My GraphQL integration is being throttled but I am barely making requests. Why?
GraphQL APIs usually meter query cost, not request count. Every field, connection and nested page carries a point value, and a single deeply nested query can consume more budget than hundreds of REST calls. You are hitting a complexity ceiling or a points-per-minute bucket, not a request ceiling. Shrink the selection set, request smaller nested pages, and read the cost information the API returns with each response.
Cost is computed before your query runs
Most GraphQL gateways estimate a query's cost from its shape: roughly the number of fields multiplied out by the page sizes you requested at each level of nesting. Ask for one hundred customers, each with fifty jobs, each with twenty line items, and the estimator prices that as if every node will be returned — even if the real answer is a handful of rows.
That is why an integration making four requests a minute can be throttled while one making four hundred small REST calls is not. The meter is measuring something different.
Read the numbers the API is already giving you
Nearly every cost-metered GraphQL API returns its accounting in the response, usually in an extensions block: requested cost, actual cost, and how much budget remains in the bucket. Log it on every call. Within a day you will know exactly which query shape is expensive, which is a far better diagnostic than adding delays and hoping.
The gap between requested and actual cost is the most useful figure. A large gap means you are being charged for rows you never receive, and the fix is asking for smaller nested pages rather than making fewer requests.
The counterintuitive fix
The instinct when throttled is to slow down. With cost metering, the better move is usually to split one large query into several small ones. Three shallow queries frequently cost less in total than one nested query returning the same data, because the estimator's multiplication is what hurts you.
Flattening also makes retries cheaper. When a deeply nested query fails, you re-pay the whole cost; when a shallow one fails, you re-pay a slice.
When REST is simply the better tool
GraphQL earns its keep when you need a narrow slice of a wide object graph and want to avoid many round trips. It works against you for bulk extraction, because bulk extraction is exactly the shape the cost model penalizes. If the vendor offers a REST bulk endpoint or a report export alongside GraphQL, use it for the heavy pull and keep GraphQL for targeted lookups.
Choosing per-workload rather than per-vendor is a normal part of integration design, and it is one of the first things we benchmark when connecting a new system into an intelligence platform.
Topics: GraphQL · rate limits · API design · throttling
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.