Usage and Quotas

Your workspace's plan includes a number of API gateway calls per billing month. This page is about what counts toward it, what happens when you reach it, and how to need fewer.

What counts

Every request the gateway processes: PraxQL queries and mutations, endpoint calls, MCP tool calls, end-user authentication, file downloads.

Two things do not count:

• Playground runs. Testing a query in the portal is free and unmetered.

• Anything rejected before the gateway processed it. A request that fails authentication is logged, but it did not do work.

Reading your usage

GET /{workspaceId}/usage returns the current picture, and the portal shows the same thing:

projectedCost is the field worth putting on a dashboard. It turns "we are using a lot of API" into a number somebody can react to before the invoice does it for them.

What happens at the limit

One setting, two very different outcomes.

Block — requests are refused with 429 once the quota is spent. Your costs cannot exceed the plan, and your integrations stop. Correct for internal tooling, a staging workspace, or anything where a surprise bill is worse than a surprise outage.

Pay-as-you-go — requests keep working and the excess is billed as overage. Your integrations cannot be taken down by a traffic spike, and your bill can grow without anyone approving it. Correct for anything customer-facing.

There is no third option that is both, so choose by asking which failure you would rather explain: an outage, or an invoice.

A retry loop is the case that hurts under either setting. Under Block it consumes the remaining quota in minutes and takes down everything else; under PayAsYouGo it bills for every attempt. That is what makes the 429 filter in the Logs tab worth checking periodically rather than only when something breaks.

Using fewer calls

Three levers, in the order they usually pay off.

1. Ask for more per call

PraxQL was designed so one request can answer what REST would need several for. A customer with their orders and each order's items is one query with nested relations, not one plus N plus N×M. If your call count is high and your page count is not, this is usually why.

Relations are batched, so nesting costs one extra query per level — not one per row. See Relations.

2. Cache on the credential

A credential can cache its own query responses:

WriteInvalidated is the interesting one: it cannot serve stale data after a write your own workspace performed. Its blind spot is data changed by something the gateway did not see, which is exactly what Hybrid covers.

Because caching is per credential, a read-heavy public key can cache aggressively while your backend key does not cache at all — the same query, two different policies.

A cache can be purged for one credential, or for every credential touching a given table, from the portal.

3. Cache on the endpoint

Endpoints have their own cache with the same modes, plus two things a credential cache does not have: the request body is always part of the key, and callers sending If-None-Match get a 304 with no payload at all.

Never cache an endpoint that writes. A cached side effect means the second caller receives the first caller's answer and their write never happens.

Before you raise the plan

Check the Logs first. High usage is often one of these, and none of them is fixed by a bigger quota:

• A client polling on a timer that could be listening to the Event Bus instead.

• A retry loop against an endpoint that has been failing for days.

• A page issuing one query per list item instead of one query with a relation.

• A cron job running far more often than the data it reads changes.

Filter the log by credential, sort by count, and the answer is usually the top row.

Next

• Logs — where the calls behind these numbers are.

• Credentials and Principals — where the per-credential cache is configured.