Skip to main content

​
Running inference through Anchorage’s Agentic Banking Platform

POST /v1/chat/completions speaks the same request shape as OpenAI’s own chat completions API. Point any OpenAI-compatible SDK’s base_url at it and it works as a drop-in swap, except streaming: send "stream": false or omit the field, since a "stream": true request is rejected today.

​
Why run inference here

  • Nothing to set up. No account with the provider, no invoice, no separate billing relationship. Anchorage handles payment on the agent’s behalf and sends the request straight to the provider — point base_url at the endpoint and go.
  • Settles instantly. No waiting on an external biller; the call completes as soon as it’s paid.
  • Anchorage carries the payment infrastructure. Your organization never has to hold, manage, or expose any payment credentials of its own to use this.
  • The same budget. The budget that pays for other purchases on this platform pays for inference too, drawn from the agent’s identity here rather than a separate balance held with the provider.
  • The same governance controls. The org’s budget cap, the per-agent daily cap, and instant revocation all apply to inference spend exactly as they do to any other agent payment, approved and reconciled the same way. A budget with the default allow-all merchant setting needs no extra configuration; one restricted to a specific allowlist needs the inference provider added to it (see prerequisites).
  • Drop-in for existing code. Point an existing OpenAI-compatible integration at this endpoint and swap the API key. The request and response shapes don’t change, other than the streaming exception above.

​
How a call is billed

The agent’s API key authenticates the call (see Agents; no OAuth session works here). Anchorage bills the charge to the agent’s primary budget, gated by the same compliance and spending checks as any other agent payment. A charge over the budget cap waits for an org admin to approve it instead of completing; retry with the same request once it’s approved (see Approvals). On success, the provider’s response passes through, and a charged response carries X-Transaction-ID.

​
Managing idempotency keys

To avoid multiple charges on retries, every request carries an idempotency key. If you don’t send an Idempotency-Key header, we generate one from your agent and the request body, so sending the exact same request twice only charges you once. Send Idempotency-Key yourself to control this directly. Reuse the same key on a second request and you don’t pay again, even if you changed the body: the key guarantees you’re not charged twice, not that you get the exact same response back. Usually you get the first request’s result again; on rare occasions the original response wasn’t retained, and the provider is contacted again for a fresh one. Send a new key when you actually want to send a new request with the same body. This key isn’t scoped to your agent, it’s scoped to your whole account. If another agent on your account reuses the same key, they collide. Use something unique, like a UUID.

​
Failure modes

A compliance check enforced before this endpoint’s own error handling can return a plain-text 403 instead. Treat it the same as payment_refused.