Skip to main content
TheGuarantors uses standard HTTP status codes to signal the outcome of an API request. Except for rate limit errors, every error response includes:
  • Message: A human-readable message detailing the reason for the request failure.
  • Object: error
Errors from the invite amendment endpoints (PATCH /v1/invites/:id, POST /v1/invites/:id/invite-recipients, PATCH /v1/invite-recipients/:id and DELETE /v1/invite-recipients/:id) also include:
  • Error code: A machine-readable code identifying the reason for the failure, returned as error_code.
  • Field errors: For a validation_error, one entry per rejected field, returned as field_errors.
See Error for the full schema.

​
Error codes

An error code is a short, fixed string, such as invite_canceled, that identifies why a request failed. The invite amendment endpoints include one in the error_code field of their error responses, except for errors raised while authenticating your request, such as a 401:
When the error code is validation_error, the response also includes field_errors. Each entry names a rejected field by its path and carries its own code and message:
Error codes are covered by our Breaking Change Policy, so use error_code rather than message to handle a failure in your integration. New codes may be added over time, so treat a code you don’t recognize as a general failure for its HTTP status. Each endpoint’s API reference lists the error codes it can return.

​
Unknown fields

Request bodies may only contain the fields documented for that endpoint. If a request includes any other field, at the top level or nested inside an object or array item, the API returns a 400 Bad Request listing each one by its path, and nothing is created or modified:
metadata objects are the exception: they accept any keys, subject to the metadata validation rules. On update endpoints, sending a field that exists on the resource but cannot be edited returns <field> is not a supported field for editing (for example, obligee on PATCH /v1/invites/:id).