agent_identity_id to the owning identity. Select slack.* event types alone or mix them with other notification types on the same identity-owned subscription.
Event types
Availability depends on Slack permissions and the events the app receives. Subscribing does not grant new conversation access. There are no Slack delivered or read event types.
Register a subscription
cURL
201 with the subscription object. Capture any one-time signing key returned during creation and verify deliveries using the identity’s signing key.
An identity can have separate subscriptions for different destinations. At one exact destination URL, the same identity and event type can appear on only one active subscription. Overlapping registration normally returns 409.
A Slack-only create using agent_identity_id can instead reuse an existing mixed subscription. Omit auth_token and context_config. Exactly one active subscription for that identity and exact URL must overlap the requested events, and it must already mix event families. The 201 response returns its existing ID, adds only missing events, and preserves its other events and settings. Ambiguous matches, a single-family existing subscription, or a create that specifies authentication or context still return 409 on overlap. This compatibility behavior does not make all creates idempotent. Updating or deleting the returned mixed subscription still requires scope=identity.
A subscription may store context_config, but it enriches only received email, text, and iMessage events. Slack events ignore it. Fetch live or retained Slack history explicitly when your runtime needs it.
Select incoming messages
Choose the incoming event types you need directly inevent_types. There is no separate Slack filter. Selections cover all accessible conversations across the identity’s connected workspaces. Subscribing does not grant access to additional conversations.
A message can match several incoming types. For example, a mention in a channel thread matches slack.mention_received, slack.thread_reply_received, and slack.channel_message_received. Inkbox creates only one delivery per subscription for that message, with a stable event id.
The delivered event_type is one of the matching types selected by that subscription. If several selected types match, the priority is:
slack.mention_receivedslack.thread_reply_receivedslack.dm_receivedslack.group_dm_receivedslack.channel_message_received
slack.channel_message_received still delivers a channel mention under that selected type. Selecting all three matching types delivers it as slack.mention_received, without additional thread or channel deliveries.
slack.thread_reply_received covers any received reply whose timestamp differs from its thread root. It does not remember which threads your runtime watches. Edits and deletions use their own slack.message_updated and slack.message_deleted selections, without message-kind restrictions.
Change event selection
event_types to replace the complete selection. Omit it to preserve the current selection. Include any other notification types you want to keep:
scope=identity for updates or deletion. Without it, the server returns 409 without changing the subscription. Use the same scope when listing all subscriptions for an identity.
The shared webhook catalog includes all 23 Slack event types.
Payload
Message webhooks include available sender details without requiring a separate lookup. Treat
actor_profile and its fields as optional: profile retrieval or Slack permissions may leave only actor_id. Email additionally requires users:read.email. Native Slack profiles use the connection’s Slack permissions independently of Inkbox contact visibility. Missing enrichment does not prevent the message from arriving.
Automatic contacts
Incoming activity from a human participant can link that Slack account to an existing organization contact or create a shared, unreviewed contact. This is encounter-driven: listing users or channel members does not import them, and Inkbox does not copy the whole workspace directory. Inkbox uses an available, Slack-confirmed email for automatic matching. Missing or unconfirmed email produces a Slack-only contact rather than matching another person by that address. Once an account is linked, its workspace and user IDs provide the stable association; an email change does not automatically reassign an established link. A contact can have accounts in multiple workspaces. New unreviewed contacts can include the available display name, first name, last name, job title, and confirmed email. Existing curated values are preserved. Profile phone numbers, photos, and status remain available through the Slack profile; a profile phone number is not automatically added as an active contact phone number. Review and add a phone number explicitly if needed. New contacts are shared within the organization by default and marked unreviewed. Contact visibility and Profile access still controlcontact_id and linked accounts in contact reads; an email match grants no additional access or communication permissions. Use contact_id with the Contacts API when present.
Event content varies by type. Message events include available message content. Deletion events identify the deleted timestamp without promising the deleted text. Reaction and pin events include item references. File events can include a file_id and metadata; fetch file content separately. Send-outcome events include action details for correlation with the message API.
Connection changes include event.status. A Slack rate-limit notice can use slack.connection_changed with reason: "rate_limited" while the connection remains connected; it does not mean the app was disconnected.
Delivery and runtime behavior
Verify the signature against the raw request body, then deduplicate usingid. Return a successful HTTP status after durably accepting the event. The response body does not control Slack behavior.
Deliveries can arrive more than once or out of order, including events from the same conversation. Do not infer conversation order from webhook arrival order.
Retries are bounded in time and attempts; delivery is not guaranteed indefinitely. Events received while an identity is paused do not produce queued wakes for later resume. Use retained history for recovery when needed.
Retries keep the same logical event ID. Overlapping message and app-mention notifications for one post resolve to one logical event. Matching more than one message kind does not create additional deliveries for a subscription. Your own bot’s message echoes are not inbound message events; use send-outcome events to track its sends.
An app-mention notification that arrives shortly after the ordinary message can identify the same message as a mention. Inkbox can then deliver it to an existing slack.mention_received subscription that did not match the first notification, without delivering it again to a subscription that already matched or changing that delivery’s selected event type. This enrichment window is 60 seconds; it is not historical replay for a newly created or changed subscription.
Message capture is independent of subscription matching. Restricting wakes to mentions does not restrict retained history to mentions. Paused identities can continue capture without webhook wake delivery.
Your runtime owns wake rules, watched-thread state, follow-up behavior, and memory. A broad subscription is not a request for Inkbox to wake the agent on every event. Decide what matters after receiving the event, and fetch only the history needed for that decision.
Inkbox receives configured interaction callbacks; its public API does not create slash commands, shortcuts, interactive message layouts, or views. Subscribing to slack.interaction alone does not make those interfaces available. They must already be configured and sent by the Slack app.
slack.interaction carries supported action, shortcut, view, or command inputs. slack.session_stopped carries a stop signal and any available thread coordinates. Your runtime must interpret these signals and perform any action or cancellation. Receipt alone does not run commands or stop work.
Diagnostics and replay
Slack delivery diagnostics expose event coordinates and delivery status, not the original message body. Do not use the delivery log as message history. A diagnostic withresponse_status: null and
error_detail: "Webhook delivery could not be prepared" means Inkbox could not
prepare that delivery; it does not mean your endpoint was contacted. A receiver
failure instead uses Webhook endpoint did not acknowledge delivery. Events that
expire before an attempt are not represented as fictitious receiver attempts, so
the delivery log is not a complete event ledger.
Historical Slack webhook replay is unsupported. A replay request returns 422. Reconnection does not backfill missed events. Use live conversation reads or the retained archive and explicit backfills for context, subject to the connection’s remaining access. Backfill imports history; it does not replay old webhook wake events.