How to configure inbound endpoints for a custom channel

A custom channel’s Inbound endpoints panel is where you tell Atender how to receive messages from a third-party system. Each endpoint gets its own URL and secret, its own authentication method, and its own mapping from whatever JSON shape the sender posts into Atender’s conversation and message fields. You can also review each endpoint’s delivery history and replay a specific delivery without asking the sender to resend it.

This is separate from the outbound “test event” and delivery log you already use to verify a custom channel is reachable — inbound endpoints are about receiving, not sending.

Open the Inbound endpoints pane

1. Go to Settings → Channels → Custom and find the channel you want to configure.
2. In that channel’s row, click the inbound-endpoints icon (the down-arrow icon, tooltip Inbound endpoints).

This opens a pane listing every inbound endpoint configured on that channel, alongside actions to create a new one.

Create an endpoint

From the Inbound endpoints pane, create a new endpoint and set:

• Name. A label to tell endpoints apart when a channel receives from more than one source.
• Authentication. Choose how Atender verifies that an inbound request really came from your sender:
• Shared secret — the sender includes a fixed secret value with each request.
• HMAC signature — the sender signs the request body with a secret key, and Atender verifies the signature instead of a raw value in transit.
• Expects a reply. Toggle this on if the sender expects Atender to send a response back through this endpoint (rather than treating the inbound call as a one-way notification).

Saving the endpoint gives you its URL and secret. Point your sender’s webhook configuration at that URL and store the secret (or signing key, for HMAC) on their side.

Map the payload to Atender’s fields

Most senders don’t post JSON that already looks like an Atender conversation, so each endpoint has a mapping editor that translates their shape into ours.

1. Paste a sample payload. In the mapping editor, paste an example of the JSON body your sender actually posts. Atender parses it and offers every path in that payload as a tag you can insert — there’s no fixed vocabulary here, unlike the merge tags used elsewhere in Atender; the available tags come straight from the sample you pasted.
2. Fill in the mapped fields, referencing paths from your sample with {{ }} syntax (for example {{item.data.customer.id}}):

• Conversation key — externalConversationId — Required. The value that ties inbound messages back to one conversation.
• Sender id — sender.externalId — Required.
• Sender name — sender.name — Optional.
• Sender email — sender.email — Optional.
• Message — message.content — Required. Supports multi-line templates.
• Sent at — message.timestamp — Optional.
• Message id — message.externalId — Optional.
• Attachments — message.attachments — Optional.

If your sender posts a batch of items in a single request, use the items/filter fields to point at the array to iterate and the item(s) to select before the field-level mapping runs.

3. Preview the mapping. Run the preview to see, side by side, the sample payload and what Atender would create from it — the mapped conversation/message fields and any mapping errors (for example, a required field left blank or a path that doesn’t exist in the sample). Fix the mapping and re-run the preview until it’s clean.
4. Save the endpoint once the preview looks right.

View and replay delivery history

Each endpoint keeps a history of the requests it has received. From the Inbound endpoints pane, open an endpoint’s delivery history to see past deliveries with their status.

To retry a delivery — whether it failed mapping, failed auth, or you simply want to reprocess it — select it from the history and replay it. Atender resends that exact stored payload through the endpoint’s current configuration, which is useful after you’ve just fixed a mapping error and want to confirm the earlier delivery would now succeed, without waiting for the sender to post again.

Tips

• Keep the sample payload for a given endpoint up to date. If a sender changes their payload shape, paste a fresh sample and re-check the preview before relying on the mapping again.
• Use HMAC signature authentication when the sender supports it — it avoids passing a raw secret with every request.
• If you’re troubleshooting a conversation that never showed up, check the endpoint’s delivery history first: a failed or unmapped delivery there usually explains why nothing landed in the inbox.