AMQP test broker

Connect

The bridge listens on port 5772 for AMQP and 61713 for STOMP — off the usual 5672 and 61613, so a broker you already run keeps them — or the next free ports, and carries every connection to the hub over one WebSocket. One bridge, one broker: what a client publishes over AMQP, another can read over STOMP. The bridge prints who connects, what is declared and bound, what is published where, and every error with its reason.

curl -O https://sondahub.com/industrial/bridge.mjs
node bridge.mjs amqp

AMQP 0-9-1 and 1.0 on localhost:5772 → wss://api.sondahub.com/amqp — amqp://guest:guest@localhost:5772
STOMP on localhost:61713 → wss://api.sondahub.com/amqp — localhost:61713, the same broker
every run of the bridge is a world of its own
the hub is an AMQP 0-9-1 and 1.0 broker that speaks STOMP too — exchanges amq.direct, amq.fanout, amq.topic, amq.headers; queues store, fleet, bank, social, helpdesk, flights, identity (the APIs’ activity), orders, orders.dead and rpc
client “orders-service” — pika 1.3.2 — connected from 127.0.0.1:51760 as guest
orders-service consumes from fleet, prefetch 10
orders-service → (default exchange) orders: routed to 1 queue
orders ← order 900001 for 42.5: paid in 2 s, shipped in 5, delivered in 9, on amq.topic as store.orders

In an AMQP client

Start the bridge, then connect to amqp://guest:guest@localhost:5772. The queues are already there and filling: store, fleet, bank, social, helpdesk, flights, identity hold each API’s activity, the last minute of it there from the start.

import json, pika

conn = pika.BlockingConnection(pika.URLParameters('amqp://guest:guest@localhost:5772/%2F'))
ch = conn.channel()
for method, props, body in ch.consume('fleet', auto_ack=True, inactivity_timeout=5):
    if method is None:
        break
    print(method.routing_key, json.loads(body))

import amqp from 'amqplib'

const conn = await amqp.connect('amqp://guest:guest@localhost:5772')
const ch = await conn.createChannel()
const { queue } = await ch.assertQueue('', { exclusive: true })
await ch.bindQueue(queue, 'amq.topic', 'store.orders')
await ch.consume(queue, (m) => console.log(m.fields.routingKey, m.content.toString()), { noAck: true })
ch.sendToQueue('orders', Buffer.from(JSON.stringify({ customer_id: 7, total: 42.5 })))

conn, err := amqp.Dial("amqp://guest:guest@localhost:5772/")
if err != nil {
    panic(err)
}
ch, _ := conn.Channel()
msgs, _ := ch.Consume("bank", "", true, false, false, false, nil)
for m := range msgs {
    fmt.Println(m.RoutingKey, string(m.Body))
}

In LockFlare Sonda: point a RabbitMQ item at localhost:5772 as guest/guest, with the bridge running.

What is in it

Queues

The hub’s queues take any declaration — durable or not, with arguments or without — so a client that declares before it consumes just works; they cannot be deleted. Each API queue keeps 500 messages at most.

Exchanges

The routing keys on amq.topic

Each message JSON, with content_type application/json, a message_id, a timestamp, type set to its routing key, app_id sondahub, and the headers source and key.

Orders and RPC

orders listens. Publish an order to it — JSON with customer_id and a total above 0, an id if you want to pick it — and the hub takes it through its life on amq.topic as store.orders: paid two seconds later, shipped with a tracking number at five, delivered at nine. An order over 10,000 is cancelled. With reply_to set, the hub answers at once: {"accepted":true,"id":…,"status":"pending"}. Anything that is not an order the hub rejects: orders dead-letters it through orders.dlx to orders.dead, with x-death saying it was rejected and x-sondahub-error saying why.

rpc answers. Publish {"method":"store.getProduct","params":{"id":1}} with reply_to and correlation_id and the answer comes back as {"result":…} or {"error":{"code","message"}}, with your correlation_id: every call JSON-RPC makes (list, get, create, update and delete on every collection of the seven APIs), writes kept as long as the broker lives. reply_to may be a queue of yours or RabbitMQ’s direct reply-to, amq.rabbitmq.reply-to.

ch.basic_consume('amq.rabbitmq.reply-to', lambda c, m, p, b: print(p.correlation_id, json.loads(b)), auto_ack=True)
ch.basic_publish('', 'rpc', json.dumps({'method': 'store.getProduct', 'params': {'id': 1}}),
                 pika.BasicProperties(reply_to='amq.rabbitmq.reply-to', correlation_id='1'))
conn.process_data_events(time_limit=2)

What the broker does

Exchanges direct, fanout, topic and headers, with bindings to queues and to other exchanges. Queues server-named (amq.gen-…), exclusive to their connection, auto-deleted with their last consumer, with the arguments below. Consumers served in turn, with prefetch per consumer (basic.qos, global false) or per channel (global true), exclusive consumers, and single active consumer. basic.get, ack, nack and reject with requeue — a requeued message comes back marked redelivered — and recover. Publisher confirms (a nack when a queue refuses the message), mandatory publishing (basic.return 312 NO_ROUTE), transactions (tx.select, commit, rollback), channel.flow, heartbeats, and consumers told when their queue goes (basic.cancel). Errors are RabbitMQ’s: 404 NOT_FOUND, 403 ACCESS_REFUSED, 405 RESOURCE_LOCKED, 406 PRECONDITION_FAILED on the channel; 503, 504, 505, 530, 540 on the connection — with RabbitMQ’s words, NOT_FOUND - no queue 'x' in vhost '/'.

Queue arguments

Messages up to 4 MB, one vhost (/), plaintext only (no TLS). Priorities are accepted and not ordered by; stream queues are refused.

Users

AMQP 1.0 on the same port

An AMQP 1.0 client connects to localhost:5772 too — the broker reads the protocol header and answers in the version asked for — and reads /queues/fleet or sends to /exchanges/amq.topic/store.orders, RabbitMQ’s addresses. AMQP 1.0 also comes straight over WebSocket, with no bridge. The AMQP 1.0 broker.

STOMP on the same broker

A STOMP client connects to localhost:61713 through the same bridge and meets the same queues and exchanges, with RabbitMQ’s destinations — /queue/orders, /topic/fleet.#, /exchange/amq.fanout. What it sends, an AMQP client reads, and the other way round. STOMP also comes straight over WebSocket, with no bridge: the STOMP server.

The bridge, on the wire

For anyone writing a bridge of their own: it opens wss://api.sondahub.com/amqp with the subprotocol sondahub-bridge and says hello in text — {"bridge":"amqp","version":1,"ports":{"amqp":5772,"stomp":61713}}. Then every client connection rides the WebSocket under an id: a byte for what happened (3 bytes of the stream, 4 a connection opened, 5 one closed), the id (four bytes, big-endian), two zero bytes, then for a 3 the bytes as they came off the socket, and for a 4 {"proto":"amqp","peer":"ip:port","local":"ip:port"} — which listener, who dialed, and the address they dialed. The hub sends 3 and 5 back, and {"log":…} lines in text.

Also on sondahub

Fake REST API · Public GraphQL API · gRPC-Web & Connect · SOAP test server · JSON-RPC & XML-RPC · OData test server · FHIR test server · Socket.IO test server · WebSocket test server · SSE test server · Public MQTT broker · Kafka test broker · AMQP 1.0 test broker · STOMP test server · NATS test server · Redis test server · FIX test server · HL7 v2 test server · MCP test server · MCP OAuth test server · Writes that persist · OpenAPI mock server · Webhook tester · Chaos and rate limits · SAML test IdP and SP · SCIM 2.0 test server · OAuth 2.0 test server · Auth test endpoints · HTTP test endpoints · Fake JSON data · Stripe sandbox · Twilio sandbox · SendGrid sandbox · Authorize.net sandbox · OpenAI sandbox · Anthropic sandbox · AWS Secrets Manager sandbox · Azure Key Vault sandbox · Google Secret Manager sandbox · 1Password Connect sandbox · Doppler sandbox · Infisical sandbox · OPC UA test server · Modbus TCP simulator · HART-IP simulator · DDS simulator

The mock APIs themselves: fake e-commerce API, fake IoT API, fake banking API, fake social media API, fake helpdesk API, fake flight booking API, fake user directory API. Built as the playground for LockFlare Sonda, the API client that lives on your computer.