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 request4xx
HTTP codes indicate an issue with the request5xx
HTTP codes indicate an unexpected error
Unsuccessful 4xx
and 5xx
requests will return a JSON body with the following response schema:
message:
stringrequiredA high-level description of the error.Example: Not Authenticatedinstruction:
stringrequiredA helpful message to troubleshoot what went wrong.Example: Are you sending a valid API Key secret in the `Authorization` header?errorId:
stringThe 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
}
}