Skip to content

Panel

Five concepts cover everything you need to use Obstruo. Each one maps directly to a section of the panel.

Organization

An Organization is the top-level container for your company's Obstruo workspace. It is created once at registration and identified by a permanent slug - a short, lowercase identifier that appears in every endpoint URL your applications call.

https://api.obstruo.ai/acme-corp/v1
                        ^^^^^^^^^
                        org slug

The slug never changes. Treat it as a stable part of your API base URL.

In the panel: the org name and slug are shown in the top-left corner. Set at registration, cannot be changed.

Project

A Project groups related resources: API keys, provider credentials, routing configuration, and governance policy. A good rule of thumb: one project per environment (production, staging) or one per product line.

Each project has an independent redaction policy, guardrail configuration, rate limits, and budget - changes to one project don't affect others.

In the panel: Administration (sidebar) → Projects tab. The active subscription and project are shown in the two pickers in the top-right corner and scope everything you see in Governance, Enforce, and Observability.

ObstruoKey

An ObstruoKey is the bearer token your application sends to Obstruo. It authenticates the request, scopes it to a project, and determines which gateway region processes it.

The key's endpoint URL - shown in the ENDPOINT column after creation - is the base_url you configure in your SDK:

https://api.obstruo.ai/your-org/v1

In the panel: Keys → Obstruo keys. The full key value is shown at creation time, and you can copy it again later with the Copy key button next to each key row - it retrieves the decrypted value from the panel.

Warning

An ObstruoKey is not a provider API key. Never send your OpenAI or Anthropic key to your application - Obstruo holds those as Provider Keys and uses them on your behalf.

Provider Key & Logical Model

These two work together to define how Obstruo routes requests to upstream LLMs.

A Provider Key is an encrypted upstream credential - your OpenAI, Anthropic, Google, or other provider API key, stored in Obstruo's KMS. Your application never touches it directly.

A Logical Model is a virtual model name your application uses in the model field. Obstruo resolves it to one or more (provider key, real model) pairs at request time.

How the pieces reference each other: the ObstruoKey says who is calling and which project the request runs in; the logical model decides what serves it. Nothing in your application ever names a provider key:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#1E1E26', 'primaryBorderColor': '#8B6FE8', 'primaryTextColor': '#ECEAF6', 'lineColor': '#8B6FE8', 'secondaryColor': '#16161C', 'tertiaryColor': '#16161C', 'mainBkg': '#1E1E26', 'nodeBorder': '#8B6FE8', 'clusterBkg': '#16161C', 'clusterBorder': '#2A2A34', 'titleColor': '#ECEAF6', 'edgeLabelBackground': '#0E0E11', 'fontFamily': 'ui-monospace, SF Mono, Menlo, monospace'}}}%%
flowchart TD
    app(["Your app\nAuthorization: ObstruoKey\nmodel = 'obstruo-chat'"])

    subgraph ep["Panel ▸ Endpoints"]
        ok["ObstruoKey: backend-prod\nproject · region · limits"]
    end

    subgraph conn["Panel ▸ Connections"]
        lm["Logical model: obstruo-chat\nordered targets"]
        pk1["Provider key:\nopenai-prod"]
        pk2["Provider key:\nanthropic"]
    end

    subgraph cat["Panel ▸ Models → Models allowed"]
        m1["gpt-4o"]
        m2["claude-3-5-sonnet"]
    end

    app --> ok
    app -->|"model field"| lm
    lm -.->|"① gpt-4o"| pk1
    lm -.->|"② claude-3-5-sonnet"| pk2
    pk1 -.->|"ticked"| m1
    pk2 -.->|"ticked"| m2

Solid arrows: what each request carries. Dashed arrows: references you configure in the panel.

The reference rules behind the diagram:

  • A target is always a (provider key, model) pair, never a bare model - the same gpt-4o behind two different provider keys is two different targets.
  • Logical models and provider keys are many-to-many: one logical model can spread its targets across several provider keys, and one provider key can back any number of logical models.
  • A model can be picked as a target only if it exists in the catalog (Models → Models allowed), its provider matches the key's API type, and it is ticked on that provider key.
  • ObstruoKeys don't pin a model: any key in the project can call any of the project's logical models - the pairing happens per request, through the model field.

At request time, the routing strategy then walks the target list:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#1E1E26', 'primaryBorderColor': '#8B6FE8', 'primaryTextColor': '#ECEAF6', 'lineColor': '#8B6FE8', 'secondaryColor': '#16161C', 'tertiaryColor': '#16161C', 'mainBkg': '#1E1E26', 'nodeBorder': '#8B6FE8', 'clusterBkg': '#16161C', 'clusterBorder': '#2A2A34', 'titleColor': '#ECEAF6', 'edgeLabelBackground': '#0E0E11', 'fontFamily': 'ui-monospace, SF Mono, Menlo, monospace'}}}%%
flowchart TD
    app(["Your app\nmodel = 'obstruo-chat'"]) --> lm

    subgraph lm["Logical Model: obstruo-chat  -  strategy: priority"]
        t1["① openai-prod → gpt-4o"]
        t2["② anthropic → claude-3-5-sonnet"]
    end

    t1 -->|tried first| gpt(["gpt-4o"])
    t2 -->|automatic fallback| claude(["claude-3-5-sonnet"])

Swap providers, add fallbacks, or optimise for cost - without touching application code.

In the panel: provider keys and logical models both live under Connections; obstruo keys under Endpoints. The allowed model catalog is under Models → Models allowed.

Policy

A Policy is the set of governance rules enforced on every request for a project. Three independent areas:

Redaction detects and replaces PII with reversible placeholders before the request reaches a model. Three layers run in sequence:

01
Regex

Structured PII: emails, phone numbers, SSNs, credit cards, IPs, and your own custom patterns.

02
NER

Free-text PII: names, places, and organisations detected using named entity recognition.

03
LLM Entity  plan gated

Anything expressible in natural language.

The Redaction page has a live Test panel: paste sample text and see exactly what gets masked before saving any changes.

Guardrails are safety checks per direction:

→
Inbound

Blocks prompt injection, jailbreaks, and malicious instructions before the LLM sees them.

←
Outbound

Screens responses for unsafe content before they reach your users.

⇄
Tools

Governs tool invocations made by agents. Each direction has built-in rules with 24h fire counts and false-positive rates.

Limits: rate limits (requests per minute) and budget caps (USD per month), set per key and per project.

In the panel: Redaction and Guardrails are under the Enforce group. Limits are set in Keys (per key) and Administration → Projects (per project).