KakaoTalk for business messaging: the operator guide

KakaoTalk is the one APAC champion that answers Korea's messaging question outright: LINE covers Japan, WeChat covers China, Zalo covers Vietnam, and KakaoTalk carries South Korea's near-universal penetration. The regional survey posts — APAC messaging superset and the APAC deep-dive on the four champions — place KakaoTalk on that map. This guide assumes the decision is made: your program addresses Korean recipients on KakaoTalk, and you need the channel's own machinery, not the regional overview.

Everything below describes shipped behavior. The field-level send contract, error codes, and credentialing live in the KakaoTalk channel reference — this post is the operating layer on top: how a tenant runs the channel day to day.

Two business surfaces: Kakao Channel and the Talk Biz Message API

Kakao separates the brand's public home from the send path, and an operator who conflates them misconfigures both.

Kakao Channel (카카오채널, historically PlusFriend) is the brand's profile inside KakaoTalk — followable, searchable, and the object your friendtalk audience accumulates on. Adding your channel as a friend is the opt-in event; follower status determines whether free-form friendtalk can reach a recipient at all.

The Talk Biz Message API is the transactional lane — the gateway your alimtalk notifications travel on. It is reached through a Kakao reseller rather than Kakao Channel tooling directly, and it answers to a sender profile (발신프로필) registered for your brand.

Devotel Orbit's kakao channel wraps the Biz Message gateway behind the same unified messaging surface as every other channel. The connect card under Settings → Channels → KakaoTalk carries the three objects the gateway issues — app key, secret key, sender key — and the channel dispatches both message classes through it.

Channel setup: connect the sender profile once

KakaoTalk is a bring-your-own-credential channel. You own the Kakao relationship; Orbit delivers through it.

1. Provision Biz Message access with a Kakao reseller. Orbit speaks the widely used NHN Cloud Biz Message contract, so any reseller issuing the standard gateway works. On signup you receive a gateway app key, a secret key, and a sender key tied to your registered sender profile (발신프로필). The channel is wired end to end but labeled beta precisely because this provisioning step sits with you.
2. Register your sender profile. The sender key only becomes sendable once the reseller has the profile on file; a send against an unregistered profile fails closed with CHANNEL_NOT_CONFIGURED before it leaves Orbit.
3. Connect in Orbit. In the dashboard, go to Settings → Channels → KakaoTalk and paste all three values. Orbit stores them encrypted at rest under your organization's settings.channels.kakao and never returns them through any API response. Per-organization credentials take precedence over any platform default an operator has set.
4. Approve alimtalk templates. Every alimtalk send names a pre-approved template code; the approval cycle runs with your reseller, not inside Orbit, so sequence it into onboarding. Send rejects a missing template with VALIDATION_ERROR (422) before anything dispatches.
5. Protect the keys. The three values are bearer credentials: whoever holds them can send as your KakaoTalk channel. Keep them out of git, CI logs, and screenshots; scope dev, staging, and production to their own credential sets; rotate immediately with the reseller if you suspect exposure and re-paste in Orbit.

Message classes: alimtalk, friendtalk, consult talk

Kakao's own taxonomy recognizes three business message classes. Orbit ships two of them as sendable classes and treats the third as the conversational workload the inbox serves.

Select the sendable class per message with the kakao_message_type metadata field; alimtalk is the default. The boundary is strict: alimtalk is template-only, and a send without an approved template_name is rejected with VALIDATION_ERROR (422); friendtalk requires a non-empty body and a follower recipient. A worked alimtalk template for a Korean-delivery program looks like this:

[주문 확인] #{name}님의 주문이 접수되었습니다.
주문번호: #{order_id}
배송 예정일: #{eta}

#{name}, #{order_id}, and #{eta} are filled per send from template_params/variables; the approved shape is what the recipient sees.

Friend acquisition: tenant-owned, Kakao-side

Friendtalk's follower gate means acquisition is a program requirement, and it is deliberately tenant-owned: the Kakao Channel QR code and friend-add links are minted by Kakao's channel-manager tooling tied to your channel, published on your receipts, packaging, and web surfaces, and consumed inside KakaoTalk by the recipient. Orbit has no acquisition widget to enable — it consumes follower status as the reachability input and rejects a friendtalk send to a non-follower through the gateway's own rejection code. Design the acquisition loop with your marketing team; measure followership by the friend-add hooks Kakao's channel manager reports; never treat Orbit credential health as a substitute for an empty follower base.

The inbox lane: Kakao threads, one SLA, one disposition set

Inbound KakaoTalk replies and delivery receipts are normalized by Orbit's messaging gateway and relayed to your account automatically — there is no Kakao webhook for you to register. Replies arrive on the standard message.received webhook with channel: "kakao", and in the dashboard the same normalization lands Kakao threads in the unified inbox beside SMS, WhatsApp, LINE, and email, under the same routing, assignment, and SLA clocks. For a Korean customer-support workload — say, a retailer's order-inquiry queue staffed in Seoul — a workable configuration is:

• Routing: a dedicated queue for channel: "kakao" traffic with a Korean-language skill tag, first-response clock of 120 seconds inside business hours, next-response clock of 300 seconds per re-engagement. See inbox routing rules.
• SLA posture: a workspace SLA policy on those conversation timers with a queue-level escalation policy watching the backlog — supervisors are notified when the queue stalls, not only when one thread breaches. Both levels are covered in inbox SLA escalation policies.
• Dispositions: a closed-with-label set the queue's agents and the AI judge assign at close — Resolved, Refund issued, Shipping exception, Escalated to logistics — so the Distribution view and reports read Korean support quality on the same axis as your other queues. Author them under Inbox → Settings → Dispositions; see inbox dispositions.

None of this is Kakao-specific machinery — that is the point. The omnichannel inbox treats a Kakao thread identically to any other channel thread once the reply lands; the channel's own specifics (the kakao channel tag, the metadata echo) live on the envelope, not in a separate conversation model.

Korea's regulatory posture: tenant-owned controls

Two regimes shape Korean business messaging, and both live on your side of the line. PIPA, Korea's Personal Information Protection Act enforced by the Personal Information Protection Commission, decides what you owe each +82 recipient on consent, data-subject rights, and overseas processing. KISA's opt-out notice regime, run with the mobile operators, decides whether SMS traffic delivers at all when you fall back: sender pre-registration, respect for 080 withdrawal numbers, and Korean opt-out keywords on every marketing send. Orbit's South Korea PIPA + KISA posture page maps those rules to tenant-configured controls — consent ledger, opt-out handling, sender pre-registration workflow — and the KYC identity model holds the documents, profiles, and destination links a Korean sender registration typically consumes. The tenant owns which consent prompts to render and when; Orbit enforces whatever tenant-configured controls you set, the same way on every channel. Never read a shipped feature as a compliance pre-approval — Kakao's own content review cycle (template approval, sender review) runs with your reseller regardless of your Orbit plan.

First alimtalk from the SDK

Alimtalk sends through the Campaigns API, because the class is template-bound and recipients are phone numbers rather than follower handles. Launch one:

```typescript Node.js import { Devotel } from '@devotel-orbit/node';

const orbit = new Devotel({ apiKey: process.env.ORBIT_API_KEY });

const campaign = await orbit.campaigns.create({ name: 'Order confirmation — Alimtalk', channel: 'kakao', type: 'blast', audience_type: 'all', message_template: 'order_confirmation_kr_v1', variables: { order_id: 'KR-90210', eta: '2026-06-12' }, }); // The campaign is created as a draft; launch it with // POST /api/v1/campaigns/{id}/send and each recipient's delivery // advances to queued.

Friendtalk direct sends go through `POST /api/v1/messages/kakao` with `metadata.kakao_message_type: "friendtalk"`; the direct endpoint is rate-capped at 80 requests/minute per organization, with `429` and a `Retry-After` header above it. The rejection errors you will actually hit are pre-Kakao-review shapes Orbit fails closed on:

| Code | HTTP | Cause | Fix |
|---|---|---|---|
| `INVALID_RECIPIENT` | 422 | `to` missing or empty | Supply a recipient phone number |
| `VALIDATION_ERROR` | 422 | Alimtalk without an approved `template_name`, or friendtalk without a `body` | Provide the field the chosen class requires |
| `CHANNEL_NOT_CONFIGURED` | 503 | No org-level credentials and no platform default | Connect credentials on Settings → Channels → KakaoTalk |
| `RATE_LIMITED` | 429 | Over 80 sends/minute on the direct endpoint | Honour `Retry-After`; stage volume on the campaigns API |
| `MESSAGE_SEND_FAILED` | 502 | The Biz Message gateway rejected the send (bad template, unfollowed user, upstream error) | Read the gateway result code in the error message |

## Cost arithmetic: per-message reality, no tier fog

Kakao prices Biz Message traffic per message; your reseller's rate sheet, not any bundled plan, is the source of truth. Orbit charges a flat fee per 1M messages for delivery and inbound webhook fan-in on top. There is no monthly minimum tier hiding inside Kakao pricing — the arithmetic is volume-through-rate-sheet plus the platform flat fee, and any program planning projection should model it per message at the real recipient count, not per "seat." Cross-check the current numbers on the [pricing page](https://orbit.devotel.io/pricing).

## Frequently asked questions

### Is KakaoTalk one channel, or two?

One channel entry on Orbit (`kakao`), two Kakao-side surfaces: the Kakao Channel profile your friendtalk followers opt in to, and the Talk Biz Message API your alimtalk notifications travel on. The connect card holds the gateway credentials; the Kakao Channel remains your tenant's own property.

### Alimtalk or friendtalk — which do I send?

Alimtalk for transactional notifications to any phone number (order confirmations, OTPs, shipping updates) through the Campaigns API. Friendtalk for marketing and re-engagement to followers only, through the direct messages endpoint. Kakao's consult talk is not a separate send class on Orbit — the conversational workload runs on the inbound envelope and the inbox.

### A friendtalk send failed with a gateway rejection. Now what?

Read the gateway result code in the error message — a rejection for a non-follower means the recipient is not a friend of your Kakao Channel; correct the audience and retry once. A bad-template rejection means the alimtalk template code, not the recipient. Both are provider rejections, not Orbit blocks.

### Who handles sender registration and content review for Korea?

You do, as the sender. Sender pre-registration and the KISA opt-out regime are tenant-owned controls Orbit exposes; Kakao's own template and content review cycles run with your reseller. Orbit documents the controls in the [South Korea PIPA + KISA posture page](https://docs.orbit.devotel.io/compliance/south-korea-pipa) and enforces whatever you configure — it never pre-approves registration on your behalf.

### How does KakaoTalk pricing work?

Per message, priced by Kakao and your reseller, plus Orbit's flat per-1M platform fee for delivery and webhook fan-in — no opaque tier math. See the [pricing page](https://orbit.devotel.io/pricing).

## Source and further reading

- The [KakaoTalk channel reference](https://docs.orbit.devotel.io/channels/kakao) — the full request/response contract, error codes, rate limits, and credential handling this guide operates on.
- The regional companions: [APAC messaging superset](/blog/apac-messaging-channels-line-kakao-zalo-viber-2026) and the [APAC deep-dive on the four champions](/blog/apac-messaging-channels-line-wechat-kakao-zalo), plus the operator guides for [WeChat](/blog/wechat-channel-operator-guide-2026), [Facebook Messenger](/blog/facebook-messenger-operator-guide-2026), and [Instagram DM](/blog/instagram-dm-operator-guide-2026).
- The [South Korea PIPA + KISA posture page](https://docs.orbit.devotel.io/compliance/south-korea-pipa) and the [KYC identity model](https://docs.orbit.devotel.io/compliance/kyc-identity-model) for the tenant-owned regulatory controls.
- The [cross-channel fallback concept](https://docs.orbit.devotel.io/concepts/cross-channel-fallback) for a Kakao → SMS cascade that covers the non-follower gap.

*Published 1 October 2026.*