The fastest way to build an inbox is to let us push changes to you. Webhooks are also how you keep a history longer than our 30-day retention: save every conversation.message.created payload (and apply conversation.message.updated for edits, unsends and status changes) and you have the full thread on your side.
Heads-up: new events arrive as soon as the feature is on. From then on we send your webhook an event for every new DM (conversation.*) and every new comment from other people on posts you published through bundle.social (comment.received, described in Automations). If your webhook has no event filter, you get all of them automatically.Answer every event with a 2xx within 15 seconds, including event types you don’t handle yet. Just ignore them. If your endpoint keeps failing and goes 7 days without a single successful delivery, we disable it automatically. You’ll get an email and a dashboard notification, and you then have to re-enable it (or set up a new one) in the Webhooks dashboard. Events sent while it was disabled are not replayed. More in Webhooks.
Subscribe to these events on your webhook (or leave the event filter empty to get everything):
Payloads use the same shape as the conversation and message objects from the REST API, wrapped in the usual envelope. One difference: the top-level replyTo and privateReplyContext of a message are only filled in on REST reads. In webhooks, look at platformData.replyTo instead, or fetch the message.
Example: A Tiny Inbox Handler
Verify the signature, answer fast, do the real work afterwards:
Deduplicate on data.id + data.updatedAt. Don’t use status for this: edits, unsends and reactions change a message without changing its status. Retries (ours and Meta’s) can occasionally deliver the same change twice.
Outgoing messages reach your webhook already as SENT or FAILED, never as PENDING.