> ## Documentation Index
> Fetch the complete documentation index at: https://docs.giwa.tokscale.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Client Integration
> What changes in an AI client to route through the verified gateway, and what gateway-verified usage means once it does.
The gateway speaks the OpenAI and Anthropic wire formats natively, so adopting it is a configuration change rather than an integration project. An application or coding client changes exactly two things: the base URL and the API key.
No public gateway origin is published yet, so there is nothing to point a client at today. This page describes the integration shape and what it produces. Track the launch in [Live Evidence](/overview/live-evidence); to track your usage now, see [Quickstart: Track Your Usage](/usage-tracker/quickstart).
## The integration shape
Requests arrive on the protocol the client already speaks:
* `POST /v1/chat/completions` and `POST /v1/responses` (OpenAI wire formats, the second being what Codex speaks)
* `POST /v1/messages` and `POST /v1/messages/count_tokens` (Anthropic wire format, what Claude Code speaks)
* `GET /v1/models` and `GET /v1/models/:model` for model discovery
* `GET /v1/receipts/:request_id` to retrieve the signed receipt for a completed request
Keys are project-scoped `tok_` bearer tokens, issued per project in the console. For the exact request and response shapes, see [Gateway API](/gateway/api).
Which setting changes depends only on what the client already speaks:
| Client | What it needs |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------- |
| An OpenAI SDK application | Base URL and API key. The Chat Completions and Responses shapes are unchanged |
| An Anthropic SDK application | Base URL and API key. The Messages shape is unchanged, including token counting |
| Codex | A model provider entry whose base URL is the gateway's `/v1` root, with the wire protocol set to responses |
| Claude Code | The standard Anthropic base URL and key environment variables |
## What the client never has to do
This is the part that surprises people, and it is the reason integration is a configuration change rather than a project. A client routed through the gateway holds one API key and nothing else:
* **No wallet, and no signing.** The client never sees a private key, never signs a payment authorization, and never submits a transaction. Payment is settled between the gateway, its isolated adapter, and the facilitator.
* **No chain interaction, and no chain awareness.** The client does not need an RPC endpoint, a chain ID, a gas balance, or any notion that a chain exists. Per-request settlement happens off the request path.
* **No payment bookkeeping.** Credit top-up and per-request settlement are handled between the gateway and the project account. A prepaid-credit project makes ordinary API calls that look exactly like any other provider.
* **No receipt handling, unless it wants one.** Receipts are issued whether or not the client asks. A client that wants proof fetches it later at `GET /v1/receipts/{request_id}` under the same key, including after a stream disconnect.
The one thing a client does gain is that its usage stops being self-reported.
## Verified by real installed clients
The integration is covered by an acceptance harness rather than by mocked HTTP: Codex and Claude Code each complete paid requests through the gateway as actually installed binaries, and every terminal request is checked for a settled ledger entry and a fetchable receipt. Accounting and privacy assertions run in the same pass, which is what makes "it works with real clients" a checkable statement rather than a claim. Those targets and their markers are in [Verification Log](/gateway/verification-log).
## What gateway-verified means for the client user
Tokscale ranks usage evidence on a five-tier ladder: self-reported, consistency-checked, source-verified, gateway-verified, attested. Self-reported usage is forgeable; verified usage is an asset.
When a client runs through the gateway, the gateway itself observes the request, the model, the token counts, and the cost, then signs that observation into a `UsageReceiptV1` receipt. That is **gateway-verified**: the data engine saw the work, so the claim no longer depends on what the client's machine says about itself. When the epoch's receipts anchor on-chain, the same usage climbs to **attested**.
This is the whole reason the gateway exists. The open-source CLI can only report what a machine tells it, which is why its data sits at the bottom of the ladder however accurate it happens to be. The ladder is explained in [Verified Usage and the Evidence Ladder](/builder-passport/evidence-ladder).
## Next steps
* For the route table and 402 semantics a client talks to, see [Gateway API](/gateway/api).
* For how a receipt is verified without trusting the gateway, see [Verifying a Receipt](/builder-passport/verify-a-receipt).
* For what one full harness pass covers, see [Gateway Overview](/gateway/overview).
* For the tiers this data climbs, see [Verified Usage and the Evidence Ladder](/builder-passport/evidence-ladder).