Further reading

Getting support

Quote the request id and the approximate time of the request, with its time zone. API responses carry the id in the X-Request-Id header, and every error repeats it as requestId.

Every response of the API, successful or not, has an X-Request-Id header, in the form req_ followed by hexadecimal characters. An error body repeats the value as requestId. It identifies one request. Filmo generates it on the server: a value you send is never used.

Two places do not follow this. The OAuth endpoints return no request id at all, and a 401 from the MCP endpoint can carry it only in the body, not in the header.

An error body with its requestId
{
  "type": "https://docs.filmo.io/errors/not_found",
  "title": "Not found",
  "status": 404,
  "code": "not_found",
  "detail": "The order does not exist",
  "requestId": "req_5f1c2f4e3a5b4f6d8e7a0b1c2d3e4f5a"
}

Log the request id for every failed call. Do not wait for a problem to start recording it.

Note:

Quote the request id as soon as you can. Filmo does not promise that a request can be located afterwards, or for how long, so a request from weeks ago may not be found. That is why the time of the request matters as much as the id.

  • The request id, or several if the problem repeats.
  • The approximate time of the request, with its time zone.
  • The operation: method and path, such as POST /api/v1/orders.
  • What you expected and what happened: the HTTP status and the code of the error.
  • The scopes of the key (the scopes of GET /api/v1/account), if the problem is about permissions.
  • Whether you used the REST API or an MCP tool, and the client.
  • The API key, or any part of it.
  • Personal data of customers or staff. The request id and the time are what support needs.
  • Full response bodies that contain records. Send the shape or a redacted copy.
  • Check the status and the errors guide. The first call that fails usually has a known cause.
  • If the error is a 400 on a date, check the offset; see dates and times.
  • For a 429, wait for Retry-After before you try again.
  • For a 5xx on a write, retry with the same Idempotency-Key first, so the write cannot run twice.

Put the information above in your first message, so nobody has to ask for it again. This documentation does not promise a response time.

To get in touch, follow the steps in Contact support in the help center.

  • Guides

    Errors

    Errors are RFC 9457 problem documents. Branch on the stable code, never on the text, and use the retry table to decide whether to try again.

  • Guides

    Responses

    Successful responses wrap their payload in data; lists add pagination; a few operations add meta; errors are RFC 9457 problems. API responses share one set of headers.

  • Guides

    Going live checklist

    Go through these eight checks before your integration runs against production data. Each one points to the guide that explains it.

Was this page helpful?