Korean OTP API

Phone verification for apps serving Korean users.

Generate, deliver, and verify one-time codes with K-OTP. Codes arrive by Kakao AlimTalk as part of your application's phone verification flow.

Start in the consoleRead the docsTry it now

Sign up and get 100 free credits (valid for 1 year)

K-OTPAlimTalknow

[K-OTP] 인증번호는 482913입니다. 3분 내에 입력해주세요.

Verification code

  1. queued
  2. sent
  3. delivered
  4. verified

Try it now

Send yourself a code. Nothing is sent, no signup.

Walk through the real issue → verify flow on a simulated phone. Each step shows the request your app would make and the response it would get.

Demo: no message is sent. Your number never leaves this page.

Step 1

Request a code

A Korean mobile number (010-…) or an international number starting with +.

K-OTPAlimTalkDemo
  1. The code arrives here.

Step 2

Enter the code

Request a code first.

The real API call

POST /v1/issuewaiting
# Step 1: issue a code# Server side: use an sk_ key and drop the Origin headercurl https://api.k-otp.dev/v1/issue \  -H "Authorization: Bearer pk_..." \  -H "Origin: https://your-app.example" \  -H "Idempotency-Key: signup-<uuid>" \  -H "Content-Type: application/json" \  -d '{    "phoneNumber": "01012345678",    "purpose": "signup"  }'# Response: waiting for the demo…{  "issueId": "…",  "expiresAt": "…",  "attemptsRemaining": 5,  "queuedAt": "…"}

Your number is masked here; a real request carries the full number. Install the SDK with npm i @k-otp/sdk; cURL works without it.

Ready to send real codes?

Create an account, copy your pk_ and sk_ keys, and go live in minutes.

Sign up and get 100 free credits (valid for 1 year)

Sign upRead the quickstart

Product

Built for the parts of OTP that go wrong

Delivery in Korea has its own channels, carriers, and retry traps. K-OTP handles them behind two endpoints.

  • Delivered by Kakao AlimTalk

    Codes go out as Kakao AlimTalk messages from a registered template. You call the issue endpoint; K-OTP handles the messaging provider.

  • Idempotency and safe retries

    Same key and payload returns the first result. Ambiguous provider outcomes are never auto-resent.

  • Delivery status you can show

    GET /v1/status reports delivery (queued, sent, delivered) and verification separately, plus one overallStatus for your support team.

  • pk_ and sk_ keys

    Public keys call issue/verify from the browser, only from Origins you allow. Secret keys stay on your server.

  • Prepaid credits

    Top up once and pay 1 credit per OTP send. Verifying a code costs nothing extra. Check the balance and ledger over the API. No subscription.

  • OpenAPI-first docs

    An OpenAPI 3.1 spec and a hosted reference, generated from the same contract the server enforces.

How it works

From issued code to verified result

  1. 01

    Issue a code

    Your server (sk_ key) or web app (pk_ key) calls POST /v1/issue with the phone number, a purpose, and an idempotency key. K-OTP generates a 6-digit code and returns an issueId.

  2. 02

    Deliver by Kakao AlimTalk

    The code goes to the user as a Kakao AlimTalk message. Delivery status moves from queued to sent to delivered. Delivered means the message arrived, not that the user is verified.

  3. 03

    Verify what the user typed

    POST /v1/verify with the issueId and the code the user entered. verified: true only when it matches. Codes expire after 3 minutes and allow 5 attempts by default.

  4. 04

    Your app handles the result

    Your application decides what happens next: sign the user in, mark the number as confirmed, or ask again. A verified code shows the user received the message sent to that number; it is not real-name or identity (KYC) verification.

Security and privacy

We keep as little as possible, for as short as possible.

One-time codes guard sign-ups and sign-ins. The defaults assume a breach will be attempted.

  • No raw phone numbers in issue records

    Issue records keep only a hash of the phone number. No API response returns it.

  • Codes are hashed and one-time

    Codes are stored as salted hashes, never returned by the API, and consumed on success.

  • Delivery PII is encrypted, then scrubbed

    Delivery records encrypt recipient fields and are scrubbed about 24 hours after a final status.

  • Browser keys are locked to your Origins

    pk_ keys require an exact Origin match and can only issue and verify.

Add phone verification to your app today.

Create a key in the console and follow the quickstart. Prepaid credits, 1 credit per OTP send, no subscription.

Create an accountSee pricing