Show HN: Free Public API Lab

LockFlare launched Free Public API Lab, a set of seven mock APIs covering e-commerce, IoT, banking, social, helpdesk, flights and a company directory, backed by 78,076 related records and served 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. The service requires no keys, accounts or database, and includes a Model Context Protocol test server over Streamable HTTP plus sandboxes that imitate Stripe, Twilio, SendGrid, Authorize.net, OpenAI, Anthropic and six secrets managers so official SDKs work against them with the host swapped. LockFlare built the lab as the playground for its LockFlare Sonda tool.

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, 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 https://sondahub.com/fhir-test-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 https://lockflare.com/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 https://sondahub.com/sandboxes/ : 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. https://sondahub.com/mock-api-with-persistence/ 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 https://sondahub.com/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. https://sondahub.com/mock-api-with-persistence/ 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 https://sondahub.com/data-files/ are open to every origin too. Which protocols are there? REST https://sondahub.com/fake-rest-api/ with OpenAPI 3 documents, GraphQL https://sondahub.com/public-graphql-api/ with introspection, OData 4 https://sondahub.com/odata-test-server/ with $metadata and $batch, FHIR R4 https://sondahub.com/fhir-test-server/ over a synthetic clinic, gRPC-Web and Connect https://sondahub.com/grpc-web-test-server/ with .proto files, SOAP 1.1 and 1.2 https://sondahub.com/soap-test-server/ with a WSDL per API and WS-Security , JSON-RPC 2.0 and XML-RPC https://sondahub.com/json-rpc-test-server/ , Socket.IO https://sondahub.com/socket-io-test-server/ , WebSocket https://sondahub.com/websocket-test-server/ , Server-Sent Events https://sondahub.com/sse-test-server/ , MQTT 3.1.1 and 5 over WebSocket https://sondahub.com/public-mqtt-broker/ , an MCP server https://sondahub.com/mcp-server/ for AI agents and an OAuth-protected one https://sondahub.com/mcp-oauth-test-server/ , SCIM 2.0 https://sondahub.com/scim-test-server/ , SAML 2.0 https://sondahub.com/saml-test-idp/ , and HTTP test endpoints https://sondahub.com/utilities/ with every auth scheme including an OAuth 2.0 / OpenID Connect server https://sondahub.com/oauth2-test-server/ . Can I test single sign-on and user provisioning? Yes — against a whole company. The Identity API https://sondahub.com/apis/identity/ is a directory of 300 people in 40 groups, and the same people sign in through the SAML IdP https://sondahub.com/saml-test-idp/ and the OIDC server https://sondahub.com/oauth2-test-server/ and are provisioned through the SCIM 2.0 server https://sondahub.com/scim-test-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 https://sondahub.com/sandboxes/ : a Stripe mock API https://sondahub.com/sandboxes/stripe/ , a Twilio mock API https://sondahub.com/sandboxes/twilio/ , a SendGrid mock API https://sondahub.com/sandboxes/sendgrid/ and an Authorize.net mock API https://sondahub.com/sandboxes/authorizenet/ 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 https://sondahub.com/sandboxes/openai/ and the Claude API mock https://sondahub.com/sandboxes/anthropic/ 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 https://sondahub.com/sandboxes/aws-secrets-manager/ , Azure Key Vault https://sondahub.com/sandboxes/azure-key-vault/ , Google Secret Manager https://sondahub.com/sandboxes/google-secret-manager/ , 1Password Connect https://sondahub.com/sandboxes/1password-connect/ , Doppler https://sondahub.com/sandboxes/doppler/ and Infisical https://sondahub.com/sandboxes/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 https://sondahub.com/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 https://sondahub.com/api-chaos-testing/ and signed webhooks https://sondahub.com/webhook-tester/ 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 https://lockflare.com/sonda or any client or code generator that reads OpenAPI. Can AI agents and LLMs use it? Yes. The MCP server https://sondahub.com/mcp-server/ gives an agent 26 tools over the same data; the OAuth-protected one https://sondahub.com/mcp-oauth-test-server/ walks a client through the MCP authorization flow — protected-resource metadata, dynamic client registration, PKCE, audience and scopes. llms.txt https://sondahub.com/llms.txt and llms-full.txt https://sondahub.com/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 https://sondahub.com/fhir-test-server/ 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 https://github.com/lockflare/sondahub-core . 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.