PureBridge API Docs

Use the OpenAI-compatible API to access multiple models.

Корпоративный доступ · For teams that need a sales contact and manual setup.

If you only want direct chat, writing, or image generation, start with the user guide or open Chatbox. This page is for users who need API Key, Base URL, SDK, CLI, IDE agent, and automation setup.

https://api.purebridge.uk

Use the API domain for programmatic traffic. Manage accounts, keys, and billing in the console.

Bearer API KEY

Create an API KEY inside your PureBridge app workspace, then pass it in the Authorization header.

OpenAI-style JSON

Works with OpenAI SDK style base_url, bearer authentication, and JSON request/response payloads.

Chat completions support stream: true for interactive responses. Use stream: false when you want a simple header-verification request.

Get from account to first request.

The public user flow is now simple: create an account on the main domain, generate an API KEY in App, then call the API domain.

  1. Create your account on purebridge.uk and sign in.
  2. Open App Workspace and create an API KEY.
  3. Send requests to the API domain with Authorization: Bearer <your_key>.
  4. Call GET /v1/models first, then send a minimal POST /v1/chat/completions request.

Current public surface

PureBridge keeps the public contract small and predictable. These are the routes currently documented for user-facing integrations.

GET /v1/models

List available models

Returns enabled PureBridge model IDs that can be used in completion requests.

POST /v1/chat/completions

Create chat completions

Streaming supported

Accepts an OpenAI-style chat payload; supports stream: true SSE responses and stream: false JSON responses.

GET /health

Health check

Returns a lightweight OK signal for deployment and probe checks.

POST /v1/chat/completions

Chat completions support stream: true for interactive responses. Use stream: false when you want a simple header-verification request.

Model values shown here are PureBridge model IDs returned by GET /v1/models. Use them exactly as returned; they may be routing aliases rather than upstream provider release names.

curl https://api.purebridge.uk/v1/chat/completions \
  -H "Authorization: Bearer sk-xxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
  "model": "codex-auto-review",
  "messages": [
    {
      "role": "system",
      "content": "You are a concise assistant."
    },
    {
      "role": "user",
      "content": "Say hello from PureBridge."
    }
  ],
  "stream": true
}'

Standard SSE streaming payload

data: {"id":"chatcmpl_123","object":"chat.completion.chunk","model":"codex-auto-review","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}

data: {"id":"chatcmpl_123","object":"chat.completion.chunk","model":"codex-auto-review","choices":[{"index":0,"delta":{"content":"Hello from PureBridge."},"finish_reason":null}]}

data: {"id":"chatcmpl_123","object":"chat.completion.chunk","model":"codex-auto-review","choices":[{"index":0,"delta":{},"finish_reason":"stop"}]}

data: [DONE]

Check the official request id for OpenAI-routed calls

When the selected model routes to the official OpenAI upstream, PureBridge passes through the x-request-id returned by OpenAI. You can also send X-Client-Request-Id so your own trace id is available in upstream troubleshooting.

  • x-request-id is the request ID generated by the OpenAI API for the upstream request. Record it for PureBridge-side troubleshooting and reconciliation.
  • X-Client-Request-Id is generated by you and sent with the request, making it easier to connect local logs, PureBridge usage records, and upstream support traces.
  • If the model ID routes to a non-OpenAI upstream, use that upstream's response headers and error format instead.
  • The body sha256 in the sample is the hash of the bytes you sent locally. If gateway-level body-sha256 echoing is enabled later, it can be used to compare the upstream body as well.

Response-header verification sample

export PB_API_KEY="sk-xxxxxxxxxxxxxxxxxxxxxxxx"
CLIENT_REQUEST_ID="pb-verify-$(date +%s)"
BODY='{"model":"codex-auto-review","messages":[{"role":"user","content":"ping"}],"stream":false}'

printf "%s" "$BODY" | shasum -a 256

curl -sS -D - -o /tmp/purebridge-verify.json https://api.purebridge.uk/v1/chat/completions \
  -H "Authorization: Bearer $PB_API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-Client-Request-Id: $CLIENT_REQUEST_ID" \
  --data-binary "$BODY" \
  | grep -Ei '^(x-request-id|openai-|x-ratelimit|date):'

PureBridge model IDs available in this environment

Model values shown here are PureBridge model IDs returned by GET /v1/models. Use them exactly as returned; they may be routing aliases rather than upstream provider release names.

  • codex-auto-review codex-auto-review ·
  • gpt-5.4-mini gpt-5.4-mini ·
  • gpt-5.5 gpt-5.5 ·

GET /v1/models response shape

{
  "object": "list",
  "data": [
    {
      "id": "codex-auto-review",
      "object": "model",
      "owned_by": ""
    },
    {
      "id": "gpt-5.4-mini",
      "object": "model",
      "owned_by": ""
    },
    {
      "id": "gpt-5.5",
      "object": "model",
      "owned_by": ""
    }
  ]
}

Operational expectations before production use.

Keep implementation simple: one API domain, bearer authentication, explicit model selection, and normal HTTP error handling.

Authentication and keys

  • Send Authorization: Bearer <your_key> on every API request.
  • Create and rotate account-scoped keys from the PureBridge console.
  • Do not place production keys in browser code, public repositories, or client-side logs.

Errors and limits

  • 401 means the Bearer API KEY is missing, invalid, or disabled.
  • 429 means the account or current environment is rate limited. Retry with backoff.
  • 5xx responses should be treated as transient upstream or routing failures.

What this path is for

  • Team onboarding and account help
  • Manual setup and sales contact
  • Usage review, SLA, and account management

What to do after reading

Submit the contact form so we can review your requirements and follow up.

Behavioral constraints