Integrate the hosted service.

Everything else in this section (API integration, Configuration, Deployment) is written for running DFENS yourself. If you signed up on portal.dfens.ai — Developer, Pro, or Team — this page is your starting point instead: what signup actually gives you, and the handful of things that differ from a self-hosted deployment. The rule engine, request/response schemas, and block behaviour underneath are identical either way.

What signup gives you

Once your Cloud subscription is active — as soon as you verify your email on Developer (free), or once payment is confirmed on Pro/Team — your customer portal issues:

• A base URL — https://api.dfens.ai, the same endpoint for every account, backed by multi-region infrastructure. Traffic is inspected before the forwarded call ever leaves for your model provider.
• An API key shaped aifw_live_<24 chars> (test keys are aifw_test_…). It's shown once, at creation — store it in your secret manager immediately; the portal can't show it to you again. Create, rotate, or revoke additional keys any time from the portal, no ticket required.

The key does double duty: it authenticates the request and identifies your account. There's no separate tenant header to set.

Authenticate every request

Present the key on every request in the X-AI-Firewall-Key header — the same header name the self-hosted engine's optional client authentication uses, but administered differently: self-hosted, it's one static token you set yourself via config; on Cloud, it's the individual key your account issued, already tied to your subscription and revocable from the portal.

# Point the OpenAI SDK at your Cloud endpoint
export OPENAI_BASE_URL=https://api.dfens.ai/v1

curl -X POST https://api.dfens.ai/v1/chat/completions \
  -H "X-AI-Firewall-Key: $DFENS_API_KEY" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o","messages":[{"role":"user","content":"hello"}]}'

Your own Authorization header still authenticates to the upstream provider — DFENS forwards it untouched on allowed traffic and strips X-AI-Firewall-Key before anything leaves for your provider. A missing or unrecognized key returns 401.

Same engine, same schemas

Provider routes, the reverse-proxy vs. /v1/inspect choice, streaming and truncation behaviour, and block-response shapes are all exactly what API integration describes — that page applies to Cloud traffic unchanged. This page only covers what's different: how you authenticate, and the errors that come from being a metered, multi-tenant service rather than a deployment only you can see.

Cloud-specific errors

On top of the block/streaming/status codes in API integration, Cloud traffic can also be refused for account-level reasons — always a JSON body naming the reason, never a silent drop:

Exact inclusion figures and what happens beyond them (hard cap vs. metered overage) vary by plan — Pricing is the source of truth for current numbers, kept separate from this integration reference so the two don't drift out of sync with each other.

Your customer portal

portal.dfens.ai is self-serve account management — separate from your firewall traffic, and separate from the billing portal linked from your subscription email:

• The DFENS customer portal (this section) — sign in via a magic link (no password), see usage against your plan, create/rotate/revoke API keys, and review recent rule-decision history for your traffic.
• Your billing portal — invoices, payment method, and subscription details. DFENS never asks for or stores your payment details directly.

Next: API integration for the request/response schemas and block behaviour that apply to every request, Cloud or self-hosted.