Skip to main content
Limits are per token, per minute, in three buckets: Messaging is separate and far tighter because those calls spend real money and land in somebody’s inbox: a runaway loop against /reminders/:id/send is a different kind of incident from a runaway loop against /members.

​
Every response carries your budget

RateLimit-Reset is seconds until the window rolls over. A 429 adds Retry-After, also in seconds:

​
Some requests cost more than one

A request is priced by the work it asks for, not by being one HTTP call. Reading a chapter’s roster costs ceil(limit / 25) units, so a page of 100 members costs 4:
That’s deliberate: a national syncing 200 chapters at 100 rows a page is 800 units of database work whether or not it looks like 200 requests. Pricing it this way means the limiter stops a runaway sync, rather than the database. Requesting smaller pages does not save you anything — 4 pages of 25 costs the same 4 units as 1 page of 100 — so prefer large pages and fewer round trips.
A malformed request still costs a unit. Otherwise sending garbage would be a free way to hammer the API.

​
Backing off

On a 429, sleep for Retry-After seconds and retry — with jitter if you run more than one worker, or they’ll all wake up together and collide again.
Better still, watch RateLimit-Remaining and slow down before you hit zero.

​
Seeing your usage

Each token’s card in the dashboard shows its requests over the last 14 days, its busiest endpoint and its failure rate, broken down per day. Usage is counted by route template, so a 200-chapter sync appears as one endpoint with 200 requests rather than 200 separate paths. That view is the fastest way to answer “what is this integration actually doing?” before an organization’s admins decide whether to keep it.