Run a tight ship and level up your Record360 experience with the Integration API.

⏳

Experimental

The Integration API is an experimental feature, and may be subject to change. Anything not explicitly documented on this site will not be considered backwards compatible. Additionally, small tweaks or bug fixes that affect backwards compatibility may need to be made, but will always be made with direct contact to affected users.

The Record360 Integration API β€” also known as the v3 REST API β€” uses standard http verbs to communicate and http status codes to indicate status and error. All responses come in standard JSON. The API is served over HTTPS to ensure data privacy; HTTP is not supported.

Backwards-compatible changes

We consider the following changes to be backwards-compatible:

  • Adding new API resources.
  • Adding new optional request parameters to existing API methods.
  • Adding new optional properties to existing API request bodies.
  • Making required properties in existing API request bodies optional.
  • Adding new properties to existing API responses.
  • Changing the order of properties in existing API responses.
  • Changing the length or format of object IDs or other opaque strings.
    • Ensure that your integration can handle Record360-generated object IDs, which can contain up to 255 characters. For example, if you’re using MySQL, store the IDs in a `VARCHAR(255) COLLATE utf8_bin`` column (the COLLATE configuration provides case-sensitivity during lookups).
  • Adding new event types.
    • Ensure that your webhook listener gracefully handles unfamiliar event types.

Errors

Record360 uses standard HTTP status codes to indicate request success or failure. When present, the body of the response will be JSON in the following format:

{
  "errors": "The Unit A-001 could not be found"
}

Experimental features

We may provide new API features via experimental flags. This allows early adopters to opt-in for the latest and greatest while providing feedback before we make a feature generally available (GA). We believe in stability without stagnation. Experimental features allow our team to build and ship best-in-class APIs faster, while upholding backwards-compatibility on GA features.

Experimental features are subject to change, and thus, are exempt from any backwards-compatibility guarantees. We do not expect nor recommend using experimental features in production environments unless our teams are working closely together.