API OTP WhatsApp untuk Login yang Aman

API OTP WhatsApp untuk Login yang Aman

Login pakai OTP terlihat sederhana di layar End User. Masukkan nomor, tunggu pesan WhatsApp, ketik Kode OTP, lalu masuk.

Di belakangnya, flow ini tidak sesederhana tombol "kirim kode". Backend Client harus tahu kapan kode baru diminta, kode mana yang sedang menunggu verifikasi, kapan sesi login boleh dibuat, dan apa yang harus dilakukan saat kode salah atau pengiriman gagal.

Artikel ini membahas cara merancang API OTP WhatsApp untuk login memakai OTP.ID, dengan fokus pada alur request sampai verify. Contohnya memakai API publik V3 OTP.ID dan placeholder aman, bukan credential asli.

Kenapa login OTP WhatsApp perlu dipikirkan sebagai flow, bukan tombol kirim kode

Kesalahan yang sering terjadi: tim product melihat login OTP sebagai satu aksi, yaitu mengirim kode. Padahal di backend, login OTP minimal punya dua fase.

Fase pertama adalah request OTP. Di fase ini, backend Client meminta OTP.ID mengirim Kode OTP ke nomor End User lewat Channel WhatsApp. Response request berisi otp_id, status pengiriman, Channel, harga request, dan sisa kredit. otp_id ini penting karena menjadi pegangan saat verifikasi.

Fase kedua adalah verify. End User mengetik Kode OTP di aplikasi Client, lalu backend Client mengirim otp_id dan otp ke OTP.ID untuk dicek. Session login aplikasi sebaiknya baru dibuat setelah hasil verify menyatakan verified:true.

Jadi, request sukses bukan berarti End User sudah berhasil login. Request sukses hanya berarti transaksi OTP sudah dibuat dan pengiriman dicoba lewat Channel yang dipilih.

Alur login OTP WhatsApp dari request sampai verify

Alur API OTP WhatsApp untuk login

Untuk login berbasis nomor HP, alurnya bisa dibuat seperti ini.

  1. End User memasukkan nomor HP di aplikasi Client.
  2. Backend Client menormalisasi nomor ke format internasional tanpa tanda plus, misalnya 628xxxxxxxxxx.
  3. Backend Client memanggil POST /v3/request dengan channel:"whatsapp".
  4. OTP.ID membuat Kode OTP, mengirimkannya lewat WhatsApp, lalu mengembalikan otp_id.
  5. Backend Client menyimpan otp_id bersama konteks login sementara, misalnya nomor HP dan tujuan login.
  6. End User memasukkan Kode OTP.
  7. Backend Client memanggil POST /v3/verify.
  8. Jika hasilnya verified:true, backend Client membuat session login untuk End User.

OTP.ID membedakan Client dan End User. Client adalah bisnis atau aplikasi yang mengintegrasikan API OTP.ID. End User adalah pengguna akhir yang menerima Kode OTP. Pembedaan ini penting karena End User tidak memanggil API OTP.ID secara langsung. Semua request API harus lewat backend Client.

Contoh payload request dan verify yang aman

Untuk integrasi baru, API publik resmi OTP.ID adalah V3. Autentikasi memakai header Bearer, jadi API key tidak boleh ditaruh di aplikasi mobile atau browser.

Contoh request OTP WhatsApp dari backend:

curl -X POST https://api.otp.id/v3/request \
  -H "Authorization: Bearer <OTP_ID_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "channel":"whatsapp",
    "destination":"628xxxxxxxxxx",
    "brand":"TokoAnda",
    "otp_length":6,
    "ttl":300,
    "external_id":"login-20260923-0001"
  }'

Beberapa catatan dari payload ini:

Saat response diterima, backend Client perlu menyimpan data.otp_id. Jangan membuat session login hanya karena request ini berhasil.

Contoh verify dari backend:

curl -X POST https://api.otp.id/v3/verify \
  -H "Authorization: Bearer <OTP_ID_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "otp_id":"OTP20260923ABCD000123",
    "otp":"123456"
  }'

Kode salah bukan selalu error sistem. Pada V3, kode yang tidak cocok dapat dikembalikan sebagai HTTP 200 dengan verified:false dan reason:"mismatch". Aplikasi Client perlu menampilkan pesan yang jelas, misalnya "Kode belum sesuai" dan memberi kesempatan mencoba lagi selama batas percobaan belum habis.

Untuk kondisi seperti OTP kedaluwarsa, terlalu banyak percobaan, atau kode sudah pernah dipakai, backend Client perlu menutup flow login sementara dan meminta End User mengulang request dari awal.

Hal yang sering bikin login OTP berantakan

Masalah login OTP biasanya muncul bukan karena endpoint-nya rumit, tapi karena state di aplikasi Client tidak jelas.

Pertama, resend dibiarkan tanpa jeda. End User menekan tombol kirim ulang berkali-kali, backend mengirim request baru terus, lalu support menerima keluhan "kode mana yang harus dipakai?". OTP.ID V3 punya rate limit per API key dan per destinasi, tetapi UI tetap perlu cooldown agar pengalaman End User tidak membingungkan.

Kedua, aplikasi menganggap semua kegagalan sebagai error server. Padahal salah kode, kode kedaluwarsa, terlalu banyak percobaan, dan kode sudah dipakai adalah kondisi produk yang normal terjadi. Masing-masing butuh pesan UI yang berbeda.

Ketiga, backend tidak mengikat otp_id ke konteks login. Jika aplikasi Client punya beberapa flow, misalnya login, ganti nomor, dan konfirmasi transaksi, jangan mencampur state-nya. otp_id dari flow login sebaiknya hanya dipakai untuk menyelesaikan flow login.

Keempat, API key bocor ke frontend. Ini kesalahan serius. API key OTP.ID adalah credential Client dan harus disimpan di environment backend. Browser, aplikasi mobile, atau script publik tidak boleh memanggil API OTP.ID langsung.

Perlindungan backend saat login OTP WhatsApp

WhatsApp, SMS, atau Channel lain untuk login?

WhatsApp sering dipilih untuk login OTP karena familiar bagi End User Indonesia dan pesan bisa membawa konteks brand. Namun WhatsApp tetap punya batasan: nomor End User harus terdaftar di WhatsApp, dan kebijakan platform bisa berubah.

OTP.ID tidak menjalankan fallback otomatis antar Channel. Jika pengiriman WhatsApp gagal, transaksi berstatus failed dan tidak didebit. Keputusan untuk mencoba Channel lain, misalnya SMS atau Voice, ada di sisi Client.

Untuk flow login, ini berarti backend Client perlu punya aturan sendiri. Contohnya: tampilkan tombol "Coba Channel lain" setelah pengiriman gagal, atau setelah End User beberapa kali tidak menerima kode. Jangan menulis copy seolah sistem pasti memindahkan pengiriman otomatis kalau sumber produk belum mendukungnya.

Perbandingan WhatsApp dan SMS juga jangan dibangun di atas angka yang tidak punya sumber. OTP.ID belum memiliki angka delivery rate publik per Channel di knowledge yang boleh dipakai sebagai klaim marketing. Lebih aman menulis batasan teknis dan desain flow yang perlu disiapkan.

Checklist sebelum login OTP masuk produksi

Sebelum memakai API OTP WhatsApp untuk login production, cek beberapa hal ini.

Checklist ini terlihat sederhana, tapi efeknya besar. Login OTP yang baik membuat End User merasa prosesnya singkat, sementara backend tetap punya pagar yang cukup untuk mencegah flow kacau.

Mulai memakai OTP.ID untuk login OTP WhatsApp

OTP.ID membantu Client mengirim dan memverifikasi Kode OTP lewat satu API. Untuk login WhatsApp OTP, bagian pentingnya bukan hanya pengiriman pesan, tetapi juga cara backend Client mengelola otp_id, hasil verify, retry, dan Channel cadangan.

Jika tim product atau engineering sedang merancang login berbasis nomor HP, mulai dari alur paling kecil: request OTP, simpan otp_id, verify kode, lalu buat session hanya saat verified:true. Setelah itu baru rapikan resend, copy UI, dan opsi Channel lain.

Pelajari gambaran produk di https://otp.id atau daftar melalui https://app.otp.id untuk mencoba integrasi OTP.ID dari backend Client.

← SEMUA ARTIKEL