Skip to main content

​
How requests are counted

Each executed root operation field is one API call. A GraphQL request that asks for four root fields is billed as four API calls, exactly as if you had made four REST requests. Aliases at the root count separately because each one dispatches an operation. Nested fields selected from a typed response do not add API calls.
One HTTP request, four API calls against your plan’s quota and rate limit. This is intentional and it is the honest model: each root field does the same work on our side as the equivalent REST call, so it costs the same. GraphQL saves you round trips and lets you fetch exactly what you need in one place; it is not a way to get more API calls than your plan includes. The practical consequences:
  • Your existing plan limits apply unchanged. See API limits for your plan’s allowance.
  • Asking for a root operation you do not need costs the same as calling it over REST. Selecting the nested response fields you need does not add calls.
  • A request can be rate limited partway through. Root fields that completed keep their data, and only the throttled root fields return errors — see Partial success.

​
Query limits

The endpoint enforces a few limits on the shape and size of a query. They exist so that a single request cannot consume an unreasonable amount of our capacity, and they are set well above what ordinary use requires — if you are hitting one, it is usually a sign of an accidentally generated query rather than a real need. A rejected query returns HTTP 400 if you send Accept: application/graphql-response+json, and HTTP 200 otherwise, with an errors array and no data in both cases. See Errors.

​
API calls per request

The important one. A single request can trigger at most 5 API calls, so the four-root-field example above is fine but a twenty-root-field one is not. Once five dispatches have started, additional root fields return a 429 explaining the limit; already-dispatched fields can still return their data. If you need more, split the query across requests. If you find yourself doing that routinely for a legitimate workload, get in touch — the limit is deliberately conservative for launch and raising it is straightforward, whereas lowering it later would break integrations, so it starts small.

​
Depth, fields and aliases

These are checked before anything runs, so exceeding one costs you no API calls at all. They are also comfortably clear of a full introspection query, which is around 180 fields and 12 levels deep with no aliases, so a client that fetches the entire schema on startup works normally.

​
Request body size

64 KB, which is generous for a query and far too small for a file. This is why media cannot be uploaded through GraphQL — see Uploading media for the supported path.

​
Timeouts

A request is given up to 120 seconds overall. Root fields in a query may run concurrently, so its duration is generally driven by its slowest dependency. Root fields in a mutation run serially, so several slow mutations can accumulate toward the timeout. Either form can still place up to five concurrent or sequential dispatches’ worth of load on the backend; split known-slow work when appropriate.

​
What is not limited

  • Reading the schema. Introspection is unauthenticated and unmetered. Browsing what exists is free; running an operation is not.
  • Malformed queries. A query GraphQL rejects — unknown field, wrong type, invalid enum value — never reaches our API and is never billed.
These limits are reviewed against real usage. If one of them is the wrong shape for a legitimate integration, tell us — that feedback is more useful than a workaround.