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, conforming to the API Commons Rate Limits specification.

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

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 Throttle: 429
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