Request IDs

Every request the Syntic API handles gets a unique request ID. It is the fastest way for you, and for Syntic support, to find one specific request among millions: what it asked for, which model answered, what it cost and why it failed.

x-syntic-request-id: req_6f1c2a9e0b7d4c3a8e5f1b2d

What it looks like

Property	Value
Header	`x-syntic-request-id`
Format	`req_` followed by 24 lowercase hexadecimal characters
Unique	Per request. A retry gets a new id.
Readable from browsers	Yes; the header is exposed to cross-origin code.

Store and compare the value as-is and do not parse it; its length can increase later.

Where it appears today

On every chat completions response, successful or not, except 405 method_not_allowed and 500 internal_error. A 500 body carries a trace_id instead; quote that.
On streamed responses the header arrives with the first byte, before any events.

Where it will appear

⚠️

Preview — this feature is being built; the design below is the spec.

Place	Change
Every response	The header is set on every status, including `405` and `500`. `trace_id` goes away.
Error bodies	`request_id` at the top level of the error envelope, so logs that capture only the body still have it.
Stream error events	The `error` event inside a stream carries `request_id`.
Console usage	The Usage page lists recent requests with their ids, so a finance or support question can be matched to an exact call.
Usage report	The usage report can be grouped by request for short ranges.
Batches and sessions	Each batch item and each model call inside an agent session gets its own request id, shown in results and traces.

Sending your own correlation id

You may also send x-client-request-id (up to 128 printable ASCII characters) with any request. Syntic stores it alongside its own id and echoes it back in the response header of the same name. It is not required to be unique and is never used for idempotency; use Idempotency-Key for that (see conventions).

Log it

Log the request ID with every call, together with the model, status and your own correlation id. When something goes wrong you can search your logs, and support can search theirs, with the same value.

curl -sS -D headers.txt -o reply.json https://app.syntic.ai/v1/chat/completions \
  -H "Authorization: Bearer $SYNTIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "Amara Quick", "stream": false, "messages": [{"role": "user", "content": "ping"}]}'
 
grep -i '^x-syntic-request-id' headers.txt

const res = await fetch('https://app.syntic.ai/v1/chat/completions', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.SYNTIC_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ model: 'Amara Quick', stream: false, messages: [{ role: 'user', content: 'ping' }] }),
})
const requestId = res.headers.get('x-syntic-request-id')
console.log(JSON.stringify({ requestId, status: res.status }))

import os, logging, requests
 
r = requests.post(
    "https://app.syntic.ai/v1/chat/completions",
    headers={"Authorization": f"Bearer {os.environ['SYNTIC_API_KEY']}"},
    json={"model": "Amara Quick", "stream": False, "messages": [{"role": "user", "content": "ping"}]},
)
logging.info("syntic request_id=%s status=%s", r.headers.get("x-syntic-request-id"), r.status_code)

With an OpenAI-compatible client, read the raw response to get headers, for example client.chat.completions.with_raw_response.create(...) in Python.

When you contact support

Include:

The request ID (or trace_id for a 500 today).
The approximate time and your time zone.
The status code and error code you received.

Do not include your API key. Support never needs it.

Build notes for the platform team

Generate the id once in the shared request wrapper before authentication, so even auth failures and 405s carry it.
Store it on the usage row written for each request, and on each execution trace step that calls a model.
Accept and store x-client-request-id, truncated at 128 characters.

Rate-limit headers Versioning & beta flags

Was this page helpful?