Errors

Every error carries a code, the same over REST and the WebSocket. Build your logic on that code: the message text may change, the code never will.

Over REST

{
  "type": "https://fathomcharts.com/docs/errors#invalid-parameters",
  "title": "Invalid parameters",
  "status": 400,
  "detail": "Invalid indicator parameters",
  "code": "INVALID_PARAMETERS",
  "instance": "req-1b",
  "errors": [
    { "path": "/minimum", "message": "must be >= 1" }
  ]
}

• code: the error code, listed below;
• detail: a human-readable explanation;
• errors: for INVALID_PARAMETERS, the list of problems, with the location of each faulty field (path);
• instance: the request id, to share with support if needed.

When a history query or an export exceeds your budget, the response also gives its cost (computeUnits) and what you have left (remainingComputeUnits). 429 responses carry a Retry-After header: the number of seconds to wait.

Over the WebSocket

A refused or interrupted subscription receives an error message with its sub. Only that subscription is closed: the connection and your other subscriptions keep running.

{"sub":"bt","t":"error","code":"UNKNOWN_INDICATOR","message":"unknown indicator `big-trade`"}

A message the server cannot understand (invalid JSON, unknown type…) receives an error without a sub.

With the SDK, a subscription error ends its iteration with a FathomChartsError carrying the received code.

Problems that close the whole connection (key rejected, too many connections, client too slow) do not come as error messages but as close codes.

Code reference