The Starlink Enterprise API enforces 250 requests a minute per account, as a sliding window, and 1,000 bearer token requests per 15 minutes per client IP address. A request over the limit returns HTTP 429. Starlink’s own advice for frequent access is to sync data into your own database on a schedule, where the rate limits no longer apply (rate limits).
What exactly is limited?
Two limits apply:
- API requests: 250 a minute per account. The account is the Starlink account the service account belongs to. Every public endpoint draws on the same budget.
- Token requests: 1,000 per 15 minutes per client IP address, on the token endpoint. Tokens last 15 minutes and should be reused until they expire, not requested per call.
What does the limit mean for an estate?
The limit is per account, so each account brings its own budget. An integration that serves many accounts can spread its calls across them. Within one account, 250 requests a minute is generous for a schedule and tight for a dashboard that calls the API on every page view.
Large calls help. The usage query returns many service lines per request, page by page, so an account’s usage costs a few requests, not one per service line (data usage).
Why sync rather than call?
Starlink states the trade-off directly: the API “is provided to manage accounts, user terminals, and service”. For frequent, low-latency or more expressive queries, it recommends “setting up a job to periodically sync data to your own database”.
A sync gives three things a live call cannot:
- Screens that never wait on Starlink. Every view reads the local store.
- A predictable request rate, set by the schedule, not by how many people are looking.
- History. Usage beyond six previous billing cycles exists only if it was stored.
How should an integration handle a 429?
- Stay below the ceiling. Budget a margin under 250 a minute, so a burst never reaches the limit.
- Back off on 429. Starlink’s instruction is to reduce the request rate. Retry with increasing delays rather than at once.
- Cache tokens. Request a new token only after a 401, never per call.
- Keep writes ahead of reads. When the budget is tight, a change a person asked for matters more than a background refresh.
What should a platform get right?
- A synchronised store, so screens never spend the rate limit.
- A schedule that fits inside each account’s budget, with a margin.
- Backoff on 429 and token reuse built in.
- Large accounts handled by paging, not by one call per service line.
How does Nexus Telemetry Enterprise approach this?
Nexus Telemetry Enterprise syncs every connected account into its own store on a schedule, as Starlink recommends, and serves every screen from that store. Its requests stay within each account’s budget, with backoff when Starlink asks for it.
Where do you start?
Count the requests your current integration makes per account per minute at its busiest, including any made per page view. If screens call the API directly, a sync to your own database is the first change to make. The complete guide covers the rest of what a platform needs.