The asynchronous world, behind the same doors.

The asynchronous plane has its contract, just as the synchronous one has OpenAPI: contracts.asyncapi loads an AsyncAPI 3.0.0 or 3.1.0 document, validated against the embedded official schema. Channels, their messages and their schemas come from the contract; a send or receive operation names its broker with x-flexway-upstream. The HTTP entry point is an OpenAPI operation marked x-flexway-publish or x-flexway-subscribe.

The invariant stays the same: published or consumed = declared. An operation with no broker, an entry point to a missing operation or one in the opposite direction, a body with a different schema from the message, or a message without a JSON schema (Avro, Protobuf) are refused at load, all reported in one pass. A refusal is stated, never ignored.

An HTTP client, or an agent through an MCP tool, publishes without embedding a broker client. The body is read in full within a bound, checked against the message schema, then wrapped in CloudEvents 1.0 binary mode (structured on MQTT 3.1.1). The gateway answers 202 only after the broker acknowledges: acks=all from an idempotent Kafka producer, AMQP confirms, MQTT PUBACK at QoS 1. An Idempotency-Key becomes the event id, and idempotency: required makes it mandatory (428 otherwise).

The buffer is bounded per broker and per replica (max_in_flight, 1,024 by default): beyond it, an immediate 503 overloaded, never a queue that grows with the outage. A circuit breaker per broker gives 503 upstream_unavailable; exceeding the budget gives 504 upstream_timeout, meaning the outcome is unknown.

The gateway authenticates to the broker (SASL, mTLS, secrets by reference); the caller travels as CloudEvents attributes - tenant always, traceparent, authid and authtype only if the message declares them - and a ce-* header supplied by the caller is refused (400). A message published through a REST route carries the same audit line and the same authorisation verdict as a synchronous call.

A browser or a mobile app consumes a stream without speaking the broker's protocol. Over SSE, delivery fans out: one consumer per channel and per replica, whatever the number of subscribers; resumption uses Last-Event-ID from the channel's in-memory history (history, 64 by default), with 412 beyond it. Over WebSocket, delivery is at least once: the position advances only after {"ack": "<id>"}, otherwise the connection is closed after ack_timeout and the message is delivered again.

A subscriber receives only what its verified values name: a bound channel parameter (x-flexway-bind: tenant, subject or claim:<name>) or the tenant attribute filtered on headers, never on data. A channel that is neither bound, nor filtered, nor declared public is refused at load. Public access is declared explicitly (x-flexway-public: true on the receive operation) and is still counted per address and overall.

The buffer is bounded per stream, a subscriber that is too slow is closed, and max_streams caps streams per caller and per replica (429 too_many_streams). Durable state - positions, groups - stays in the broker: the gateway remains stateless. Subscribing an agent to a stream through an MCP tool is upcoming.

Kafka, AMQP 0-9-1 (and AMQPS) and MQTT go through the same admission as HTTP traffic: identity, quota, audit, trace. The gateway reaches a broker as a client, never through a broker listener, and a contract operation is never relayed as is to a broker. Upstreams are declared with upstreams.*.protocol (kafka, amqp, mqtt), with brokers, protocol_version and sasl, whose password is a reference.

On consumption, both CloudEvents modes are read according to each binding's rule: application/cloudevents+json as structured, binary otherwise. Errors on the asynchronous plane are expressed as a CloudEvents attribute, as they are expressed in RFC 9457 over HTTP. The configuration reloads hot: an unchanged broker client is reused, and one client per subscription costs connections, hence the max_streams cap.

A receive operation can deliver to a declared target (x-flexway-deliver, upstream protocol: webhook). Consumption runs in a group shared by the replicas, one replica per message, in the Standard Webhooks format: webhook-id equal to the event id, an HMAC-SHA256 signature covering the attributes, two active secrets for rotation, a structured CloudEvent as the body. A partner thus receives its tenant's events without access to the broker.

The address is checked at connection time: loopback, link-local and cloud metadata addresses are always refused, private ranges only with allow_private, with no proxy and no redirect. Retries are bounded (retries.max, retries.max_delay) and honour Retry-After, with a circuit breaker per target. The position advances only after a 2xx; once retries are exhausted or on a 4xx refusal, the intact event goes to the declared dead-letter queue with problemcode and problemstatus, from where it can be replayed.

A delivery has no caller: a channel bound to a caller fact (subject, claim) cannot be delivered by webhook, and a delivery without a tenant or without a dead-letter queue is refused at load.

The delivered asynchronous plane mediates between HTTP and brokers. The native Kafka proxy goes further: Kafka clients connecting directly to the gateway, with virtual clusters and topics per tenant.

It comes with ACLs and quotas per Kafka client, then field-level encryption of messages at the proxy. The state of these three features in this release, read from the product's catalogue, is shown below.