When should I use the API vs a built-in channel?
Use a built-in channel when one fits. Use the API only when none of them do.
Use the built-in channels first
Atender’s built-in channels — Email, Web Chat, Voice, SMS, WhatsApp, Messenger, Amazon — handle inbound and outbound traffic, identity, attachments, channel-specific quirks (DKIM signing for email, embed code for chat, IVR for voice) and a settings UI you can configure without writing code. They’re also the channels your team’s analytics, automation, and AI features are tuned for.
If your support traffic comes in through one of these channels, the built-in channel is almost always the right answer. Don’t rebuild what Atender already does.
Use the API when there’s no built-in fit
The API is the right tool when you have a touchpoint that lives outside what Atender supports natively:
- A custom in-app chat in your own product that doesn’t use Atender’s Web Chat widget.
- A marketplace inbox Atender doesn’t integrate with (Etsy, eBay, a regional platform).
- A legacy ticketing system you’re migrating off, where you want the open tickets to land in Atender as conversations.
- A backend signal that should become a conversation — a transaction flagged by fraud detection, a critical health-check failure, an upgrade request from a billing system.
In each of these cases, you push the conversation in via POST /v1/conversations/outbound, you subscribe to message.sent to ship agent replies back to wherever the customer is, and your application acts as the bridge between Atender and the external system.
What if there’s almost a built-in channel?
If a built-in channel almost works but doesn’t quite — for example, you use WhatsApp Business API through a provider Atender doesn’t directly integrate with — you have two choices:
- Use the built-in channel and live with whatever gap there is.
- Use the API and rebuild the bridge yourself.
The second option gives you more control but adds a custom integration to maintain. Most tenants are better served by option one unless the gap is genuinely blocking.
What you give up with the API
- A settings UI. All configuration is in your code.
- Channel-specific features. A “channel: email” conversation pushed via the API doesn’t go through your verified Mailgun domain unless you wire that up — the channel field is a tag, not a transport.
- Provider features. Things like Mailgun’s deliverability metrics, Vonage’s number provisioning, the Web Chat widget’s appearance customization — none of that applies. You’re building the integration end to end.
What you get with the API
- Full programmatic control. Push conversations from anywhere your server can reach.
- Long-lived authentication. API keys don’t expire.
- Outbound webhooks for every event. Your server can react to whatever happens in Atender.
- No UI lock-in. You can build whatever surface makes sense for your team.