Limits and quotas

jsonpad meters two things: how many requests you make in a calendar month, and how many bytes you have stored. Everything else on your plan is a guard rail against a runaway loop rather than something you should need to design around.

If you are writing a client or an agent that talks to jsonpad unattended, this is the page to read: the response headers below are what let it pace itself, and the degradation behaviour is what lets it keep working when it runs out.

What counts as a request

Every API call authenticated with an API token counts as one request against your monthly allowance, regardless of method or response status.

Two things do not count:

  • Requests made by the jsonpad dashboard while you are signed in. Browsing your own data through the website is free.
  • Requests that fail with a 5xx status. If we break, you get the request back.

Realtime websocket messages are not metered either. Instead, each plan caps how many concurrent realtime connections a single account may hold open; a connection beyond that cap is refused at connection time.

Response headers

Every metered response carries the four headers below, alongside the existing x-rate-limit-total and x-rate-limit-remaining, which describe the per-minute rate limit rather than the monthly allowance.

  • x-quota-total25000The request allowance for the current month, excluding any overdraft and any prepaid credits.
  • x-quota-remaining18342How many requests are left before writes start being refused. This includes your plan's overdraft and any prepaid credits you hold, so it can be larger than x-quota-total.
  • x-quota-credits0How many prepaid requests you currently hold. These never expire and are only drawn down once the monthly allowance and overdraft are gone.
  • x-quota-reset2026-10-01T00:00:00.000ZAn ISO 8601 timestamp for when the allowance next resets.

What happens when you run out

We email you once, when you cross 80% of your allowance. There is no second email at 90%.

At 100%, in order:

  1. On a paid plan you enter a 10% overdraft, and nothing changes. The free plan has no overdraft.
  2. Past the overdraft, any prepaid request credits you hold are drawn down. Again, nothing changes until they run out.
  3. Once those are gone, GET, HEAD and OPTIONS requests keep working, but at the free tier's rate limit. Every other method returns
    429 Too Many Requests
    with the error code QUOTA_EXCEEDED and a retry-after header.

In other words, your application degrades to read-only rather than going dark. Whatever you have already stored stays readable.

{
name: "QUOTA_EXCEEDED"
code: 10013
message: "Monthly request quota exceeded. Your allowance resets at 2026-10-01T00:00:00.000Z. Read requests st..."
}

Buying a prepaid request pack takes effect immediately and does not change your plan.

When the allowance resets

At 00:00 UTC on the first of each calendar month, not on your billing anniversary. Free accounts have no anniversary, and a fixed reset date means an upgrade never has to prorate your allowance.

Prepaid credits carry over. Unused monthly allowance does not.

Storage

Each plan has a total storage allowance covering the JSON data of every item in every one of your lists. Stored bytes are recalculated once a day rather than on every write, so the figure you see on your dashboard can be up to a day behind.

If you are over the allowance, reads keep working and writes return

403 Forbidden
with the error code STORAGE_LIMIT_EXCEEDED until you delete some data or move up a plan. Nothing is ever deleted for you.

Rate limits

Separately from the monthly allowance, each plan limits how fast you can make requests: a maximum number of requests per minute, and a minimum gap between consecutive requests. Exceeding either returns

429 Too Many Requests
with the error code RATE_LIMIT_EXCEEDED and a retry-after header telling you how long to wait.

Rate limits exist to stop one account degrading the service for everyone. They are not something you should have to plan around: if you are hitting them during normal operation, add a short delay between requests rather than retrying immediately.

Version history

Each plan retains a number of versions per item. Older versions remain in the event log — we never delete event history — but they can no longer be fetched back through the version query parameter, and requesting one returns

410 Gone
with the error code ITEM_VERSION_NOT_RETAINED.

What is not limited

Lists, items per list and indexes per list are uncapped on every plan, including free. In practice what you can store is bounded by the storage allowance rather than by a count.

Every feature is available on every plan too: JSON schema validation, version history, JSON Patch, JSON Pointer, JSON Path, realtime updates and identities. You never need to move up a plan to unlock a capability — only to get more volume.

The current numbers for each plan are on the pricing page.