# API Overview
URL: https://www.quiltt.dev/api
Description: Get a comprehensive understanding of Quiltt's hybrid API, featuring both GraphQL and REST endpoints, to power your financial data interactions securely.
Content Length: 6k characters

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 REST API endpoints to handle authentication and administration concerns.

## Schemas and Reference

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

Page Index:

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 REST API, you can access the OpenAPI specification here:

- [https://api.quiltt.io/latest/rest.yaml](https://api.quiltt.io/latest/rest.yaml)

These can be used with OpenAPI-compatible tools like Postman, [openapi-generator](https://github.com/OpenAPITools/openapi-generator) or [openapi-typescript](https://github.com/openapi-ts/openapi-typescript/tree/main/packages/openapi-typescript) to generate client libraries, typings and more.

## 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:

```yaml
Content-Type: application/json
```

## Versioning

When we make breaking changes to our API, we release a new version. The current version is `2026-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:

```yaml
Quiltt-Version: "2026-04-01"
```

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

See the [API Version Upgrade Guide](/api/version-upgrade-guide) for details on what changed between versions and how to migrate.

## Rate Limits

Quiltt uses a fixed window counter for rate limiting. Request counts reset at the start of each second.

Most API calls are subject to the following rate limits:

- Authenticated requests (via API Key, Basic Auth or Session Tokens) are limited to **100 per second**.
- All other requests are limited to **25 per second**.

> **Note:** Legacy API keys without the `qltt_` prefix are subject to the 25 req/sec limit. Generate a new API key in your Dashboard to access the higher rate limit.

You can access your current request budget in the headers of each response:

```yaml
Ratelimit-Limit: "100"
Ratelimit-Remaining: "99"
Ratelimit-Reset: "1741161600"
```

### Session Tokens

Additionally, a separate per-Profile rate limit applies when [Issuing Session Tokens](/authentication/issuing-session-tokens). For each Profile, you can issue a maximum of:

- **10 active Session tokens per hour**
- **20 active Session tokens per day**

Note that 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](https://www.quiltt.dev/authentication#basic-auth), which is not subject to this rate limit.

### Exceeding Rate Limits

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.

## Pagination

### Pagination in GraphQL

The GraphQL API uses [Relay-style cursor-based pagination](https://relay.dev/graphql/connections.htm) to support efficient and flexible querying of large lists like Transactions.

See the [GraphQL Pagination guide](/api/graphql/pagination) for more information.

### Pagination in REST

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:

API Endpoint - GET https://api.quiltt.io/v1/profiles?page=2&limit=50:

All responses will return pagination information via the following headers:

```yaml
Current-Page: "3"
Page-Items: "25"
Total-Count: "114"
Total-Pages: "5"
```

## Errors

### 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 docs](https://graphql.org/learn/validation/) for more information.

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

Code Examples:

  ```json
{
  "data": ["account": null],
  "errors": [
    {
      "message": "No Account found for `id: \"acct_123\"`",
      "path": ["account"],
      "extensions": [conditional content]
    }
  ]
}
```
  ```json
{
  "data": {
    "profileUpdate": {
      "success": false,
      "record": null,
      "errors": [
        ["path": ["attributes", "email"],
          "message": "Email is not a valid email address"]
      ]
    }
  }
}
```

### Errors in REST

REST API calls use canonical 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:

REST Error Schema:

We recommend logging unsuccessful responses to help diagnose issues. When reporting unexpected errors to Quiltt Support, please make sure to send us the `requestId` and `errorId` values from the JSON response.