Support

Send these, always

request_id     from the error body, or the X-Request-Id response header
job id         if a job was created (job_...)
operation      e.g. POST /v1/skin/analyses
status + error.code   or job.error.code for a failed job
when           the timestamps, with a timezone
base URL       which deployment you called

request_id is the one that matters. With it, a specific request is found in seconds; without it, the conversation starts by narrowing down which request you meant. It is on every error body and every response header, so log it on failures whether or not you plan to ask about them.

Never send these

• the API key, or any part of it — not a prefix, not a length, not a hash. A key that reaches a ticket is rotated, which is an outage you did not need;
• the image, or any face photograph. If a specific capture is genuinely required to reproduce a problem, say so and we will arrange a path for it;
• your end user’s identity. the job id identifies the work; a name or an email address identifies a person and is not needed to debug.

Privacy and retention covers what we hold and for how long.

Before asking

Most reports resolve against one of these:

What we cannot answer here

• Pricing, credit rates and invoices — commercial, not technical. Your account contact has them; Credits and usage explains what GET /v1/usage reports and why it is not billing authority.
• Uptime, latency or availability commitments — no figure is published on this site. A number that binds anyone comes from your agreement.
• Whether a result is clinically or cosmetically correct — the API reports what the model measured. Interpretation for your own customers is your decision.
• Data processing terms — a privacy page is not a DPA. Ask your account contact.

Reporting something that looks like our bug

Include what you expected, what you got, and why you believe the contract says otherwise — quoting the OpenAPI document or the page you read. The contract is the authority: if a page on this site disagrees with it, that is a documentation bug and worth reporting on its own, because someone else has read the same page.

Security issues do not belong in a normal support channel. Report them privately through your account contact, without a working exploit in the first message.