How to create a custom channel

A custom channel connects a system you already run — your order system, a review site, a Zapier zap, anything that can send and receive HTTP — to Atender. Atender gives the channel an ingress URL your system POSTs messages to, and a secret your system uses to sign or authenticate those calls. Every reply an agent sends goes back out over the same webhook, so there’s no email or phone fallback for a custom channel — your system is the only place a reply can land.

This is different from the general-purpose REST API: a custom channel is a configured, named integration with its own routing, delivery log, and health state, set up entirely from Settings.

Before you start

You’ll need:

• Admin access to the tenant.
• A webhook URL on your side that Atender can POST inbound events to, and that you’re prepared to receive deliveries at.
• A plan for where conversations from this channel should land — a default team, and optionally a default agent stack.

If you’re building against Atender’s API more broadly (not just this channel), you may also want an API key with the channels:read / channels:write scopes.

Add a custom channel

1. Go to Settings → Custom Channels.
2. If this is your first custom channel, you’ll see an empty state — click Add custom channel. If you already have one or more, use the same action to add another.
3. Give it a name — something that identifies the system on the other end (for example, “Order system” or “Review site”). This name is what agents see as the channel on the conversation.
4. Enter the webhook URL — the endpoint on your system that Atender will call for outbound events (replies, and any other channel events your integration handles).
5. Save. Atender creates the channel and returns two things you’ll only see once:
   The secret for this channel.
   The ingress URL — the Atender endpoint your system POSTs inbound messages to.

Copy the secret now. It’s shown once, at creation. Atender doesn’t store it in a way it can redisplay later — if you lose it, you’ll need to rotate it and update your system with the new value.

What the ingress URL and secret are for

• Ingress URL — a per-channel Atender endpoint, unique to this custom channel. Your system POSTs to this URL whenever a new message should become a conversation (or a new message on an existing conversation) in Atender.
• Secret — used to authenticate that inbound POST as coming from your system. Keep it wherever you keep other integration credentials for that system; it’s the credential you configure on the sending side (your order system, your Zapier zap, etc.).

Both values live on the channel’s detail view if you need to copy the ingress URL again later — only the secret itself is one-time.

Assign a default team and agent stack

Each custom channel routes to a default team, and optionally a default agent stack, so conversations coming in over that webhook land somewhere sensible without an agent having to triage them first.

1. Open the custom channel from Settings → Custom Channels.
2. Pick a default team from the list of teams on your tenant.
3. Optionally pick a default agent stack to handle the conversation before or alongside a human agent.

Auto-resolve on inactivity

A custom channel can be configured to auto-resolve a conversation after a period of inactivity, the same idea as inactivity handling on other channels. Turn on auto-resolve on inactivity and set the number of minutes of silence after which an open conversation on this channel should resolve itself.

Send a test event

Before pointing real traffic at the channel, use the test-send action on the channel’s detail view to fire a sample event at your configured webhook URL. This confirms your endpoint is reachable and responding before your order system or Zapier zap depends on it.

View and resend failed deliveries

Every outbound call Atender makes to your webhook — replies, test events — is logged as a delivery. From the channel’s detail view:

• Open the delivery log to see each attempt: the event type, attempt number, status (success or failed), the response status code and response time, and, for failures, the error message.
• Click into a delivery to see the full outgoing payload and the response body your system returned.
• If a delivery failed, use resend to queue it again without regenerating the original event.

Rotate the secret

If the secret is compromised, or you’ve lost it and can’t retrieve it (it’s never shown again after creation), rotate it from the channel’s detail view. Rotating issues a new secret — shown once, the same as at creation — and immediately invalidates the old one. Update the credential on your sending system right away, since inbound calls signed with the old secret will stop being accepted.

Auto-disable after repeated failures

If Atender’s calls to your webhook fail repeatedly in a row, the channel auto-disables itself rather than continuing to retry indefinitely. A disabled channel shows the reason it was disabled and stops attempting new deliveries until you re-enable it — typically after you’ve fixed whatever was rejecting the calls on your side (an expired endpoint, a broken auth check, a deploy that changed the response shape). Check the delivery log first; the failed entries there usually show exactly what your endpoint returned.

Replies only flow back over the webhook

There’s no email or phone fallback for a custom channel. When an agent replies on a custom-channel conversation, that reply is sent to your webhook URL and nowhere else — Atender does not fall back to the contact’s email or phone number even if one is on file. Your system is responsible for getting that reply in front of the end user (posting it to your order system’s message thread, your review platform, etc.). If your webhook is down or rejecting calls, replies won’t reach anyone until it’s fixed — which is also why the delivery log and auto-disable behavior exist, so a broken endpoint doesn’t silently swallow replies.