Service levels | Modulate API

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. 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. 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.
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 with:

The meta.request_id from the failing response (every response includes one). It is the fastest way for us to find your request.
The endpoint and parameters, with the time of the request in UTC.
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 immediately so we can revoke it and issue a new one.