Synchronous AI calls. Policy first. Proof always.
Relay is TaskQ's low-latency execution plane for API-shaped work: messages, chat completions, streaming, model listing, and token counting. It keeps the provider wire shape familiar while the Gateway handles auth, policy, placement, custody, metering, and HashIQ proof.
Send a Messages request.
Use Relay when the customer expects a synchronous response: chat UX, API completions, model listing, token counting, and streaming. The request still carries TaskQ auth, credential handle, and optional placement policy.
curl https://api.taskq.xyz/v1/messages \ -H "authorization: Bearer $TASKQ_API_KEY" \ -H "x-taskq-credential: cred_prod_anthropic_ca" \ -H "x-taskq-policy: must_run_in=CA;key_custody=pinned,enclave" \ -H "content-type: application/json" \ -d '{ "model": "claude-sonnet-4-5", "max_tokens": 800, "messages": [{"role":"user","content":"Summarize this report."}] }'
Read proof headers from every response.
Relay preserves the expected response shape, but TaskQ adds proof headers so the customer can retrieve the signed chain record for that call.
HTTP/2 200 x-taskq-request-id: req_01J... x-taskq-chain-key: sha256:... x-taskq-placement-proof: proof_... x-taskq-worker-ref: worker_blind:...
Relay endpoints.
Relay supports provider-compatible API surfaces while keeping provider-specific behavior behind adapters.
| Method | Endpoint | Purpose |
|---|---|---|
| POST | /v1/messages | Anthropic-shaped synchronous messages, including streaming when enabled. |
| POST | /v1/chat/completions | OpenAI-compatible chat surface for tools and clients expecting that shape. |
| GET | /v1/models | Model listing filtered by provider, credential, policy, and available adapters. |
| POST | /v1/messages/count_tokens | Token counting before execution for supported providers. |
| SSE | streaming | Preserves upstream stream semantics while TaskQ closes accounting at completion. |
| GET | /v1/chain/{request_id} | Retrieve the signed proof record for a completed Relay call. |
Streaming rules.
Streaming responses keep provider-compatible byte flow. TaskQ opens the chain entry before the first upstream byte and closes it after the terminal usage event. Relay may retry only before provider side effect or before the first upstream byte. Once bytes flow, there is no blind retry.
curl https://api.taskq.xyz/v1/messages \ -H "authorization: Bearer $TASKQ_API_KEY" \ -H "x-taskq-credential: cred_prod_anthropic_ca" \ -d '{"model":"claude-sonnet-4-5","stream":true,"messages":[{"role":"user","content":"Draft the patch notes."}]}'
Relay custody is restricted by default.
Synchronous Relay traffic does not decrypt customer credentials on plain leased BYOW workers by default. Relay is eligible for pinned, enclave, and customer-owned custody classes.
Eligible — pinned / enclave / customer-owned
Credential unwrap happens only on custody classes approved by customer and credential policy.
Excluded by default — plain leased workers
Leased BYOW capacity is queue-eligible unless confidential custody or explicit customer policy allows otherwise.
Relay failures happen before execution when possible.
Policy, credential, custody, and placement failures create clear errors and may create proof entries showing prevention.
Bad or expired TaskQ bearer. No request executes.
No usable customer credential handle was provided.
No pinned, enclave, or customer-owned Relay worker satisfies policy.
A compliant worker existed but lease acquisition failed after retries.
Use Relay when the response is the product.
Relay is for synchronous API work. Queue is for jobs that produce artifacts, patches, reports, or long-running deliverables. Both share Gateway auth, policy, placement, HashIQ proof, and settlement.