Changelog

1 October 2026

Added

• An MCP server for the API. AI assistants and coding agents can add https://mcp.jsonpad.io/api, with one of your API tokens, to build and run a backend on your account: create lists, indexes and write rules, read and change items, plan and apply schema sync documents, find out why a write was refused, restore items from their history, and call your flows. It can only do what its token can, and it's careful: it won't overwrite changes your app made in the meantime, won't delete values a guard index hides from it, and asks before anything that can't be undone. It's also an npm package, @basementuniverse/jsonpad-mcp, for running it locally. See MCP servers.
• Connect apps with OAuth. Add the API MCP server with just its URL (in Claude Desktop and on claude.ai, as a custom connector): your agent opens a JSONPad page where you see which app is asking, choose what it may do (read only, read and write, or everything, optionally for some of your lists) and when its access ends. Allowing creates an API token for it, tagged oauth, which you can delete at any time to take the access away.
• After logging in, you're taken back to the page you were trying to open, rather than the dashboard.
• Three new error codes for the consent page: OAUTH_CLIENT_INVALID (24001), OAUTH_REDIRECT_URI_INVALID (24002) and OAUTH_REQUEST_INVALID (24003).

30 September 2026

Added

• An MCP server for the docs. AI assistants and coding agents can add https://mcp.jsonpad.io/docs to search and read these docs, look up the exact contract of any API endpoint, SDK method, command line tool command or error code, and check the write rules, flows, schema sync documents and token permissions they write for you, with the same engines the API uses, before you save them. It's free, needs no account, and can't see your data. It's also an npm package, @basementuniverse/jsonpad-docs-mcp, for running it locally. See MCP servers.

29 September 2026

Added

• Run a flow has its own page in the API reference: parameters, headers, input, responses and errors for https://api.jsonpad.io/flows/<path> and public flows. See run a flow.
• The JSON schemas for flow documents, flow tests and write rules tests are published at https://jsonpad.io/schema/flows-v1.json, flow-tests-v1.json and rules-tests-v1.json, next to sync-v1.json, so editors can autocomplete and check those files too.

Changed

• includeData, path, includeGuarded and generate are now reserved index path names, because they're query parameters on the item endpoints. An existing index with one of these names keeps its values, but items can no longer be filtered or sorted by it, so rename it to use it that way.
• The errors page lists USER_NOT_AUTHENTICATED (11002) and USER_NOT_AUTHORIZED (11003).

Fixed

• The markdown version of a documentation page (its URL with .md on the end) showed write rules examples as numbered lines run together (1allow update, delete: ...), with operators escaped. They're now code blocks, marked jsonpad-rules.
• In the markdown version of the errors page, each error's name ran into its HTTP status (QUOTA_EXCEEDED429 Too Many Requests). They're now written ` QUOTA_EXCEEDED (10013, 429 Too Many Requests) `.
• The errors page called error 10000 UNKNOWN (it's UNKNOWN_ERROR), and filed the schema sync errors under identity errors; they have their own section now.
• The "guard indexes" link in the description of includeGuarded, on every item endpoint's page, went to a page that doesn't exist.
• The "Registering and authenticating" section of the authentication guide couldn't be linked to, because its anchor had spaces in it.

27 September 2026

Added

• Flows. A flow is a small program you draw in the dashboard instead of writing: a graph of steps that read and write items in any of your lists, check who's asking with require steps, branch, loop over arrays, and respond. Expressions are written in the write rules language. The new Flows page in the dashboard has the graph editor, templates, a test runner that rolls everything back, stored tests that must pass before a flow is saved, and a log of each flow's last 100 runs. A flow costs what the same API calls would: a call or an event run is one request, and each item it reads or writes is one more. Each plan allows a number of flows: 2 on Free, 10 on Indie, 50 on Pro and 250 on Scale. See flows.
• Endpoint flows are called by your app at https://api.jsonpad.io/flows/<path>, with a token that has the new run permission (or run-with-identity). Everything a run writes happens together, or not at all, so a flow can take stock only if there's enough, or deal the top card of a hidden deck. A flow can also be public, and called without a token. The JavaScript SDK has runFlow().
• Event flows run shortly after items are created, updated, restored or deleted in the lists they watch, one event at a time for each item, with old and new to compare. Runs that can't finish are retried, flows that start flows stop three deep, and a flow that keeps failing is turned off. See event flows.
• Flows in git. Declare flows in a schema sync document, and the command line tool checks, tests, syncs and calls them (jsonpad flows check, test and run). See keeping flows in git.
• Emitting to webhooks from a flow. A flow's emit step sends a flow.emit event to webhooks you choose, once the run has committed. Webhooks for changes a flow made say so in their actor.
• Lookups in write rules. Rules can now read other items: lookup("customers", new.customerId) gives the item (its data and metadata) or null, and exists(...) checks there is one. So a rule can check that a reference points at something real, or ask another item who may write ("only the game's players can post moves"). Lookups read as the list's owner, guarded values included, so a rule can check a guess against an answer the client never sees. A write can look up at most 10 different items, and each item read counts as a request, as the same GET would. A lookup in a list that doesn't exist fails closed, and saving rules warns about such lists. Rule tests can list items for lookups to find, and the rules dry run reports what it read. Because rules that look up a list can read it, an API token can only save rules that look up lists it has update permission on. See looking up other items.
• Shuffling, sampling and picking. Three new variables, $jsonpad-var:random-shuffle, random-sample and random-pick, work on an array in the item's data (or on values you list), using a cryptographic random source the client can't predict or choose: deal a deck, assign teams, pick who goes first. See variables.

23 September 2026

Added

• Webhooks. JSONPad can tell your own server when items change. Create a webhook on the new Webhooks page in the dashboard, choose the events (item.created, item.updated, item.restored, item.deleted) and the lists to watch, and each change is sent to your URL as a signed POST request. Updates include the item as it was before the change, so your server can tell what changed. Deliveries are signed (x-jsonpad-signature), retried for about a day if your server is unavailable, and listed on the webhook's page with your server's response, where you can send a test ping or redeliver any event. Each plan allows a number of webhooks (1 on Free, 5 on Indie, 20 on Pro, 50 on Scale), and deliveries don't count as requests. See the new webhooks guide.
• Conditional writes. Send an item's ETag in an if-match header when you update, restore or delete it, and the write only happens if nobody else has changed the item since you read it. Otherwise nothing is written and the API returns 412 Precondition Failed (ITEM_PRECONDITION_FAILED), so two clients editing the same item can no longer silently overwrite each other's changes. Every item write returns the new ETag to use next time. See conditional writes.
• Write rules. A list can now say what API tokens are allowed to write to it, in a few lines of text checked on every create, update and delete. allow decides who may write (a write nothing authorises is refused with 403), and require decides what they may write (a failed check is a 400 with the message you wrote). Rules read the data before and after the write, the item's owner, the identity and token making it, and the server's clock, so they can express what token permissions and JSON schema can't: only the owner may edit this, this field can never change once set, this counter can only go up by one, this player may only move on their turn. That's what lets a browser or game client talk to JSONPad directly, with the rules enforced on our side. See the new write rules guide, the language reference and the recipes.
• Shared items. A list's rules can declare shared update, delete;, which lets several identities write the same item instead of only their own, with the rules deciding who may. It's what a game, a shared document or a chat room needs.
• A rules editor and playground on each list's new Rules page. It highlights and checks the rules as you type, suggests field names from your list's schema, and runs a candidate write beside them, showing every part of every rule and what it evaluated to. Templates and a quick-rules form write the common cases for you.
• Rule tests are saved with a list's rules and run every time either is saved, so a change can't quietly break something you'd already checked. They run in the dashboard while you type, and offline in the command line tool.
• Rules in your repository. Rules and their tests can live in files beside your schema document and deploy with it, and jsonpad rules check, test and eval check them in CI without making a request.
• A log of refused writes: the last 50 per list, with which rule refused each one, on the rules page in the dashboard and at GET /lists/:list/rules/denials.
• Writes to a list with rules re-read and lock the item before saving, so two clients that race can't both win: the second is refused with 409 ITEM_CONFLICT and can fetch the item again and retry.

Fixed

• Creating or updating an item failed with ITEM_UNABLE_TO_CREATE / ITEM_UNABLE_TO_UPDATE ("unknown error") when a value at an indexed pointer was longer than 1024 characters, and building an index over such a value failed too. An index now stores the first 1024 characters (or 2048 bytes of UTF-8, whichever is shorter) of a long value, so filtering, sorting and searching work on the start of it. Alias values still have to be stored in full to stay unique, so an item write with an alias value over the limit is refused with a message naming the index, and an alias index can't be built, or turned on, while an item has one. See long values.

18 September 2026

Added

• Password reset and email verification for identities. Your app can request a single-use password reset token for an identity (POST /identities/password-reset, by id, name or email) and send it to them, e.g. as a link in an email. The page the link opens sets a new password with POST /identities/password-reset/confirm, which logs the identity out everywhere. Email verification works the same way (POST /identities/email-verification and .../confirm). JSONPad never sends email itself: the email comes from your app, with your own branding. Tokens are URL-safe, single-use, and expire after 1 hour (reset) or 1 day (verification) by default. Requesting a token needs the new reset-password or verify-email token permission. See the new password reset guide.
• Webhook token delivery. An identity group can send reset and verification tokens to a webhook instead of returning them. The request then always responds 202 { "delivery": "webhook" }, so it can be made straight from a browser, and apps without a server can send emails from a serverless function or a no-code tool. Deliveries are signed (x-jsonpad-signature), retried when your webhook is unavailable, and recorded as events. The dashboard can send a test delivery.
• Identity groups. Groups now have settings, managed on the new Identity groups page in the dashboard: how long sessions last, whether an email address is required, token lifetimes, and token delivery. Groups are still created automatically the first time an identity uses one, and existing groups keep their current behaviour. See identity groups.
• Email addresses on identities. Identities can have an email address (unique within their group, ignoring case), and can log in with it instead of their name. Email addresses are only returned to the account owner and to the identity itself, never in token auth mode listings or identity events.
• Logging in on several devices. Each login creates a new session, so logging in on one device no longer logs an identity out on another. POST /identities/logout with { "all": true } logs out everywhere, and so does the new Log out everywhere button on an identity's dashboard page. GET /identities/self includes sessionCount.
• Sign in with Google or GitHub. Identities can sign in with an account they already have, instead of (or as well as) a password. Your app lists the providers you've enabled (GET /identities/oauth/providers), starts a sign-in (POST /identities/oauth/:provider/start) and finishes it on the page the provider returns to (POST /identities/oauth/complete), which logs in the identity linked to that account, or creates one. A logged-in identity can link and unlink accounts of its own, and its last way of signing in can't be removed. Set a provider up for an identity group in the dashboard: it walks you through creating the OAuth app, pasting the client ID and secret (checked with the provider as you save them), and a test sign-in that shows exactly what the provider sent back. See the new OAuth guide, and the Google and GitHub setup guides.
• Sign-ins can return to your app's own page, or go through JSONPad's callback URL, which passes them on to whichever of an identity group's redirect URLs started them. That way one callback URL at the provider covers production, staging and localhost.
• Sign in with Microsoft, Discord and Facebook, alongside the others. Microsoft can be limited to one organization with a tenant ID, and its client secrets expire (the guide says where to look). JSONPad never trusts a Microsoft or Facebook email address — an administrator can set any address on an account in their own Microsoft tenant, and Facebook doesn't say whether it has checked one — so identities created with them have no email address until they add one. Each provider has its own setup guide: Microsoft, Discord and Facebook.
• Sign in with Apple, alongside Google and GitHub. Apple needs a paid developer account, a Services ID and a .p8 key, which the dashboard takes (and encrypts) in the same wizard; JSONPad signs the short-lived client secrets Apple asks for. Apple posts its result back as a form, so its sign-ins always come through JSONPad's callback URL, which means localhost return pages work even though Apple won't accept them. Apple only sends someone's name the first time they sign in, and private relay addresses count as verified. See the Apple setup guide.
• The dashboard's identity page lists the accounts an identity can sign in with, and can unlink them, e.g. to help someone who has lost access to one.
• The dashboard's identity page can issue password reset and email verification tokens for an identity, e.g. to help someone who can't get into their account.

Changed

• Breaking: changing an identity's own password or email address with PUT /identities/self now needs its current password in currentPassword (unless the identity has no password). This stops someone who has got hold of an identity token from locking the real owner out.
• Breaking: new identity passwords must be at least 8 characters, and at most 72 bytes, long. Existing passwords still work.
• Setting a new password for an identity from the dashboard or the API logs it out everywhere. When an identity changes its own password, its other sessions end.
• New identity groups' sessions expire after 30 days (configurable per group). Groups that already exist keep sessions that never expire.

Fixed

• Deactivated and locked identities could still log in, and their existing identity tokens kept working.
• The failed-login delay for an identity kept doubling with no upper limit. It's now capped at 30 seconds.
• Fetching a single event by id refused several kinds of event that the event list returns: an index's build events (GET /lists/{list}/indexes/{index}/events/{event}), and an identity's password reset, email verification, self-update and linked account events (GET /identities/{identity}/events/{event}). Anything the list returns can now be fetched on its own.

16 September 2026

Added

• Schema sync. POST /sync-schema takes a document describing your lists and their indexes, keyed by path name, and creates or updates the account to match. Nothing is deleted unless you ask it to prune (see below). ?dryRun=true returns the plan (what would be created, updated or left alone, field by field) without applying it. A sync is all or nothing: if any change would be refused, nothing is written. Changing an index's pointer in a list that has items makes the index unusable until it has been rebuilt, so it needs ?allowRebuild=true. A document can name a scope (e.g. your app's name): its lists are tagged with it, and a list managed by one scope can't be changed by a document with another. Tokens need the new sync-schema permission action, plus the usual permission for each change. GET /sync-schema exports existing lists and indexes as a document (optionally only a scope's lists, lists with certain tags, or lists by path name), which is the easiest way to start using schema sync on an existing account. The JS SDK has syncSchema() and exportSchema(), and a jsonpad command line tool (npx @basementuniverse/jsonpad-sdk sync-schema) for deploy scripts and CI. Documents can point editors at the JSON schema at https://jsonpad.io/schema/sync-v1.json for autocomplete. See the new schema sync guide.
• Schema sync pruning. POST /sync-schema?prune=true also deletes the lists and indexes a scope manages that its document no longer declares. Only resources a previous sync with the same scope declared are deleted: a list that has been renamed or has lost the scope's tag since, and anything created by hand, is left alone and reported with a warning. A list's indexes are only pruned if its definition has an indexes key. Deleting a list that has items, or a guard index, needs ?allowDestructive=true, and a prune that would delete every list in the scope is refused. Tokens need permission to delete each list and index. Deletes show up in the plan (and in dry runs) with the delete action, and are logged as list-deleted / index-deleted events with the sync's id. The JS SDK's syncSchema() and the jsonpad sync-schema command have matching prune and allowDestructive options. See pruning.
• Moving lists between scopes. POST /sync-schema/move moves lists (by id or path name) to another scope, assigns lists that no scope manages to one, or releases lists from their scope with "scope": null. Pass "fromScope" instead of "lists" to move every list a scope manages, e.g. to rename it. The scope's tag moves with each list. A moved list keeps its indexes managed; an assigned list's indexes are adopted by the next sync that declares them. Like a sync, a move is all or nothing, supports ?dryRun=true, and needs the sync-schema permission plus permission to update each list. The ownership conflict error now says how to move a list. The JS SDK has moveLists(), and the command line tool has jsonpad move-lists. See moving lists between scopes.
• A list's page in the dashboard shows which schema sync scope manages it, and has a button to move it to another scope, assign it to one, or release it. You see what will change before it's applied.
• Show jobs in the dashboard, including their status and progress.
• Index rebuilds. POST /lists/{list}/indexes/{index}/rebuild starts a new build for an index whose last build failed, once the problem has been fixed. Failed builds are never retried automatically. The dashboard's background jobs menu has a rebuild button on failed index builds, and the JS SDK has rebuildIndex(). Rebuilding an index that isn't failed is refused with INDEX_BUILD_NOT_FAILED (16008), and each rebuild logs an index-build-requested event.
• Code examples in the dashboard. The code button on list, item, index, identity and event pages now opens a Code tab next to the raw JSON, with cURL, fetch and JS SDK examples for fetching, updating and deleting that resource. The examples use its real ids and, where there's a request body, its current values. Pick one of your tokens to fill it in; the choice is shared with the documentation's token selector.
• The command line tool has its own package. jsonpad is now @basementuniverse/jsonpad-cli, and it does a lot more than schema sync: manage lists, indexes, items and identities, search, read stats and event history, restore items, export and import a list's items, act as an identity, and watch realtime events. It saves tokens as profiles on your own machine, prints tables in a terminal and JSON in scripts, and has shell completion. The schema commands work exactly as before, so to switch, run npx @basementuniverse/jsonpad-cli sync-schema in place of npx @basementuniverse/jsonpad-sdk sync-schema. The JS SDK's own command is deprecated, and will be removed in SDK 2.0.0. See the new command line tool guide.

Fixed

• An existing index can now be made the alias index with PUT /lists/{list}/indexes/{index} (or from the dashboard). Previously this was always refused with "list already has an alias index", even when the list had no alias index.
• Turning alias on for an existing index is refused if more than one item already has the same value at its pointer, since alias values have to be unique. If the index is still being built, the build checks the values when it finishes.
• Refusing to make an index the alias because the list already has one now reports "Unable to update index" rather than "Unable to create index".
• Copying a code example from the documentation copies ordinary spaces, so copied shell commands and YAML work when pasted.
• The dashboard's page for an identity or subscription event no longer fails to load, and the event log can be filtered to identity and subscription events.
• The markdown version of a documentation page (its URL with .md on the end) now includes every language of each code example, rather than only the first.
• The documentation's identity login, identity register and "patch partial item data" cURL examples now send valid JSON; before, each had a missing or extra comma.
• The documentation's JS/TS examples import the SDK from @basementuniverse/jsonpad-sdk rather than jsonpad.
• The documentation's cURL examples no longer send a Content-Type header on requests without a body.
• All the code examples on a documentation page use the same example ids, so the cURL and JS/TS versions of an example refer to the same list or item.

13 September 2026

Added

• Tags. Lists, items, indexes, tokens, and identities can each carry an array of tags. Tags can be added and edited in the dashboard with auto-complete, filtered on in the API, and searched from the dashboard search bar. Intended as a lightweight way to group the resources belonging to one application without introducing a formal "project" concept.
• Token regeneration. POST /tokens/{id}/regenerate issues a new value for an existing token without deleting and re-creating the token entity. User auth mode only. Use it when a token has been exposed.
• Index builds run as background jobs. Building or rebuilding an index no longer blocks the request. Build progress, status and failures are visible in the dashboard, and a failed build can be retried from there.

Changed

• Deleting a list no longer waits for its contents. DELETE /lists/{list} deletes the list itself, so it disappears (and its path name is free to use again) immediately, and its items, indexed values and indexes are deleted by a background job. Deleting a list with a lot of items is no longer at risk of timing out. The job shows up in the dashboard's jobs menu while it runs, and your stored bytes are recalculated when it finishes.
• Dashboard search now returns your own lists, items, indexes, tokens and identities alongside documentation results. Previously it only searched the documentation.
• The JSON editor in the dashboard has been rebuilt — better formatting, error reporting and large-document handling.

12 September 2026

Added

• Guard indexes. An index can be marked guard, which strips the value at its pointer from item data in responses made with token auth. The value can still be written. If the item belongs to the calling identity, pass ?includeGuarded=true to get the guarded data back. Useful for keeping part of an item private to its owner.

Changed

• Breaking: event list endpoints no longer include the event snapshot by default. Pass includeSnapshot=true to restore the previous behaviour. Event responses were large and most callers never read the snapshot.

Fixed

• Token values are now redacted in the event log. They were previously visible in the before/after payloads of token events.
• Corrected several typos in the homepage demo.

11 September 2026

Added

• Item restore. POST /items/{id}/restore restores a deleted item.
• Current token endpoint. GET /tokens/self returns the token being used to make the request, so an application can inspect its own permissions and identity without a user-mode call.
• Identity filtering. Item list endpoints accept an identity filter, so you can fetch only the items owned by a given identity.
• Identities have a displayName.
• Realtime connection quotas. Concurrent realtime connections are now capped per user according to plan (1 on Free, up to 500 on Scale). A refused socket receives a connect_error carrying the same error shape as an API error, plus max and retryAfter. Realtime messages themselves are not metered.

Changed

• Reworked token and identity permission handling, closing several gaps where a permission was checked inconsistently between related endpoints.
• Clearer button labels throughout the dashboard.

Fixed

• Rate-limit response headers were wrong on some routes and missing on others.
• Prepaid credits could be charged retroactively for requests that had already been refused.
• Fixed the JSON Pointer validation regex, which rejected some valid pointers.
• Fixed invalid JSON in several generated documentation examples.

10 September 2026

Added

• New pricing and metering model. Four plans — Free (£0), Indie (£9), Pro (£29) and Scale (£99), with annual billing at two months free. Metering is on two things only: requests per calendar month and total stored bytes. Entity limits (number of lists, items per list, indexes per list) are gone.
• Every feature is available on every plan, including Free — schema validation, version history, JSON Patch/Pointer/Path, realtime, identities, generative API. Volume is the only reason to upgrade.
• Prepaid request packs — £5 / £20 / £60 for 100k / 500k / 2M extra requests. They never expire and can be bought on any plan, including Free.
• Quota headers on every metered response: x-quota-total, x-quota-remaining, x-quota-credits, x-quota-reset, x-quota-degraded, x-rate-limit-total, x-rate-limit-remaining and retry-after.
• GET /subscriptions/usage returns current usage against your allowance.
• A /pricing page and a "Limits and quotas" documentation section.

Changed

• Only requests made with an API token are metered. Dashboard traffic authenticates as a user and does not count against your allowance.
• When an allowance, overdraft and credits are all spent, reads keep working at the Free tier's rate limit rather than failing outright; writes return 429 with QUOTA_EXCEEDED. Paid plans get a 10% overdraft first.
• Requests that end in a 5xx, that are refused for quota, or that trip the rate limiter are given back and do not count against your allowance.
• Subscribing now goes through Stripe Checkout, and billing is managed through the Stripe Customer Portal. The custom card form has been removed.

Fixed

• Stale user data could be served from cache after a subscription change.
• Subscription card styling in the dashboard.

6 September 2026

Added

• A proper 404 page.

5 September 2026

Changed

• The homepage and all documentation pages are now pre-rendered. They previously returned an empty shell to anything that does not run JavaScript, which meant search engines indexed nothing and language models could not read the documentation at all. Every documentation page is also available as markdown by appending .md to its URL — for example https://jsonpad.io/docs/getting-started.md — and the site now publishes sitemap.xml, robots.txt, llms.txt and llms-full.txt.

30 August 2026

Fixed

• Features that are disabled by configuration are now properly hidden in the client rather than shown in a broken state.

8 February 2025

Added

• An identityId variable, so the id of the identity that owns an item can be substituted into that item's data.

30 January 2025

Added

• A downloadable Postman collection in the documentation.

13 January 2025

Changed

• Added the identities section to the API reference index page.

10 January 2025

Changed

• Adjusted API rate limits.

30 December 2024

Added

• JSON5 support. Send Content-Type: application/json5 to have a request body parsed as JSON5, or Accept: application/json5 to have the response serialised as JSON5.

25 December 2024

Fixed

• An index path name uniqueness check was not scoped to its list, so creating an index could fail because an index with the same path name existed on a different list.

17 December 2024

Added

• The realtime server accepts list path names and item aliases when subscribing, not just ids.

15 December 2024

Added

• MessagePack support. Send Content-Type: application/x-msgpack to have a request body decoded as MessagePack, or Accept: application/x-msgpack to have the response encoded as MessagePack.
• An includeData parameter on the item write endpoints. It defaults to true; set it to false to skip item data in the response, which is worth doing when updating large items.
• A samples page in the documentation, listing example applications on GitHub.

Changed

• Updated subscription limits.

14 December 2024

Added

• A path parameter on the items index endpoint.

13 December 2024

Changed

• Large item data is conditionally omitted from realtime messages, so a big write no longer floods subscribers.

11 December 2024

Added

• Branding pack — downloadable "powered by JSONPad" images and logos.

Changed

• Updated the SDK examples throughout the documentation.

8 December 2024

Added

• Identities. End users of your application can now have their own accounts inside JSONPad — register, log in, log out, and read and write their own items through identity-scoped tokens, without you building an auth layer. Includes the identity API, dashboard management and documentation.
• A delay on failed login attempts.

Fixed

• Corrected the token permission schema, and brought the client's copy of it back into line with the server's.
• Fixed identity card styling and event log colours in the dashboard.
• Filled in missing entries in the event type tag.

29 November 2024

Added

• Variables. Dynamic values can be substituted into item data on write — timestamps, generated ids and similar — so a client does not have to compute them.

Fixed

• Assorted dashboard UI fixes.

24 November 2024

Added

• Token permissions can be edited as raw JSON in the dashboard, as well as through the UI controls.

23 November 2024 — Launch

JSONPad went live.

Added

• Lists and items. JSON documents organised into lists, with a REST API over both.
• JSON Schema validation per list, so items cannot be written in a shape the list does not allow.
• Version history. Every item write is versioned; previous versions can be fetched, compared and restored.
• Partial data access via JSON Path and JSON Pointer — fetch, update, patch or delete part of an item without sending the whole document. JSON Patch is supported on writes.
• Indexes. Typed indexes over a pointer into item data, used for sorting, filtering and searching a list. Alias indexes let an item be addressed by a value from its own data instead of its id.
• Search across a list.
• Tokens and permissions. API tokens with a declarative permission model covering which resources and actions a token may use.
• Event log. An audit trail of every change to a list, item, index or token.
• Realtime server. Subscribe over a socket and receive item changes as they happen.
• SDKs for Node and the browser.
• Generative API — create and populate items from a prompt, backed by Google Gemini or OpenAI.
• Dashboard — lists, items, indexes, tokens, event log, item version comparison and restore, statistics, and a first-time user experience.
• Accounts and billing — registration, email verification, subscriptions via Stripe, account deactivation and deletion.
• Documentation with full API reference and searchable content.
• Status page.
• ETags and conditional requests, standard rate-limit and quota response headers, and a maintenance mode.