Seven complete fake APIs — e-commerce, IoT, banking, social, helpdesk, flights and a company directory — with 78,076 related records, over REST, GraphQL, OData, gRPC-Web, SOAP, JSON-RPC, XML-RPC, Socket.IO, WebSocket, Server-Sent Events, MQTT and MCP, with SAML, SCIM and OAuth on top — and a FHIR R4 server over a synthetic clinic. 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.
Every protocol #
The same data, whichever way your client talks.
Sandboxes for the APIs you integrate #
Stand-ins for Stripe, Twilio, SendGrid, Authorize.net, OpenAI and Anthropic — and for the secrets managers: AWS Secrets Manager, Azure Key Vault, Google Secret Manager, 1Password Connect, Doppler and Infisical — that the official SDKs work against with the host swapped and the session token carried: the vendors’ test cards and magic numbers, bounces and opens, settlement, a scripted model that answers the same way every time, secret versions, rotation and sign-ins, and callbacks signed their way. Independent imitations, not affiliated with any of these companies.
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.
SendGrid sandbox
A SendGrid mock API: Mail Send with real validation, templates rendered, bounces and opens, signed Event Webhooks.
Authorize.net sandbox
An Authorize.net mock API: XML and JSON checked like the real one, test triggers, settlement every minute, profiles, subscriptions, signed webhooks.
OpenAI sandbox
An OpenAI mock API with a scripted model: chat completions, the Responses API, streaming, tool calls, structured outputs, embeddings, errors on cue.
Anthropic sandbox
A Claude API mock with a scripted model: messages, streaming, tool use, signed thinking blocks, prompt caching, batches, errors on cue.
AWS Secrets Manager sandbox
An AWS Secrets Manager mock for boto3 and the SDKs: all 23 actions, SigV4 checked, versions and labels, rotation, deletion windows, replicas.
Azure Key Vault sandbox
An Azure Key Vault mock the Azure SDK signs in to: the bearer challenge, an Entra ID token endpoint, versions, soft delete, recover, purge, backup.
Google Secret Manager sandbox
A Google Secret Manager mock for the client libraries over REST: versions, aliases, CRC32C checks, delayed destruction, IAM, a service account.
1Password Connect sandbox
A 1Password Connect server mock: vaults, items, generated passwords, one-time codes, files, JSON Patch, activity.
Doppler sandbox
A Doppler API mock: configs and branch inheritance, references resolved, every download format for doppler run, logs and rollback, service tokens.
Infisical sandbox
An Infisical API mock: Universal Auth, raw secrets v3 and v4, references expanded, folders, imports, versions, personal overrides.
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 much data is there, and does it behave like a real backend?
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.
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, OData 4 with $metadata and $batch, FHIR R4 over a synthetic clinic, gRPC-Web and Connect with .proto files, SOAP 1.1 and 1.2 with a WSDL per API (and WS-Security), JSON-RPC 2.0 and XML-RPC, Socket.IO, 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, Twilio, SendGrid or Authorize.net integration without an account?
Yes, against the sandboxes: a Stripe mock API, a Twilio mock API, a SendGrid mock API and an Authorize.net 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, SendGrid’s validation, templates, bounces and opens, Authorize.net’s schema checks, test triggers and settlement, and webhooks signed so the vendor’s own library or recipe verifies them. They are independent imitations, not the vendors’ own test modes.
Can I test code that calls OpenAI or Claude without paying for tokens?
Yes: the OpenAI mock API and the Claude API mock answer the official SDKs with a scripted model — chat completions and the Responses API, messages, streaming, tool calls, structured outputs, thinking blocks, embeddings, batches — the same answer for the same request, checked like the real API. Set the SDK’s base URL to the sandbox and any key will do; a phrase in the message such as [[tool]], [[refuse]] or [[error:429]] picks the outcome your code has to handle.
Can I test code that reads secrets from AWS Secrets Manager, Key Vault, Doppler or 1Password?
Yes: the AWS Secrets Manager, Azure Key Vault, Google Secret Manager, 1Password Connect, Doppler and Infisical mocks answer the official SDKs with a seed of fake secrets — versions and labels, rotation, soft delete, references resolved, the vendors’ sign-ins and errors — so the code that loads your configuration at boot, rotates a password or rolls a value back can be tested without an account. Never send them a real secret: they are public playgrounds.
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. The patients of the FHIR clinic are synthetic too, every resource tagged as test data, with real LOINC, SNOMED CT and RxNorm codes. Same rows on every build, so ids in your tests stay valid.
Can I run it myself?
A curated version of the hub is open source under the MIT License (on GitHub). It is not everything sondahub.com runs, but it serves on localhost on plain Node, which suits a CI run that should not depend on a public service.