Bring your own gateway

Already running your own AI gateway or LLM proxy? You do not have to replace it. Joopler plugs in alongside it two ways: send it your logs for a signed record of every interaction, or call Joopler for an allow / redact / block verdict that your gateway enforces itself. Either way your traffic keeps flowing through your own infrastructure, and Joopler becomes the policy brain and evidence layer on top.

What you need

• A Joopler workspace where you are signed in as an admin.
• A proxy token to authenticate the calls (created below). Both paths use the same base URL, https://api.joopler.com.

Step 1: Create a proxy token

1. Go to AI usage in the left nav.
2. Click Issue proxy token and give it a name, for example Gateway integration.
3. Copy the token that appears. It starts with jpx_ and is shown once. Store it like a password; you can revoke it anytime from the same screen.

Send it as a bearer token on every request:

Authorization: Bearer jpx_YOUR_TOKEN

Option A: Send your logs (visibility)

Export your gateway's AI-usage logs to Joopler and each entry becomes a signed, hash-chained, timestamped evidence record on your AI usage dashboard. This is the observe path, available on every plan. Batch up to 500 entries per call.

curl https://api.joopler.com/v1/gateway/ingest \
  -H "Authorization: Bearer jpx_YOUR_TOKEN" \
  -H "content-type: application/json" \
  -d '{
    "source": "generic",
    "entries": [
      { "provider": "openai", "model": "gpt-4o", "user": "alice@yourco.com", "at": "2026-07-27T15:00:00Z", "action": "allow" }
    ]
  }'

Each entry may carry provider, model, user, url, action, and a timestamp (at or timestamp); the provider is inferred from the URL when not given. Set source to your log source. The events land next to your reverse-proxy, egress, and tool-call events and count toward your AI usage-logging control.

Option B: Ask Joopler for a verdict (enforcement)

Have your gateway call Joopler with the prompt or response text and get back a verdict to enforce. Joopler runs the same inspection pipeline it uses on its own proxy (data-loss detection, prompt-injection detection, data classification) and returns one of three actions. Nothing is forwarded and the raw content is never stored, only a hash and the redacted findings.

curl https://api.joopler.com/v1/gateway/check \
  -H "Authorization: Bearer jpx_YOUR_TOKEN" \
  -H "content-type: application/json" \
  -d '{
    "content": "the prompt or response text to inspect",
    "kind": "prompt",
    "provider": "openai",
    "model": "gpt-4o",
    "user": "alice@yourco.com"
  }'

The response tells your gateway what to do:

{
  "action": "block",
  "allow": false,
  "reason": "a secret was detected",
  "classification": "restricted",
  "injection": false,
  "hits": { "aws_access_key": 1 },
  "enforced": true
}

• allow - forward the request unchanged.
• redact - forward the cleaned text returned in redactedText instead of the original (secrets stripped).
• block - refuse the request; show reason to the caller.

Your gateway honors whichever action comes back. Every decision is signed into your evidence ledger and recorded on your AI usage dashboard, so bring-your-own-gateway traffic still produces auditable evidence and satisfies your AI-governance controls.

Enforcement is a Growth plan feature

Verdicts that actually block or redact are available on the Growth plan and above. On lower plans the check endpoint still inspects and records every call for full visibility, but always returns allow with enforced: false - observe-only. To turn on real enforcement, set your enforcement rules under AI usage → Provider steering and upgrade to Growth. Until then, your ai-dlp-enforced control stays open with a prompt to enable it.