Quiltt Logo

API Overview

Quiltt is a hybrid API. We provide a powerful GraphQL API to support expressive interactions with your end-user's financial data, and simple REST APIs to power server-side authentication and administrative concerns.

Link to this section#Schemas and Reference

Full resource and schema documentation is available in the corresponding API Reference pages:

A great place to interact with the Profile GraphQL API is the GraphQL Explorer in your Dashboard

Link to this section#Protocols & Headers

Quiltt APIs are served over HTTPS to ensure data security; requests sent over HTTP will not be processed.

All POST request payloads must be sent as JSON, accompanied with a Content-Type header:

Content-Type: application/json

Link to this section#Versioning

When we make breaking changes to our API, we release a new version. The current version is 2024-01-01.

By default all API requests use the API version set on your API Key in the Dashboard. You can override this by setting the Quiltt-Version HTTP header to a specific version.

All API responses will return a 'Quiltt-Version' HTTP header to indicate which version was used for the request.

Link to this section#Rate Limits

Rate limits are applied based on the authorization scope:

  • Requests authenticated with a valid Session token are limited to 100 per second.
  • All other requests are limited to 25 per second.

Please contact us if your use-case requires higher limits. You can view your request budget in the headers of each response:

Ratelimit-Limit: 100
Ratelimit-Remaining: 99
Ratelimit-Reset: 1659127063

Link to this section#Pagination

Link to this section#REST

REST Endpoints that return a collection of objects support a simple pagination scheme, with the following parameters:

All responses will return pagination information via the following headers:

  • Current-Page
  • Page-Items
  • Total-Count
  • Total-Pages

You can request additional pages using the page and items query params to specify the page number and number of records to return, respectively.

Link to this section#GraphQL

The GraphQL API uses Relay-style cursor-based pagination to support efficient and flexible querying of large lists like Transactions.

See the GraphQL Pagination guide for more information.

Link to this section#Errors

Link to this section#Errors in REST

REST API calls use standard HTTP response codes for success and failure notifications.

  • 2xx HTTP codes indicate a successful request
  • 4xx HTTP codes indicate an issue with the request
  • 5xx HTTP codes indicate an unexpected error

Unsuccessful 4xx and 5xx requests will return a JSON body with the following response schema:

A generic error with troubleshooting instructions. This object will be returned with all `4xx` or `5xx` HTTP status codes, except `422`.
  • message:stringrequired
    A high-level description of the error.
    Example: Not Authenticated
  • instruction:stringrequired
    A helpful message to troubleshoot what went wrong.
    Example: Are you sending a valid API Key secret in the `Authorization` header?
  • errorId:string
    The unique ID associated with a server error, used for troubleshooting.

Link to this section#Errors in GraphQL

Since GraphQL is transport-agnostic and uses an "errors-as-data" pattern, authenticated requests to the Profile GraphQL API will return errors inside an errors JSON object, along with 200 HTTP response. See the GraphQL validation documentation for more information on this pattern.

Additionally, Quiltt mutations expose a success boolean and an errors object to communicate any data validation errors, similar to a 422 HTTP response in REST, like so:

{
  "data": {
    "success": false,
    "errors": [
      {
        "path": ['attributes', 'phone'],
        "message": 'Phone is not a valid E.164 phone number'
      }
    ]
    "record": null
  }
}