Memilih API OTP untuk aplikasi Indonesia tidak cukup dengan bertanya, “bisa kirim SMS atau tidak?” OTP hari ini menyentuh banyak bagian produk: registrasi, login, reset akun, transaksi, risiko fraud, biaya pengiriman, sampai pengalaman End User saat kode tidak masuk.
Kalau provider hanya mengirim pesan, tim developer masih harus membangun banyak hal sendiri: generate kode, masa berlaku, batas percobaan, retry, verifikasi, audit, dan perhitungan biaya. Untuk aplikasi yang mulai tumbuh, bagian-bagian kecil ini cepat berubah jadi beban operasional.
Artikel ini membahas kriteria memilih API OTP Indonesia dari sisi developer dan product team. Bukan untuk mencari label “terbaik”, tapi untuk membantu Client mengecek mana provider yang cocok dengan kebutuhan aplikasi.
API OTP bukan cuma kirim pesan
API OTP yang matang seharusnya menangani lifecycle kode verifikasi, bukan hanya mengirim SMS atau WhatsApp. Lifecycle itu dimulai dari request kode, pengiriman ke channel yang dipilih, verifikasi kode yang dimasukkan End User, hingga status akhir apakah kode valid, salah, kedaluwarsa, atau sudah pernah dipakai.
Riset kompetitor global menunjukkan banyak provider mulai mengarahkan pengguna dari raw messaging API ke managed verification API. Twilio, misalnya, menulis tentang migrasi dari Programmable Messaging ke Verify API karena OTP membutuhkan token generation, fraud protection, compliance, dan multi-channel delivery. Authgear juga membedakan raw SMS gateway dengan OTP service provider yang mengurus generate, expiry, delivery, fallback, dan fraud protection.
Untuk konteks Indonesia, pertanyaannya menjadi lebih spesifik. Apakah provider mendukung channel yang relevan untuk user lokal? Apakah harga per channel jelas? Apakah response API cukup mudah ditangani saat pengiriman gagal? Apakah developer bisa mencegah double-send saat retry jaringan?
Kriteria 1: Channel yang sesuai dengan user Indonesia
Satu channel tidak cukup untuk semua situasi. WhatsApp kuat untuk user yang aktif di chat. SMS tetap punya jangkauan luas karena tidak butuh aplikasi tambahan. Voice berguna ketika kode perlu didengar lewat panggilan suara. Email bisa menjadi opsi hemat untuk flow web. Missed Call cocok untuk verifikasi berbasis panggilan tak terjawab.
OTP.ID mendukung lima kategori channel: WhatsApp, SMS, Voice, Email, dan Missed Call. Di API publik V3, channel dipilih melalui field channel, sehingga backend Client bisa menentukan jalur verifikasi secara eksplisit.
Poin pentingnya: jangan memilih provider hanya karena satu channel terlihat murah. Lihat apakah channel itu cocok untuk perilaku End User dan skenario produk. Aplikasi PPOB, top-up game, marketplace niche, dan komunitas reseller bisa punya pola user yang berbeda. Ada yang lebih responsif ke WhatsApp, ada yang masih membutuhkan SMS, dan ada yang perlu channel alternatif ketika pesan tidak ideal.
Kriteria 2: API lifecycle lengkap
Provider OTP yang baik menyediakan alur request dan verify yang jelas. Di OTP.ID, integrasi umum dimulai dari POST /v3/request, lalu dilanjutkan ke POST /v3/verify.
Contoh request WhatsApp OTP:
curl -X POST https://api.otp.id/v3/request \
-H "Authorization: Bearer ***" \
-H "Content-Type: application/json" \
-d '{
"channel": "whatsapp",
"destination": "628xxxxxxxxxx",
"brand": "TokoAnda",
"otp_length": 6,
"ttl": 300,
"external_id": "register-1042"
}'
Request memakai destination untuk nomor tujuan, format digit internasional tanpa tanda plus. Response sukses berisi otp_id, status, channel, number, price, last_balance, dan expires_at. Simpan otp_id di database aplikasi karena nilai ini dipakai saat verify.
Contoh verify:
curl -X POST https://api.otp.id/v3/verify \
-H "Authorization: Bearer ***" \
-H "Content-Type: application/json" \
-d '{
"otp_id": "OTP20261001ABCD000123",
"otp": "123456"
}'
Kode salah bukan exception. Pada kontrak V3, mismatch kembali sebagai HTTP 200 dengan verified:false dan reason:"mismatch". Kondisi seperti expired, too many attempts, atau already used dikembalikan sebagai error final sesuai kontrak API.
Detail seperti ini penting. Kalau semua kegagalan dianggap exception, aplikasi Client bisa memberi pesan UI yang salah, retry tidak perlu, atau membuat End User bingung.
Kriteria 3: Kontrol retry dan fallback yang jujur
Banyak artikel kompetitor memakai istilah automatic fallback. Pola itu menarik secara marketing, tapi tidak selalu cocok untuk semua produk. Fallback otomatis bisa membuat biaya sulit diprediksi, membuat End User menerima kode dari channel yang tidak dipilih, atau menyulitkan debugging saat ada komplain.
OTP.ID mengambil pendekatan yang eksplisit. Tidak ada fallback otomatis antar-channel. Jika pengiriman gagal, request dapat berstatus failed, saldo tidak didebit, dan aplikasi Client menentukan channel berikutnya.
Pendekatan ini memberi kontrol lebih besar ke product team. Aplikasi bisa menampilkan pilihan ke End User: kirim ulang lewat WhatsApp, coba SMS, gunakan Voice, atau pakai Missed Call. Biaya dan pengalaman pengguna tetap bisa dirancang secara sadar.
Untuk tim developer, kontrol seperti ini juga mempermudah observability. Setiap keputusan channel tercatat sebagai request yang jelas, bukan hasil rute otomatis yang tersembunyi.
Kriteria 4: Idempotency, rate limit, dan anti double-send
OTP endpoint bisa menjadi sumber biaya bocor jika tidak dikendalikan. Retry dari mobile app, jaringan yang putus, atau user yang menekan tombol kirim ulang berkali-kali bisa membuat kode terkirim lebih dari yang dibutuhkan.
Di OTP.ID, field external_id membantu menjaga idempotency. Request ulang dengan external_id yang sama dan parameter yang sama dalam 24 jam akan me-replay response pertama tanpa debit ulang. Jika external_id sama dipakai dengan parameter berbeda, server mengembalikan 409 DUPLICATE_EXTERNAL_ID.
Rate limit V3 juga berjalan di dua lapis: per API key dan per nomor tujuan per merchant. Per API key, batasnya 20 request per jendela 1 detik. Per nomor tujuan, batasnya 5 OTP per 10 menit dan 10 OTP per jam untuk endpoint pembuatan OTP.
Tetap saja, aplikasi Client perlu memasang pagar sendiri. Beri cooldown pada tombol resend, jangan log kode OTP, simpan API key hanya di backend, dan tampilkan pesan yang jelas ketika user perlu menunggu sebelum meminta kode baru.
Kriteria 5: Harga publik dan biaya yang bisa diprediksi
Biaya OTP tidak hanya soal harga satu pesan. Competitor seperti Authgear banyak menulis tentang biaya 2FA karena struktur harga bisa berbeda: ada yang mengenakan platform fee per verification, ada yang mengenakan biaya channel saja, ada yang menyembunyikan harga di balik sales call.
Untuk aplikasi Indonesia, harga publik membantu tim produk memperkirakan biaya sejak awal. OTP.ID memakai model prepaid pay-per-OTP dengan katalog harga publik:
| Produk | Harga publik |
|---|---|
| WhatsApp Tap-to-Verify | Rp120 / OTP |
| WhatsApp Random Number | Rp370 / OTP |
| WhatsApp Official OTP.ID | Rp495 / OTP |
| SMS OTP | Rp670 / OTP |
| Voice OTP | Rp595 / OTP |
| Email OTP | Rp20 / OTP |
| Misscall OTP | Rp250 / OTP |
Harga bisa berubah jika katalog resmi diperbarui, tapi angka publik memberi baseline untuk menghitung channel mix. Misalnya, aplikasi bisa mulai dari WhatsApp untuk flow tertentu, memakai SMS saat user tidak aktif di WhatsApp, dan memilih Email untuk skenario web yang lebih sensitif biaya.
Yang perlu dihindari adalah menghitung biaya hanya dari satu channel lalu menganggap semua user akan cocok di channel itu. Biaya OTP yang sehat dihitung dari perilaku user, failure handling, retry, dan channel alternatif.
Kriteria 6: Dokumentasi dan debugging
Dokumentasi API bukan pelengkap. Untuk OTP, dokumentasi menentukan seberapa cepat developer bisa memahami status gagal, retry, rate limit, dan verifikasi.
Minimal, provider perlu menjelaskan:
- endpoint request dan verify;
- field wajib dan opsional;
- format nomor;
- response sukses dan gagal;
- error code;
- rate limit;
- perilaku saldo saat gagal kirim;
- cara cek status OTP.
OTP.ID menyediakan dokumentasi publik di docs.otp.id. Untuk tim yang baru mencoba, registrasi publik tersedia di app.otp.id, dan merchant baru mendapat kredit gratis Rp2.000 untuk testing awal.
Kapan OTP.ID cocok dipakai?
OTP.ID cocok untuk Client yang ingin mulai cepat tanpa membangun infrastruktur OTP sendiri. Terutama untuk aplikasi Indonesia yang membutuhkan beberapa channel, ingin biaya lebih terukur, dan ingin kontrol eksplisit atas channel berikutnya ketika pengiriman gagal.
Contoh use case yang relevan:
- aplikasi PPOB dengan login nomor HP;
- aplikasi top-up game yang perlu verifikasi saat checkout;
- marketplace niche yang ingin mengurangi akun palsu;
- komunitas atau reseller app yang butuh registrasi nomor;
- aplikasi internal bisnis yang ingin menambah verifikasi tanpa tim infra besar.
Jika kebutuhan utama adalah “kirim pesan marketing massal”, OTP.ID bukan kategori yang tepat. OTP.ID fokus pada pengiriman OTP verifikasi: kode singkat, masa berlaku terbatas, dan endpoint verify untuk memastikan kode benar.
Checklist memilih API OTP Indonesia
Sebelum memilih provider, cek hal-hal ini:
- Apakah provider mengurus lifecycle OTP, bukan hanya mengirim pesan?
- Apakah channel yang tersedia cocok untuk user Indonesia?
- Apakah ada endpoint verify yang jelas?
- Apakah response gagal bisa ditangani tanpa menebak?
- Apakah ada idempotency untuk mencegah double-send?
- Apakah rate limit dan retry behavior terdokumentasi?
- Apakah harga publik cukup jelas untuk menghitung biaya?
- Apakah dokumentasi bisa dipakai developer tanpa harus menunggu sales call?
Kalau jawabannya “ya”, integrasi OTP biasanya lebih mudah dirawat ketika aplikasi mulai tumbuh.
Untuk mencoba OTP.ID, daftar di app.otp.id, ambil API key dari dashboard, lalu mulai dari POST /v3/request dan POST /v3/verify. Setelah alur dasar stabil, baru rancang pilihan channel yang paling cocok untuk End User aplikasi.