Skip to main content

Prerequisites

Before continuing, you should have already completed the following for this connector:
1

Configure the Connector

Enable the connector and set up its connector profile in your project. See Managing Connectors.
https://stackone-logos.com/api/dixa/filled/png

Connector Profile

Dixa - API Key
2

Link an Account

Connect an account using StackOne Hub or Auth Link.
https://stackone-logos.com/api/dixa/filled/png

Link Account

Dixa - API Key

How webhooks are set up

Dixa delivers events through webhook subscriptions, and StackOne provisions them for you — there is no webhook screen to configure inside Dixa and no URL to paste.

1

Connect with an Admin API token

Managing Dixa webhook subscriptions requires an API token created by a Dixa Administrator. Connect the account using such a token — see the connector’s authentication guide for how to generate one.

2

Enable the events you need

When the connection is established, StackOne generates a unique callback URL for it and automatically creates a Dixa webhook subscription covering the events you enable in StackOne. Only the events you enable are subscribed and delivered.

Available webhook events

The events below can be enabled for this connection. Each delivered payload carries the event’s event_fqn shown in parentheses. Only the events you select in StackOne are subscribed in Dixa and delivered.

1

Review conversation lifecycle events

Fired as a conversation moves through its lifecycle.

  • Conversation Created (CONVERSATION_CREATED) — Fired when a new conversation is created.
  • Conversation Open (CONVERSATION_OPEN) — Fired when a conversation is opened or reopened.
  • Conversation Pending (CONVERSATION_PENDING) — Fired when a conversation is set to pending.
  • Conversation Pending Expired (CONVERSATION_PENDING_EXPIRED) — Fired when a conversation’s pending state expires.
  • Conversation Closed (CONVERSATION_CLOSED) — Fired when a conversation is closed.
  • Conversation Abandoned (CONVERSATION_ABANDONED) — Fired when a conversation is abandoned before being answered.
2

Review conversation routing events

Fired as a conversation is queued, assigned, or transferred.

  • Conversation Enqueued (CONVERSATION_ENQUEUED) — Fired when a conversation is added to a queue.
  • Conversation Assigned (CONVERSATION_ASSIGNED) — Fired when a conversation is assigned to an agent.
  • Conversation Unassigned (CONVERSATION_UNASSIGNED) — Fired when a conversation is unassigned from an agent.
  • Conversation Transferred (CONVERSATION_TRANSFERRED) — Fired when a conversation is transferred to another agent or queue.
3

Review conversation content and update events

Fired when the content or metadata of a conversation changes.

  • Conversation Note Added (CONVERSATION_NOTE_ADDED) — Fired when an internal note is added to a conversation.
  • Conversation Message Added (CONVERSATION_MESSAGE_ADDED) — Fired when a message is added to a conversation.
  • Conversation Tag Added (CONVERSATION_TAG_ADDED) — Fired when a tag is added to a conversation.
  • Conversation Tag Removed (CONVERSATION_TAG_REMOVED) — Fired when a tag is removed from a conversation.
  • Conversation Rated (CONVERSATION_RATED) — Fired when a conversation receives a rating.
  • Conversation End User Replaced (CONVERSATION_END_USER_REPLACED) — Fired when the end user on a conversation is replaced.
  • Conversation Custom Attribute Updated (CONVERSATION_CUSTOM_ATTRIBUTE_UPDATED) — Fired when a custom attribute on a conversation is updated.
4

Review message delivery status events

Fired as outbound messages progress through delivery.

  • Message Delivery Sent (CONVERSATION_MESSAGE_DELIVERY_SENT) — Fired when an outbound message is sent.
  • Message Delivery Delivered (CONVERSATION_MESSAGE_DELIVERY_DELIVERED) — Fired when an outbound message is delivered.
  • Message Delivery Seen (CONVERSATION_MESSAGE_DELIVERY_SEEN) — Fired when an outbound message is seen by the recipient.
  • Message Delivery Info (CONVERSATION_MESSAGE_DELIVERY_INFO) — Fired with informational delivery status for an outbound message.
  • Message Delivery Failed (CONVERSATION_MESSAGE_DELIVERY_FAILED) — Fired when an outbound message delivery fails.
  • Message Delivery Spam Complaint (CONVERSATION_MESSAGE_DELIVERY_SPAM_COMPLAINT) — Fired when a spam complaint is received for an outbound message.
5

Review agent moderation events

Fired when an agent bans or unbans an end user or IP address.

  • Agent Banned Enduser (AGENT_BANNED_ENDUSER) — Fired when an agent bans an end user.
  • Agent Unbanned Enduser (AGENT_UNBANNED_ENDUSER) — Fired when an agent unbans an end user.
  • Agent Banned IP (AGENT_BANNED_IP) — Fired when an agent bans an IP address.
  • Agent Unbanned IP (AGENT_UNBANNED_IP) — Fired when an agent unbans an IP address.
6

Review typing events

Fired for real-time typing activity.

  • Typing Started (TYPING_STARTED) — Fired when typing starts in a conversation.
7

Review SLA events

Fired as service-level agreement (SLA) evaluations change state.

  • SLA Evaluation Pending (SLA_EVALUATION_PENDING) — Fired when an SLA evaluation becomes pending.
  • SLA Evaluation Breached (SLA_EVALUATION_BREACHED) — Fired when an SLA target is breached.
  • SLA Evaluation Achieved (SLA_EVALUATION_ACHIEVED) — Fired when an SLA target is achieved.
  • SLA Evaluation Voided (SLA_EVALUATION_VOIDED) — Fired when an SLA evaluation is voided.

Delivery format

How Dixa delivers events to StackOne.

1

Inspect event payloads

Dixa sends each event as an HTTP POST with a JSON body containing event_id (the event’s unique id), event_fqn (the uppercase event name, e.g. CONVERSATION_CREATED), event_version, event_timestamp, an organization object, and a data object with the event-specific payload. Dixa sends one event per request.

2

Signed deliveries

Dixa signs each delivery with an X-DIXA-SIGNATURE header of the form t=<timestamp>,v1=<signature>, where the signature is an HMAC-SHA256 of the payload using a secret generated for the subscription. StackOne additionally verifies each delivery through the unique, unguessable callback URL generated for the connection.

Verify

Your Connector should now be able to receive and process events. Try triggering an event and you should see an Event appear in the Connector logs.