KakaoTalk production patterns: Alimtalk and Friendtalk
This guide walks KakaoTalk (South Korea) end to end: credentials and template registration, choosing between Alimtalk and Friendtalk, the not-a-friend fallback, bulk vs one-off sends, tracking, and payloads that pass or fail validation. The field reference lives on the KakaoTalk channel page; this guide is the ordered playbook for a production integration. The APAC channels onboarding guide is the region-wide survey — start here when KakaoTalk is your Korea channel.1. Beta caveat: bring your own Biz Message credentials
KakaoTalk is a beta channel. Orbit wires the send and receive paths end to end, but onboarding requires you to provision your own KakaoTalk Biz Message access with a Kakao reseller. The gateway speaks the widely used NHN Cloud Biz Message contract, so the reseller relationship, sender profile registration, and template approvals all happen off-Orbit.- Contract with a Kakao Biz Message reseller (NHN Cloud–contract gateway) and register your sender profile (발신프로필). You receive a gateway app key, a secret key, and a sender key.
- Paste all three values in Orbit under Settings → Channels → KakaoTalk. Per-organization credentials take precedence over any platform default and are stored encrypted at rest.
- Role caveat: until your credentials are connected, every send fails closed with
CHANNEL_NOT_CONFIGURED(503).
2. Template registration walkthrough
Alimtalk is template-only. The approval cycle is off-Orbit, and Orbit never re-checks a template’s status — atemplate_name you pass is the code your reseller approved.
- Draft the template body with
#{variable}placeholders for each recipient-specific value (name, order id, ETA). - Submit it through your reseller’s console and wait for Kakao approval. Re-submit after edits — an edited template is a new approval.
- Reference the approved code as
template_name(campaignmessage_template) and fill the placeholders withtemplate_params(campaignvariables).
3. Choose Alimtalk vs Friendtalk
Pick per recipient, not per program. A production integration usually carries both: Alimtalk for transactional traffic, Friendtalk for promotional pushes to followers.
4. Fallback when the recipient is not a friend
The gateway rejects a Friendtalk send to a non-follower at the application layer, and Orbit surfaces it asMESSAGE_SEND_FAILED (502) with the gateway’s result code. Do not drop the send — escalate to Alimtalk:
- On a
faileddelivery-status event wheremetadata.kakao_message_typeisfriendtalk, re-route the recipient to an approved Alimtalk template with equivalent content (“join the channel as a friend for promos” keeps a working template on file for this escalation). - Record the recipient’s preference on your own contact model so later promotional pushes skip Friendtalk for that recipient until a follow event proves the relationship.
message.received with channel: "kakao" as the update to your friend-relationship cache.
5. Bulk vs one-off sends
- One-off / transactional:
POST /messages/kakao(capped at 80 requests/minute per organization) or a small batch job. Use it for OTPs and per-recipient confirmations. - Bulk: the Campaigns API. A campaign throttles, retries, and reports per recipient; a loop over the direct endpoint burns the per-organization minute cap and returns
429 RATE_LIMITED.
6. Tracking: kakao_message_type and suppression handling
Echometadata.kakao_message_type on every send — it comes back on the delivery-status webhook and tells you which branch of your integration produced the delivered / failed outcome. Carry your own idempotency/correlation key in the same metadata map.
Per-recipient suppression handling: when an Alimtalk or Friendtalk send fails, drop the recipient into your suppression and opt-out list — promotional Friendtalk traffic must honor it before the next campaign launch. The suppression list is a tenant-owned control: your organization owns the entry, Orbit enforces the gate.
7. Payloads that pass vs fail VALIDATION_ERROR
Pass — Friendtalk with a body:422 VALIDATION_ERROR (“KakaoTalk Friendtalk requires a message body”).
Fail — Alimtalk with no template (implied when kakao_message_type is omitted):
422 VALIDATION_ERROR (“KakaoTalk Alimtalk is template-only — an approved templateName (templateCode) is required”).
8. Handover: one template, a pick-list of channels
The same concept serves every template-only Asia channel — KakaoTalk Alimtalk, WeChat, Zalo, and Meta-routed channels. Keep the pick-list pattern: one approved template code, one send shape, only the endpoint path changes. The template-only playbook is the consolidated reference; keep KakaoTalk as the Korea cell in that matrix and reuse the sametemplate_name + template_params shape you registered in step 2.
See also
- KakaoTalk channel page — field reference, error codes, and credential handling.
- APAC channels onboarding — LINE, WeChat, Zalo, and the fold-in of KakaoTalk.
- Template-only Asia channels playbook — one approved template across every template channel.
- Campaigns API — bulk sends.
- Message suppression — per-recipient opt-out handling.