Use a webhook when another system pushes events to DataMind OS. Use RabbitMQ when your events already sit in RabbitMQ queues. In both cases, events collect in a buffer first, and the Lake tables you import from the connection load from it.
Click Request guide under the endpoint URL to see the exact request your sender must make. It shows the endpoint, the headers the request carries and an example, built for the sender you chose. The secret is never shown there.
| Sender | What it does |
|---|---|
| GitHub, Shopify, Wolt | Checks the vendor's signature. The signature format is set for you, so you only enter the signing secret. |
| Static token in a header | Checks a shared token that the sender puts in a header. This is the default, with the header name X-API-Key. |
| Custom HMAC signature | Checks an HMAC signature. You set the signature format yourself. |
| No authentication | Checks nothing. |
Each sender checks exactly what its row describes, and nothing else. Matching the Header name ignores case.
With No authentication, nothing is verified. Anyone who learns the URL can write events into this connection. Use it only when the sender cannot sign or send a token.
Stripe and Slack senders are not supported, because they pack several values into one header.
With Custom HMAC signature, the Signature format section shows these settings:
| Setting | What it does | Default |
|---|---|---|
| Algorithm | The hash the sender signs with: SHA-256, SHA-1 or SHA-512. | SHA-256 |
| Digest encoding | How the digest is written: Hex or Base64. | Hex |
| Signature prefix | Text the sender puts before the digest, if any. | Empty |
| Timestamp header | Set this only if the sender signs "timestamp.body". It also turns on replay rejection. | Empty |
| Replay window (seconds) | Appears when Timestamp header is set. How far the sender's timestamp may drift before the event is refused. | 300 |
| Setting | What it does | Default |
|---|---|---|
| Table name | The table that receives one row per event, with the body kept as raw JSON. It is fixed once the connection is saved. | table |
| Retention | Keep forever keeps every event. Delete after N days deletes older events. | Keep forever |
The sender makes a POST request to the Endpoint URL shown on the connection. A request the connection accepts gets HTTP 200 with {"received": true}, and the event is written to the buffer.
A request the connection refuses gets HTTP 401 with Webhook authentication failed: <reason>. The reason names the check that did not pass, and it never contains the stored secret:
| Reason | What it means |
|---|---|
missing_auth_header | The request has no credential header, or the header name does not match Header name. |
token_mismatch | The token does not match the connection's current or previous token. |
signature_mismatch | The signature does not match what DataMind OS computes from the request. |
timestamp_outside_tolerance | The request's timestamp falls outside the Replay window (seconds). |
connection_auth_misconfigured | The connection's own sender settings are incomplete, so no request can match. |
Two more answers a sender can meet:
Unknown webhook endpoint: the address matches no connection. The sender posts to the wrong place.Empty or unreadable request body: the request carries no readable body, so there is nothing to store.Accepted events wait in the buffer until the table is synchronised. The buffer exists from the moment the connection is saved, so events are kept even before you import a table. The endpoint URL never changes when you edit the connection.
For every broker field in detail, including its default, see Connect RabbitMQ.
Imported RabbitMQ tables also get _message_id and _ingested_at columns. Without a key column, _message_id is the key.
Creating a webhook or RabbitMQ connection needs Add/Modify Lake Objects. See Who can do what in the Lake.
To send data out to RabbitMQ instead, see Publish to RabbitMQ.
A secret cannot be shown again. Enter a new token or signing secret in Sender & security, keep Keep the old secret working during changeover on, and follow the steps in Rotate a webhook secret above.
Yes. Both the current and the previous token or signing secret are accepted during changeover, so events keep arriving while your sender catches up. Save the new secret, update the sender, then stop accepting the old one.
No. The URL stays the same when you change the sender or the security settings.
HTTP 200 with {"received": true}.
They wait in the buffer. The buffer exists from the moment you save the connection, and the table loads from it on its next sync.
Events land in the buffer first. The table fills the next time it is synchronised, by hand or by its workflow. See Run, stop and troubleshoot loads.
Set Timestamp header if the sender signs "timestamp.body". The endpoint then refuses any request whose timestamp falls outside the Replay window (seconds), which is 300 by default.
The event keeps its headers as a normalised list, but never credential headers such as Authorization or Cookie, and never the header that carries your token or signature.
No. The endpoint answers any sender that can reach it, without a sign-in. The sender security you choose is the only check, so take care before choosing No authentication.
The buffer is removed with the connection, and senders that keep posting to the old endpoint get HTTP 404 Unknown webhook endpoint.