Your next application.
One connected API.

Build with the API

From an account to a working integration, without guessing endpoints.

Use one service account with the public model selections and eligible credit/time shown by that account. The API exposes compatible Responses, Chat Completions and Messages interfaces. An SDK is optional; the HTTP examples work with ordinary clients.

1. Register or sign in, verify your email and complete required security checks.
2. Open API Keys and create a named User API Key. Up to 20 active keys are available per site.
3. Give it the permissions your integration needs. Save it server-side with the correct base URL.
4. Check the account’s funding/access, list models, then send a small streaming request.
5. Capture the response’s request ID and completion/usage events. Keep errors and retries visible in your application logs without logging keys or private coding content.

Choose the correct base URL

Your account site determines where its key belongs.

For direct HTTP calls, use the complete endpoint path. For an SDK that appends /responses or /chat/completions, configure its base URL with exactly one /v1. Do not accidentally send to /v1/v1/....

Use a regional URL only when your site’s setup/connection controls supply it. Do not assume a different brand’s key or a dashboard session will work on another API host.

Authenticate and restrict keys

Treat the key as a secret, and grant only the required capabilities.

export API_KEY="YOUR_API_KEY"
export API_BASE="https://codexapi.pro"

$env:API_KEY = "YOUR_API_KEY"
$env:API_BASE = "https://codexapi.pro"

The placeholders above must be replaced on your own machine or server. Use a secret manager for a deployed application. A public browser/mobile app should call your own backend rather than ship this key to users.

Keep System Tokens for owner actions that require them, such as managing other keys. Named User API Keys keep their owner, permissions, expiry, spending/IP restrictions and revocation state. API authentication is distinct from a website session JWT. Do not transmit credentials in query strings.

Discover supported models

Fetch exact IDs instead of hard-coding private or retired selections.

curl -fsS "$API_BASE/v1/models" \
  -H "Authorization: Bearer $API_KEY"

The response uses a data array. Use an ID returned for your account and the endpoint/client you intend to use. Public model choices and requested effort follow your account’s managed service terms; they are not permission to specify an internal provider or arbitrary upstream URL.

Fable 5.2 uses the separate public ID claude-fable-5-2. Fable 5.1 and its existing aliases retain their original selection. Use a compatible client and check the exact allowed models on your paid plan; adding a public model does not expand a model-specific paid contract.

Fable 5.2 supports streaming, tool calls and text/image input through compatible API clients, with a 1,000,000-token context and up to 128,000 output tokens. Request high reasoning effort by default; supported efforts are low, medium, high, xhigh and max.

These are the published base wallet rates for Fable 5.2. Your account rate card and applicable client/account adjustments govern the final charge. Plan coverage, funding, request limits and compatible tooling still apply.

curl -N "$API_BASE/v1/responses" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-fable-5-2","stream":true,"reasoning":{"effort":"high"},"input":"Write a small Python function and explain its edge cases."}'

A logical selection can have app-specific compatibility. For example, Daybreak Blue is restricted to supported managed-client transport, and Carbon 4 is a managed preview. If an ID is missing or rejected, use the authenticated catalogue and setup wizard rather than forcing a hidden alias.

Use power-ai with the API

One public managed model alias, with the same account and tool workflow.

Use power-ai as the model ID in a compatible request. No subscription is required: use sufficient wallet credit or eligible coding coverage, including All Models Unlimited sessions. Normal funding and usage limits apply; it is not a separate key or a private provider identifier.

curl -N "https://codexapi.pro/v1/chat/completions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"power-ai","stream":true,"messages":[{"role":"user","content":"Write a small Python function."}]}'

The same alias can be used with the supported Responses interface. Keep streaming enabled for Codex-style Responses requests and use the tool format appropriate to the chosen protocol. Preserve complete reasoning/tool state for a continuation.

Execution follows the managed service configuration. Do not specify internal destinations, forge another client’s identity or assume access to a hidden model. If a request fails, retain the complete error and request ID.

Send a streaming Responses request

The Codex-style request path requires stream:true.

curl -N "$API_BASE/v1/responses" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-6.1-sol","stream":true,"reasoning":{"effort":"xhigh"},"input":"Write a Python function that adds two numbers."}'

A successful HTTP status only means the stream opened. Your client must read until a completed terminal event or an explicit error/disconnect. Consume text deltas for display and retain the complete final response.output for continuations.

Python, using the standard library

import json, os, urllib.request

body = {"model": "gpt-6.1-sol", "stream": True,
        "input": "Write a Python function that adds two numbers."}
request = urllib.request.Request(
    os.environ["API_BASE"] + "/v1/responses",
    data=json.dumps(body).encode(),
    headers={"Authorization": "Bearer " + os.environ["API_KEY"],
             "Content-Type": "application/json"}, method="POST")
with urllib.request.urlopen(request, timeout=300) as response:
    print("Request ID:", response.headers.get("X-Request-ID"))
    for line in response:
        print(line.decode("utf-8"), end="")

Node.js, using fetch

const response = await fetch(process.env.API_BASE + "/v1/responses", {
  method: "POST",
  headers: { Authorization: `Bearer ${process.env.API_KEY}`,
             "Content-Type": "application/json" },
  body: JSON.stringify({ model: "gpt-6.1-sol", stream: true,
                         input: "Write a small Python function." })
});
if (!response.ok) throw new Error(`${response.status}: ${await response.text()}`);
console.log("Request ID:", response.headers.get("x-request-id"));
if (!response.body) throw new Error("The response has no stream body");
const decoder = new TextDecoder();
for await (const chunk of response.body) {
  process.stdout.write(decoder.decode(chunk, { stream: true }));
}
process.stdout.write(decoder.decode());

These examples print raw SSE for a first connection check. A production client should parse frames, show deltas, handle terminal errors and keep full continuation items. Choose timeouts appropriate to your application; do not automatically resubmit a partially completed paid request.

Use the Messages API

Send Claude-style messages with the required version header.

curl -N "$API_BASE/v1/messages" \
  -H "Authorization: Bearer $API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-opus-5-5","max_tokens":256,"stream":true,"messages":[{"role":"user","content":"Write a Python hello-world function."}]}'

Provide model, max_tokens and the messages array. Use the content-block format the endpoint expects for tools/images. In a stream, process message_start, content-block events, usage/stop information and message_stop.

Preserve complete thinking/redacted-thinking/signature blocks returned by the service when carrying a conversation forward. Do not move signed state between accounts, models or unrelated conversations. Tool results use Messages-format blocks, not Responses-format function-call items.

Use Chat Completions

Connect applications that expect a messages-based chat endpoint.

curl -N "$API_BASE/v1/chat/completions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-6.1-sol","stream":true,"messages":[{"role":"user","content":"Explain this API in one sentence."}]}'

Use messages for the conversation. Streaming clients should accumulate text/tool argument deltas, respect the finish reason and capture usage when reported. Preserve returned reasoning_details and tool-call IDs for a compatible continuation.

Legacy Completions and stored-chat operations exist only where the site schema lists them. Do not assume every compatibility interface supports every upstream provider feature. The live endpoint reference lists this site’s published methods and request fields.

Stream completion, cancellation and safe timeouts

Separate an opened connection from a successful model result.

1. Check the HTTP status before parsing SSE. Capture X-Request-ID when present.
2. Parse complete SSE frames. Ignore keepalives for content; render only recognized text/tool deltas.
3. For Responses, wait for response.completed and inspect the completed response. Treat response.failed, an error event or premature disconnect as incomplete.
4. For Messages, require the terminal stop sequence/stop reason rather than assuming the first text delta means success.
5. On user cancellation, close the connection and cancel local work. Use an advertised response-cancel endpoint only when you have a valid stored response ID and that operation is supported.
6. Before retrying an ambiguous failure, inspect your own request logs and pass telemetry. Do not replay a completed or partially streamed request just because your UI timed out.

A canceled request can already have consumed resources. Retry policy must preserve actual usage and avoid duplicate tool side effects. Use exponential backoff/jitter for safe retryable admission failures; never retry authentication/permission errors indefinitely.

Implement a tool-calling loop

The model requests a tool; your application decides whether to execute it.

{
  "model": "gpt-6.1-sol",
  "stream": true,
  "tools": [{"type":"function", "name":"get_order_status",
    "description":"Look up an order the current user may access",
    "parameters":{"type":"object", "properties":{"order_id":{"type":"string"}},
                  "required":["order_id"], "additionalProperties":false}}],
  "input":"What is the status of my order?"
}

1. Declare a bounded JSON schema for the function and pass only tools you intend to expose.
2. Accumulate each returned function call’s argument fragments until complete. Validate its function name and parse/validate the final JSON arguments.
3. Authorize the action for the current user in your own backend. A model requesting an order lookup does not establish ownership.
4. Execute the approved tool once, using your own side-effect/idempotency controls.
5. Append the complete model output and a function_call_output carrying the original call_id, then send the next request with the same conversation context.

// Use completeOutput from the completed response, not text deltas alone.
const nextInput = [
  ...previousInput,
  ...completeOutput,
  { type: "function_call_output", call_id: toolCall.call_id,
    output: JSON.stringify({ status: "paid" }) }
];

Responses function choices use a flat {"type":"function","name":"..."}. Chat Completions tool choices nest the name under function. Messages uses its own tool_use/tool_result blocks. Keep protocol formats separate and never execute incomplete arguments.

Keep conversation and reasoning state intact

Avoid missing-item and encrypted-content failures.

1. Keep the full final assistant output, including reasoning/opaque state and tool calls, in the same account/model conversation.
2. For stateless requests (store:false), resend the complete required history/items. A bare item ID does not recreate unpersisted content.
3. Preserve stable tool call_id values and pair every tool result with the correct call. Do not replace opaque reasoning with an invented placeholder.
4. Only use previous_response_id, item references or stored-response retrieval when that service/route explicitly persisted the response and supports that operation.
5. After switching accounts/models or losing required state, start a fresh conversation rather than copying signed/encrypted items into a new scope.

Do not strip all reasoning, signatures or tool results as a workaround. If the backend rejects encrypted content, give support the error and request ID without publishing ciphertext or private conversation content.

Web search, images and structured output

Check capability and send the correct protocol shape.

Web search: use a supported search tool in a compatible request/client. The coding client may supply its own local/MCP tool. Inspect actual returned search/citation material; unrelated text or a model’s guess is not verified live search.

{"model":"gpt-6.1-sol","stream":true,"tools":[{"type":"web_search"}],"input":"Find current information and cite the sources you use."}

Images: use the image-content structure accepted by the chosen endpoint/model. Responses, Messages and Chat Completions use different content shapes. Keep payload sizes reasonable and do not send private images without permission.

Structured output: request the JSON/schema options published for the endpoint, then validate the returned result in your own app. Tool schemas and response-output schemas serve different purposes. A schema does not authorize a tool action.

If a provider/route does not support an option, handle its explicit error. Do not silently downgrade tools, fabricate citations or present incomplete output as a completed success.

Funding, billing and fallback resources

API usage shares the account’s eligible access, with normal safeguards.

curl -fsS "$API_BASE/api/v1/wallet/status" \
  -H "Authorization: Bearer $API_KEY"

Read billingStatus and the public wallet/window fields the endpoint returns. A status read does not reserve a coding allowance or start unused Unlimited time.

Permanent Uncapped API coverage follows the same model scope as the app: 1 day covers Opus 5.5 and Sonnet 5.5; 3 days also covers Fable 5.1; 7, 14 and 30 days cover every public model subject to client compatibility. Time starts at the first eligible coding admission and then runs continuously. No Pause, VIP, five-hour allowance or 24-hour allowance is included in these plans.

1. Usable, unpaused purchased Unlimited can pay first while preserving wallet funds.
2. Otherwise eligible plan/token allocations and included resources are evaluated under their terms.
3. When a membership allowance/window is exhausted, eligible Unlimited or Credit Wallet can continue paying; wallet-funded usage has no membership window cap.
4. Paused, future, expired or model-incompatible time cannot pay. A key’s restrictions can still reject a request even if the owner has funds.
5. If no usable resource remains, handle insufficient credit and direct the owner to top up or purchase available access.

Input/output/cache/reasoning buckets and minimum charges follow the account’s saved rate card. Purchased wallet credit does not expire; promotional allocations can. View current prices in the dashboard/quote rather than hard-coding an advertised rate into settlement logic.

Managed-app savings apply only to genuine eligible clients. Do not forge client headers to claim a discount or bypass model compatibility. A PayPal/crypto receipt and token-usage telemetry are different records.

The server verifies the saved package quote and available Cash Wallet funds. It does not charge an external card, withdraw API credit as cash, or exchange Reward Points. If the initial quote changed, no funds are deducted: review the fresh quote before authorizing a new request. Billing status reads and quote reads never make a purchase.

Read live tokens for every pass

Owner/key-scoped telemetry across all four sites.

curl -fsS "$API_BASE/api/v1/usage/passes?limit=20" \
  -H "Authorization: Bearer $API_KEY"

curl -fsS "$API_BASE/api/v1/usage/passes/PASS_ID" \
  -H "Authorization: Bearer $API_KEY"

curl -N "$API_BASE/api/v1/usage/passes/PASS_ID/events" \
  -H "Authorization: Bearer $API_KEY"

Take the pass ID from X-Request-ID on your generation response. Use the same account/key scope. A restricted key cannot read another key’s history; inaccessible or unknown passes return 404.

Poll about every 1–2 seconds or prefer the SSE feed. Missing counts remain null until reported, and some providers update only at completion. Do not sum cumulative snapshots as new token increments or use these diagnostic reads as a substitute for the account’s settled ledger.

Handle errors without hiding the cause

Classify admission, credentials, validation and upstream failures.

An HTTP200 stream can still contain a terminal error. Log status, request ID, endpoint, selected public model and timestamp; redact authorization headers, ciphertext, passwords and private prompt contents. Do not substitute an unrelated answer when a tool or provider fails.

Stored responses, counting and compatibility operations

Discover what this site and selected route actually support.

The live reference may list response retrieval, deletion, input-item listing, cancellation, compaction, token counting, stored chat or legacy completion operations. Availability varies across sites and execution routes.

1. Find the exact path and method in the endpoint reference. Read its request schema and required fields.
2. Use the correct account/key and an ID that the operation actually created or persisted. Setting store:false means you must not assume stored lineage exists.
3. For token-count endpoints, use the endpoint-specific payload. A preflight count is an estimate/diagnostic and is not a final usage receipt.
4. For destructive operations such as deleting a stored object, obtain the user’s intended action and handle its actual response; do not execute every advertised method automatically.

A published compatibility path is not a promise that a chosen managed execution route stores every item. Handle explicit capability errors and preserve the full upstream detail. If your app only needs generation, start with the three primary protocols.

Live customer endpoint reference

Search published methods without exposing admin or retired payment APIs.

This browser reads the site’s current public OpenAPI document, displays customer operations and explains request/response fields. It does not automatically execute endpoints. Legacy payment initiation, internal/admin and provider-private operations are excluded from this documentation view.

The reference loads on request. No API key is needed to read it.

Test a model-list request in this tab

Check authentication without submitting a paid coding pass.

Paste your own key only on the genuine HTTPS site. This optional tester sends a same-site model-list GET to /v1/models. It keeps the key in memory for this tab only and does not save it in browser storage or a URL.

No request has been sent.

A 401/403 result does not submit a coding request or load credit. Review key permissions and site/base URL. The tester never buys a product, changes routing, grants access or executes a tool.

Production checklist and safe integration habits

Move beyond a successful hello-world request.

• Keep keys server-side; use separate named/restricted keys for each environment and rotate deliberately.
• Use explicit user consent for paid purchases, recurring billing and tools with side effects.
• Consume complete streams; validate outputs/tool arguments and preserve full continuation state.
• Bound concurrency and retry with backoff/jitter. Do not let one job create unlimited retry loops.
• Capture request IDs and final usage. Distinguish provider-reported telemetry from settled billing.
• Keep local files/terminal/MCP tools under your own authorization and audit policy.
• Use current public models and client versions; do not hard-code private routing destinations.
• Build an account-funding/402 flow and a support path for ambiguous payments or incomplete requests.

For provisioning reseller clients, use the separate reseller API guide. For an existing failure, open a support ticket with redacted logs, the request ID and approximate time.