API Overview
Loading...
Loading...
Loading...
Quiltt is a hybrid API, leveraging both GraphQL and REST.
Use the powerful GraphQL API to interact with your end-user's financial data, and simple REST APIs to handle authentication and administration concerns.
Full resource and schema documentation is available in the corresponding API Reference pages:
Types, queries, mutations and subscriptions for interacting with Profile data with GraphQL
Schemas and endpoints to manage your backend integration to Platform
Schemas and endpoints to authenticating to Quiltt
The GraphQL API reference page includes instructions on how to use GraphQL's powerful introspection system, and the REST API reference pages include downloadable OpenAPI specifications.
For the Platform and Auth APIs, you can access the OpenAPI specifications here:
These can be used with OpenAPI-compatible tools like Postman, openapi-generator or openapi-typescript to generate client libraries, typings and more.
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:
When we make breaking changes to our API, we release a new version. The current version is 2025-04-01.
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 API version was used to process the request.
Most API calls are subject to the following rate limits:
You can access your current request budget in the headers of each response:
Additionally, a separate per-Profile rate limit is applied when Issuing Session Tokens. For each Profile, you can issue a maximum of:
Revoked Session tokens do not count towards this limit.
To avoid hitting the rate limit, we recommend ensuring that client and devices are correctly persisting and revoking sessions during the user's activity lifecycle. For server-to-server API requests and intensive use-cases, use Basic Auth, which is not subject to this rate limit.
If you exceed the rate limit, the API will return a 429 Too Many Requests HTTP response code. Please contact Quiltt Support if your use-case requires higher limits.
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.
REST Endpoints that return a list of records can be paginated using query params. Use the limit query param to specify the number of items (default is 25), and the page query param to set the page number. For example, to get the second page of 50 profiles, you would make the following request:
GEThttps://api.quiltt.io/v1/profiles?page=2&limit=50All responses will return pagination information via the following headers:
REST API calls use standard HTTP response codes for success and failure notifications.
2xx HTTP codes indicate a successful request4xx HTTP codes indicate an issue with the request5xx HTTP codes indicate an unexpected errorUnsuccessful 4xx and 5xx requests will return a JSON body with the following response schema:
A generic error with troubleshooting instructions.
Returned with all 4xx or 5xx HTTP status codes, except 422 errors on some REST endpoints.
message:stringrequiredA high-level description of the error.
instruction:stringrequiredA helpful message to troubleshoot what went wrong.
errorId:stringThe unique ID associated with a 5xx server error, used for troubleshooting.
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 docs for more information.
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: