Spike · Rate Limits

Spike Api Rate Limits

Spike does not publish fixed numeric rate limits for its Application User API in the public documentation. Access is scoped per application (and per application user, authenticated with a per-user JWT), and practical throughput is governed by the negotiated plan and the volume of connected users rather than a published per-minute request cap. Data ingestion is largely event- and webhook-driven: providers push updates on their own cadence, Spike normalizes them, and then notifies the application via outbound webhooks - so most applications read on webhook triggers instead of polling. The webhook delivery path has an explicit, documented retry policy.

Spike Api Rate Limits is the machine-readable rate-limit profile for Spike on the APIs.io network, in the API Commons Rate Limits shape.

It captures 4 rate-limit definitions, measuring requests, records, and deliveries.

An exhausted limit returns HTTP 429.

This profile was written by API Evangelist and has not been verified against a page the provider published; treat every limit as unconfirmed until a dated transcription replaces it.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Health Data, Wearables, Digital Health, Rate Limiting, and Quotas.

4 Limits Exhausted: HTTP 429
Method: generated, dated 2026-07-03.
Written by API Evangelist on 2026-07-03 and not verified against a page the provider published. Treat every limit as unconfirmed until a dated transcription replaces it.
View Source
Health DataWearablesDigital HealthRate LimitingQuotas

Limits

Application User API Requests application
requests
not published
No fixed numeric request-rate limit is documented for the query/command endpoints.
Per-User Token Scope user
requests
not published
Each end user is authenticated with a distinct JWT; access is scoped to that user's data.
Provider Backfill / Historic Retrieval user
records
provider-dependent
Historic data retrieval depth and speed depend on each upstream provider's own API limits.
Webhook Delivery Retries application
deliveries
up to 10 retries per event
Non-200 responses, timeouts (>30s), or network errors trigger exponential backoff retries at 5s, 2m, 30m, 2h, then every 12h, up to 10 attempts.

Policies

Event-Driven Delivery
Spike pushes record_change, provider_integration_created, and provider_integration_deleted events via outbound webhooks, reducing the need for polling the query endpoints.
Webhook Retry with Backoff
Endpoints must return HTTP 200 within 30 seconds; otherwise Spike retries with exponential backoff up to 10 times.
Backoff Strategy
Clients of the query endpoints should implement exponential backoff with jitter and honor Retry-After on any 429 responses.

Sources

Work with this as data

Every rate limit here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for rate limits

4 MCP tools reach this
  • find_rate_limitsBrowse and filter every rate limit in the catalog.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This rate limit 
curl "https://apis.io/api/v1/rate-limits/spike-api-rate-limits"
All rate limits 
curl "https://apis.io/api/v1/rate-limits?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

GitHub Google LinkedIn

A second provider on the same verified email joins the account you already have.