> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.morphiaone.ai/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.morphiaone.ai/_mcp/server.

# Support

## Send these, always

```text
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](/concepts/privacy-retention) covers what we hold and for how
long.

## Before asking

Most reports resolve against one of these:

| Symptom                                                         | Start at                                                                              |
| --------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| a status or code you do not recognise                           | [Error reference](/api-reference/errors), [Status codes](/api-reference/status-codes) |
| a job that never finishes, or a `200` that looks like a failure | [Asynchronous jobs](/concepts/jobs)                                                   |
| a retry that made things worse, or a double charge              | [Retries](/concepts/retries), [Idempotency](/concepts/idempotency)                    |
| results that look inverted or wrong                             | [Skin analysis](/products/skin-analysis) — a higher score means less visible          |
| a rendering that does not match another try-on                  | [Makeup try-on](/products/makeup) — parity is unproven                                |
| anything else                                                   | [Troubleshooting](/guides/troubleshooting)                                            |

## What we cannot answer here

* **Pricing, credit rates and invoices** — commercial, not technical. Your account
  contact has them; [Credits and usage](/concepts/credits) 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](/api-reference) 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.