> This page is for Partner API. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.getmodulate.dev/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.getmodulate.dev/_mcp/server. # Service levels > What we commit to, what we measure, and how to reach us when something breaks The Modulate Partner API is a **production API**. It is operated and monitored around the clock and backs live partner integrations. It is not covered by a contractual service level agreement (SLA): the commitments on this page describe how we run the service, not service credits. ## Commitments | Area | Commitment | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Breaking changes** | At least **30 days' notice** before a breaking change to a documented endpoint, field, or parameter. Deprecations are marked in the OpenAPI specification and announced before removal. | | **Planned maintenance** | Advance notice by email to your organization's technical contacts. We schedule maintenance outside US business hours wherever possible. | | **Support response** | Acknowledgement within **1 business day** at [it@flute.com](mailto:it@flute.com). If **every data endpoint is failing** for your key, we acknowledge the **same business day**. | A breaking change removes or renames a field, endpoint, or parameter, changes a field's type or meaning, or makes a previously optional input required. Adding endpoints, optional parameters, response fields, or enum values is not breaking; build your client to ignore fields it does not recognize. Deprecated parameters keep working until their removal date. For example, the `timezone` parameter on transaction endpoints is deprecated: it is still accepted but ignored, because transaction dates are processor business dates with no time of day. ## Service level objectives These are the targets we run the service to. We measure them continuously and review them monthly; they are operating objectives, not a contractual SLA. | Objective | Target | How it is measured | | -------------------------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Availability** | **99.5%** per calendar month | Share of authenticated requests that do not return a `5xx` status or time out, cross-checked against probes we run every five minutes from outside our network. `429` and other `4xx` responses count as available: they are answers about the request, not failures of the service. | | **Latency: account and merchant reads** | 95th percentile **under 2 seconds** | `/me`, the merchants list, merchant detail and processor profiles. | | **Latency: single-merchant warehouse reads** | 95th percentile **under 8 seconds** | One merchant's transactions, TSYS pricing, authorizations, chargebacks and statements. | The objectives apply to requests within your [rate limit](/partner-api/overview/getting-started/introduction#rate-limits). Portfolio-wide warehouse pages (the same reads without a merchant ID), exports and `POST .../explain` (AI) calls have no latency objective; they count toward availability. Plan around what the API does today: * **Warehouse-backed endpoints take seconds, not milliseconds.** Transactions, TSYS pricing, chargebacks and residuals query our data warehouse. Single-merchant calls typically complete in a few seconds and portfolio pages can take longer. Set client timeouts of at least **60 seconds**. * **Prefer portfolio endpoints for bulk pulls.** One call to `GET /api/partner/pricing/tsys` or `GET /api/partner/transactions` (up to 90 days, up to 100 rows per page) replaces hundreds of per-merchant calls and stays well inside your [rate limit](/partner-api/overview/getting-started/introduction#rate-limits). * **Narrow the window instead of paging deeper.** Transaction pages reach the first 500,000 rows of a query, authorization pages across more than one day reach the first 500,000 rows (50,000 with `approved` or `card_type`), and the portfolio statement list takes `year` and `month`. A request past a limit returns `422 VALIDATION_ERROR` naming the parameter to change; pull large portfolios one day (or one month of statements) at a time. * **Retry what we mark retryable.** Every error carries a boolean `retryable`. Retry `retryable: true` errors (including `503 SERVICE_UNAVAILABLE`) with exponential backoff; do not retry `retryable: false` errors unchanged. ## Data freshness The API serves data as soon as it is loaded from processor files; we do not promise a clock time for new data yet. * Merchant records carry `last_data_refresh`, the time our merchant directory last synced from our system of record (hourly). * Transactions, pricing, deposits and chargebacks follow processor batch ingestion. The most recent processing day can be incomplete until the processor's files for that day have loaded, so re-pull a trailing window (for example the last 3 days) on each run rather than only the newest day. ## When something breaks Email [it@flute.com](mailto:it@flute.com) with: 1. The `meta.request_id` from the failing response (every response includes one). It is the fastest way for us to find your request. 2. The endpoint and parameters, with the time of the request in UTC. 3. The HTTP status and the `errors[].code` you received. Never include your API key in a support request. If a key may have been exposed, tell us at [it@flute.com](mailto:it@flute.com) immediately so we can revoke it and issue a new one.