Free mock APIs that answer like real ones.
Seven complete fake APIs — e-commerce, IoT, banking, social, helpdesk, flights and a company directory — with 78,076 related records, over REST, GraphQL, gRPC-Web, WebSocket, Server-Sent Events, MQTT and MCP, with SAML, SCIM and OAuth on top. No keys, no accounts, no database — and still, what you write is there when you read it back, because the state travels with you. Built as the playground for LockFlare Sonda.
The mock APIs
Each one is a small world with thousands of related records, ids that never change, and behaviour a real backend has: a transfer checks the funds and writes a transaction on each side, a ticket refuses an impossible status, a booking gets a seat.
Store API
An online shop: products, customers, orders, reviews and stock.
Fleet API
An IoT fleet: sites, devices, telemetry and alerts — the MQTT one.
Bank API
Retail banking: customers, accounts, cards, nearly eight thousand transactions, transfers and FX rates.
Social API
A social network: users, posts, comments, likes and follows — the GraphQL one.
Helpdesk API
A support desk: tickets, messages, agents, customers, SLAs — the state-machine one.
Flights API
Airports, airlines, two and a half thousand scheduled flights and their bookings — the live-board one.
Identity API
A company directory: people, groups and memberships — behind SCIM 2.0, SAML and OpenID Connect.
MCP test server
The same seven worlds as a Model Context Protocol server over Streamable HTTP — data tools, domain tools, resources, prompts and completions — plus tools built to test an MCP client: progress, errors, images, every content type.
HTTP test endpoints
Echo, any status code, delays, redirects, cookies, gzip, streams, uploads — and every auth scheme, checked for real: Basic, Digest, API key, Bearer, AWS SigV4, OAuth 2 with PKCE, JWT.
Testing tools
The things a real backend does to a client — and the things a client has to do to a real backend. One page each, with examples that run from the page.
Writes that persist
POST, then GET it back — with no database: the state travels with you.
OpenAPI mock server
Point it at any OpenAPI or Swagger file and get a working mock.
Webhook tester
Signed webhooks to your endpoint: Standard Webhooks, Stripe or GitHub style.
Chaos and rate limits
Latency, failures, 429s, idempotency keys, cursors, CSV and XML on any endpoint.
SAML test IdP and SP
Sign in with SAML, or check what your IdP sends — signatures and all.
SCIM 2.0 test server
Users and Groups with filters, PATCH, Bulk and discovery.
OAuth 2.0 test server
Authorization code with PKCE, client credentials, OIDC, dynamic registration.
Auth test endpoints
Basic, Digest, API key, Bearer, JWT and AWS SigV4, checked for real.
JSONPlaceholder alternative
When six small resources are not enough.
Every protocol
The same data, whichever way your client talks.
Fake REST API
CRUD over 37 collections with paging, filters, sorting, search and relations.
Public GraphQL API
Seven schemas with introspection, nested relations and mutations.
gRPC-Web & Connect
Every API as a protobuf service, unary and streaming, .proto files included.
WebSocket test server
An echo socket and live JSON event streams.
SSE test server
Server-Sent Events with ids, named events and resumption.
Public MQTT broker
MQTT 3.1.1 and 5 over WebSocket with live IoT telemetry.
MCP test server
A Model Context Protocol server over Streamable HTTP.
MCP OAuth test server
The MCP authorization flow end to end: metadata, DCR, PKCE, audience.
Sandboxes for the APIs you integrate
Stand-ins for Stripe and Twilio that the official SDKs work against with the host swapped and the session token carried — the vendors’ test cards and magic numbers, and callbacks signed their way. Independent imitations, not affiliated with either company.
Stripe sandbox
A Stripe mock API the official SDK works against: test cards, 3D Secure, refunds, Checkout, signed webhooks.
Twilio sandbox
A Twilio mock API: SMS, calls, Verify and Lookups, magic numbers, signed status callbacks.
How the sandboxes work
Same paths, errors and behaviour as the real API; your data in a session token; webhooks your SDK’s own signature check accepts. No account to open.
Writes that stick, with no database
sondahub keeps nothing — there is no database behind it, only files and code. Yet a POST you send is there on your next GET. Every write is validated, run through the real rules and answered as a real server would, and the answer carries a token holding everything you have changed so far. Send it back and the next request starts from your world instead of the seed:
POST /v1/store/orders {"customer_id":1,"items":[…]}
→ 201 Created, order 3001, priced
X-Sondahub-Session: s1.…
GET /v1/store/orders/3001 X-Sondahub-Session: s1.…
→ 200, the order you just placed
PATCH /v1/store/orders/3001 {"status":"shipped"}
→ 200, stamped shipped_at and a tracking number
GET /v1/store/orders?sort=-id
→ yours first, the total one higher
Nobody else sees your writes and nobody can break your tests; drop the token and the world is the seed again. The examples on every page share one session until you reload. How the session works.
Three steps in Sonda
Everything an API here offers can be loaded into Sonda without typing a request by hand.
Import an API
Every API publishes an OpenAPI document. Import → From a URL, paste https://api.sondahub.com/v1/store/openapi.json, and the whole project appears with example bodies.
Send things
Lists with filters, a record by id, a POST that gets validated and priced, a PATCH that moves a status. Wrong bodies come back as 422 with every field named.
Go live
A WebSocket or SSE request on /v1/fleet/ws or /v1/fleet/events streams the world's own activity. The MQTT pane connects to wss://api.sondahub.com/mqtt.
Questions people ask
Is sondahub free? Do I need an API key?
Free, with no account, no key and no signup. Every endpoint answers anyone over HTTPS. The auth test endpoints use playground credentials printed on the page — public on purpose, so a client can prove a flow works.
How is this different from other fake JSON APIs?
Most fake APIs serve a few small static lists. sondahub serves 78,076 related records in 37 collections, ids that never change, filters, sorting, search and relations — and the behaviour of a real backend: a bank transfer checks the funds and writes a transaction on each side, a ticket refuses an impossible status change, a flight booking picks a free seat, and a wrong body gets a 422 naming every field. A side-by-side with JSONPlaceholder.
Do POST, PUT, PATCH and DELETE work? Do they persist?
Yes, and yes — for you. A write is validated, run through the real rules and answered with the status, headers and body a real server would send. The answer also carries an X-Sondahub-Session token holding everything you have changed; send it back on the next request and that request sees your writes: POST an order, GET it, PATCH it, list it. There is no database — the state travels with you, so nobody else sees it and nobody can break your tests. How the session works.
Can I call it from a browser, a frontend demo or a mobile app?
Yes. CORS is open to every origin and preflight requests are answered, so fetch() from any page works, and so do the WebSocket and SSE streams. The raw JSON data files are open to every origin too.
Which protocols are there?
REST with OpenAPI 3 documents, GraphQL with introspection, gRPC-Web and Connect with .proto files, WebSocket, Server-Sent Events, MQTT 3.1.1 and 5 over WebSocket, an MCP server for AI agents (and an OAuth-protected one), SCIM 2.0, SAML 2.0, and HTTP test endpoints with every auth scheme including an OAuth 2.0 / OpenID Connect server.
Can I test single sign-on and user provisioning?
Yes — against a whole company. The Identity API is a directory of 300 people in 40 groups, and the same people sign in through the SAML IdP and the OIDC server and are provisioned through the SCIM 2.0 server. Point Okta, Entra ID or your own SP at it; the test SP checks what your IdP sends, signature by signature.
Can I test a Stripe or Twilio integration without an account?
Yes, against the sandboxes: a Stripe mock API and a Twilio mock API that the official SDKs work against with the host swapped and the session token carried — Stripe’s test cards and 3D Secure, Twilio’s magic numbers and delivery receipts, and webhooks signed so the vendor’s own library verifies them. They are independent imitations, not the vendors’ own test modes.
Can I mock my own API?
Yes: give the OpenAPI mock server the address of any OpenAPI 3 or Swagger 2 file and it serves that API — routes matched, requests validated against the spec, answers from your examples or generated from your schemas, the same answer for the same request. And any endpoint here takes latency, failures, rate limits and signed webhooks on request.
Is there an OpenAPI spec I can import?
Every API publishes an OpenAPI 3.0.3 document at https://api.sondahub.com/v1/{api}/openapi.json, with schemas and example bodies. Import it into Sonda or any client or code generator that reads OpenAPI.
Can AI agents and LLMs use it?
Yes. The MCP server gives an agent 26 tools over the same data; the OAuth-protected one walks a client through the MCP authorization flow — protected-resource metadata, dynamic client registration, PKCE, audience and scopes. llms.txt and llms-full.txt describe every endpoint in one plain-text file.
Is any of the data real?
No. Every person, order, account, card and booking is generated from a fixed seed — emails use reserved example domains and card numbers are masked. The airports are real airports; the airlines are invented. Same rows on every build, so ids in your tests stay valid.
Can I run it myself?
Yes — the source is MIT-licensed. npm install, npm run build and npm run dev serve the whole hub on localhost on plain Node, which suits a CI run that should not depend on a public service.