Console guide

The console (app.k-otp.dev) is where you manage K-OTP apps, keys, usage, and credits. Everything belongs to an organization: your team or company, with its members, apps and one credit wallet.

Signing in

The console has no passwords. Enter your email on the sign-in page and we send you one email with a sign-in link and a 6-digit code. Enter the code on the sign-in page, or open the link. The link signs in the browser that opens it: if your mail app opens it in another browser, that browser is signed in and the page says so; enter the code in the browser where you asked to sign in to continue there. The code and the link each work once and expire after 15 minutes; if they have expired, request a new email (you can resend after a minute). Safari can fill in the code from Apple Mail. Your first sign-in creates your account, and you can set your name right after. If you were invited to an organization, sign in with the invited email to accept the invitation. Otherwise you create your organization right after setting your name; you can create more organizations and switch between them in the sidebar. Your account settings (profile, security, notifications) are in the user menu.

Apps

An app is the basic unit of K-OTP. Create one app per service (or environment). For example, separate production and staging apps keep keys, usage, and issue history apart.

An app owns:

• API keys (pk_, sk_)
• issue history and usage

All apps of an organization spend credits from the organization's wallet; the ledger shows which app each charge belongs to.

Keys

Issue keys per purpose inside an app.

• Server sk_ keys — pick only the scopes you need: otp:issue and otp:verify for a server that issues and verifies; add otp:dashboard:read, otp:ledger:read, otp:balance, etc. for admin screens or billing jobs.
• Browser pk_ keys — can only hold otp:issue and otp:verify, and you must register the exact origins allowed to call with them (for example https://www.example.com). Wildcards are not supported.

Each key can also have a custom rate limit (per key, per IP, per phone number); the key list shows the limits that actually apply, including the pk_ platform defaults. See Authentication › Rate limits.

Treat key values like passwords. For rotation, revocation, and propagation time (up to about 60 seconds), see Authentication › Rotating and revoking keys.

The Test tab of the keys page holds the app's test keys (pk_test_, sk_test_), which only accept magic test numbers and never send or bill anything. Their issues appear in the app's Test inbox with the fixed code, not in usage or issue history. See Test mode.

Usage

The Usage page shows the volume of all apps in the organization by Korean calendar day (KST), broken down by app or channel. Each app's own usage page shows that app by UTC day. The console also shows issue history and delivery/verification status. The same data is available through the API:

• Issue history: GET /v1/issues, GET /v1/issues/{issueId}
• Single status: GET /v1/status

History never includes phone numbers, codes, idempotency keys, or metadata.

Credits

Organization owners and admins top up the organization's wallet in the console; every member can review the balance and ledger. Issues are rejected with 402 PAYMENT_REQUIRED when credit runs out, so keep enough headroom for your traffic. See Credits & billing.