How do I mock the Azure Service Bus + Storage API locally?

Install stunt, add a one-service block to stunt.yaml (adapter: embedded:azure-servicebus-style), and run stunt up. You get a local, stateful stand-in for Azure Service Bus + Storage 2024-01-01 — 18 routes over rest — with no remote account, no network, and no bills.

Is the Azure Service Bus + Storage mock data synthetic?

Yes — entirely. The adapter returns generated data only; stunt's adapter lint rejects real-looking secrets and PII at build time. It simulates the shape and behavior of Azure Service Bus + Storage (routes, status codes, pagination, webhooks), never real records.

← all adapters

azure-servicebus-style

simulates Azure Service Bus + Storage 2024-01-01

restadapter v0.2.018 routes

verification

VMVM tier — no SDK suite yet· surface 18 · not implemented 6 · differs 3

use it

# add to stunt.yaml
services:
  azure-servicebus:
    adapter: embedded:azure-servicebus-style

# then
$ stunt up

The embedded: source extracts this adapter from the binary — no git clone, fully offline.

how to mock the Azure Service Bus + Storage API locally

Install stunt, paste the service block above into stunt.yaml, run stunt up — then point your client at localhost instead of Azure Service Bus + Storage. It works offline, keeps state across requests and restarts, and every response is synthetic: the route shapes, status codes, pagination, and webhook delivery follow the real Azure Service Bus + Storage 2024-01-01 surface — the data is fake, the behavior is real.

backing stores

sb_messagesstorage_messages

api surface (18)

generated from the adapter manifest — exactly what boots, nothing more

18 routes

POST/{queue}/messages

DELETE/{queue}/messages/head

POST/{queue}/messages/{lockToken}/{action}

GET/$topicInfo

GET/topics

PUT/topics/{topic}

GET/topics/{topic}

DELETE/topics/{topic}

POST/topics/{topic}/messages

GET/topics/{topic}/subscriptions

PUT/topics/{topic}/subscriptions/{sub}

GET/topics/{topic}/subscriptions/{sub}

DELETE/topics/{topic}/subscriptions/{sub}

POST/topics/{topic}/subscriptions/{sub}/messages

POST/topics/{topic}/subscriptions/{sub}/messages/{lockToken}/{action}

POST/{account}/{queue}/messages

GET/{account}/{queue}/messages

DELETE/{account}/{queue}/messages/{messageid}

VM-verified behaviors (7)

✓a correctly signed SAS token sends the message
✓a tampered signature is 401 InvalidSignature
✓an expired se is 401 ExpiredToken
✓structurally broken tokens map to MalformedToken or InvalidSignature
✓Entra Bearer tokens are accepted alongside SAS
✓the storage-queue endpoint accepts the same SAS verifier
✓a tampered storage-queue signature is 401 InvalidSignature

Not implemented (6)

No queue management — queues are neither created nor listed
No subscription rules — fan-out is the default match-all broadcast only
No dead-letter settle action or DLQ receive (subqueue $deadletterqueue)
No sessions, scheduled send, or duplicate detection
No AMQP 1.0 transport — HTTP/REST surface only
No Storage queue peek, update, clear, or queue create/list/delete

Differs from the real API (3)

Default 30s peek-lock, overridable via simulator-only lockduration query param
Bearer auth accepted with any non-empty token — only SAS is verified
Storage queue send accepts JSON MessageText in place of the real XML body

full scorecard →

want more of the Azure Service Bus + Storage surface? adapters are YAML + Starlark — the authoring guide covers adding routes, fixtures, and state machines. Open an issue for anything big first, or just file a PR — merged routes ship in the next release.