Reverse OTP: Login dengan WhatsApp Tanpa Mengirim Kode OTP

OTP WhatsApp biasanya bekerja seperti ini: pengguna memasukkan nomor, server mengirim kode, lalu pengguna menyalin kode itu kembali ke formulir. Alurnya familiar, tetapi nomor pengirim menanggung seluruh risikonya. Pesan bisa tertunda, gagal terkirim, dilaporkan sebagai spam, atau ikut terhitung dalam batas WhatsApp untuk pesan kepada orang yang tidak membalas.

Reverse OTP membalik alurnya. Server membuat sesi login, pengguna menekan tautan WhatsApp lalu mengirim pesan yang sudah terisi seperti LOGIN 48213907, dan LoginWA memberi tahu server bahwa nomor pengirim sudah terverifikasi. Nomor bisnis menerima pesan; ia tidak mengirim OTP keluar.

Artikel ini membahas cara kerja Reverse OTP, perbedaan mode any_sender dan phone_bound, contoh integrasi server, serta batas keamanan yang tidak boleh dilewatkan.

Reverse OTP vs OTP WhatsApp Biasa

Reverse OTP bukan pengganti semua OTP. Jika aplikasi memang harus membuktikan bahwa seseorang menguasai nomor tertentu yang sudah tersimpan, mode phone_bound cocok. Jika tujuannya login atau pendaftaran tanpa formulir nomor, mode any_sender justru menghapus satu langkah yang sering membuat pengguna berhenti.

Penjelasan produk dan perbandingan visualnya tersedia di halaman Reverse OTP. Untuk OTP terkirim konvensional, lihat fitur OTP WhatsApp.

Cara Kerja Reverse OTP

Alurnya hanya membutuhkan dua sisi: browser pengguna dan server aplikasi.

1. Pengguna menekan tombol Login dengan WhatsApp.
2. Server memanggil POST /api/v1/auth/reverse/start.
3. LoginWA mengembalikan session_id, message, dan wa_link.
4. Browser menampilkan wa_link sebagai tombol di ponsel atau kode QR di desktop.
5. Pengguna membuka WhatsApp dan mengirim pesan yang sudah terisi.
6. LoginWA mencocokkan kode serta pengirimnya.
7. Server menerima webhook otp.verified atau membaca status sesi lewat polling.
8. Server membuat sesi login aplikasinya sendiri.

Poin terakhir penting: LoginWA memverifikasi nomor WhatsApp. Keputusan akun mana yang dibuat atau dimasuki setelah verifikasi tetap milik aplikasi kamu.

Mode 1: Login dengan WhatsApp (any_sender)

Kosongkan field phone bila pengguna belum memberikan nomor atau memang tidak perlu mengetiknya.

curl -X POST https://api.loginwa.com/api/v1/auth/reverse/start \
  -H "Authorization: Bearer $LOGINWA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

Respons sukses berbentuk seperti ini:

{
  "session_id": "9b2f6c1e-5d0a-4c3e-8f1b-2a7d4e6c9f10",
  "mode": "any_sender",
  "code": "48213907",
  "message": "LOGIN 48213907",
  "receiver_phone": "6281100000001",
  "receiver": "app",
  "wa_link": "https://wa.me/6281100000001?text=LOGIN%2048213907",
  "expires_in": 300,
  "quota_remaining": 99
}

Pada mode ini kode terdiri dari delapan digit. Siapa pun yang mengirim kode valid sebelum kedaluwarsa akan menyelesaikan sesi, dan nomor pengirim itulah yang dikembalikan sebagai identitas terverifikasi.

Karena itu, perlakukan sesi Reverse OTP seperti tautan login sekali pakai:

• tampilkan wa_link hanya di browser yang memulai login;
• simpan keterkaitan session_id dengan sesi browser di server;
• jangan membagikan kode atau tautan ke grup, email publik, atau URL yang dapat ditebak;
• setelah verified, tandai sesi sebagai sudah dipakai dan jangan terima verifikasi kedua.

Mode 2: Verifikasi Nomor yang Sudah Diketahui (phone_bound)

Kirim phone jika aplikasi sudah memiliki nomor yang harus dibuktikan, misalnya saat pendaftaran, perubahan nomor, atau pemulihan akun.

curl -X POST https://api.loginwa.com/api/v1/auth/reverse/start \
  -H "Authorization: Bearer $LOGINWA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"phone":"6281234567890"}'

LoginWA menggunakan kode enam digit pada mode ini. Hanya pesan dari nomor yang cocok yang dapat menyelesaikan sesi. Mode ini memberi batas identitas lebih ketat, tetapi pengguna tetap harus membuka WhatsApp dari nomor tersebut.

Pilihan praktisnya:

• gunakan any_sender untuk login dan pendaftaran cepat;
• gunakan phone_bound untuk membuktikan nomor yang sudah diklaim pengguna;
• gunakan OTP terkirim bila pengguna tidak dapat mengirim pesan WhatsApp dari perangkatnya.

Menerima Hasil: Polling atau Webhook

Setelah sesi dibuat, server dapat polling setiap dua sampai tiga detik:

curl https://api.loginwa.com/api/v1/auth/reverse/SESSION_ID \
  -H "Authorization: Bearer $LOGINWA_API_KEY"

Status yang mungkin diterima adalah pending, verified, expired, dan failed. Saat berhasil, respons berisi nomor pengirim dan waktu verifikasi:

{
  "session_id": "9b2f6c1e-5d0a-4c3e-8f1b-2a7d4e6c9f10",
  "status": "verified",
  "phone": "6281234567890",
  "verified_at": "2026-10-15T08:15:42+00:00"
}

Untuk aplikasi produksi, webhook biasanya lebih bersih karena browser tidak perlu terus bertanya. LoginWA mengirim event otp.verified; server kemudian mencari sesi lokal berdasarkan session_id, memvalidasi statusnya, lalu membuat login session. Detail event dan endpoint lengkap ada di dokumentasi API.

Jangan membuat sesi login hanya karena browser mengaku sudah menekan tombol WhatsApp. Sesi hanya boleh dibuat setelah status dari API atau webhook menyatakan verified.

Contoh Alur Server yang Aman

Kerangka berikut sengaja tidak terikat framework:

1. Browser meminta POST /login/whatsapp/start ke server aplikasi.
2. Server memanggil LoginWA dan menyimpan session_id, waktu kedaluwarsa, serta pengenal sesi browser.
3. Server mengembalikan wa_link ke browser.
4. Browser membuka WhatsApp atau menampilkan QR dari wa_link.
5. Webhook LoginWA masuk ke server.
6. Server memastikan session_id dikenal, belum dipakai, dan belum kedaluwarsa.
7. Server mencari atau membuat akun berdasarkan nomor terverifikasi.
8. Server membuat sesi login dan menandai sesi Reverse OTP sebagai selesai.

Jika memakai polling, ganti langkah webhook dengan endpoint status. Jangan mencampur keduanya tanpa status lokal yang idempoten; webhook dan polling dapat melihat keberhasilan yang sama.

Nomor Siapa yang Menerima Pesan?

Respons start berisi receiver dan receiver_phone.

• Jika app memiliki device online, pesan masuk ke nomor app tersebut.
• Jika belum ada device online, nomor verifikasi LoginWA dapat menerima pesan.
• Jika device_id ditentukan secara eksplisit, LoginWA tidak mengalihkannya ke device lain.

Artinya, pengujian awal dapat dilakukan sebelum menghubungkan nomor sendiri. Untuk pengalaman brand yang konsisten, hubungkan nomor bisnis dan pastikan field receiver sesuai harapan sebelum rilis.

Error yang Perlu Ditangani

Siapkan UX untuk kondisi berikut:

• 503 no_device_connected: app dan LoginWA tidak memiliki nomor penerima online.
• expired: pengguna membuka WhatsApp terlalu lama; buat sesi baru.
• failed dengan sender_hidden: nomor pengirim tidak dapat dibaca; tawarkan OTP terkirim sebagai fallback.
• 404 session_not_found: sesi bukan milik app API key yang dipakai.
• Sesi sudah dipakai: tolak pembuatan login kedua dari session_id yang sama.

Fallback penting karena tidak semua konteks cocok untuk Reverse OTP. Misalnya, nomor yang disembunyikan oleh pengaturan atau alur perangkat tertentu tidak boleh membuat pengguna terkunci dari akunnya.

Kapan Reverse OTP Lebih Cocok?

Reverse OTP kuat untuk:

• login passwordless bagi pengguna yang memang aktif di WhatsApp;
• pendaftaran tanpa formulir nomor;
• verifikasi nomor saat onboarding;
• aplikasi yang nomor pengirim OTP-nya sering terkena pembatasan;
• produk yang ingin membayar hanya untuk login berhasil, bukan sesi yang ditinggalkan.

OTP terkirim tetap lebih cocok bila alur harus dimulai dari nomor yang dimasukkan pengguna dan tidak ada cara baginya untuk mengirim pesan. Perbandingan biaya dan delivery kedua pendekatan dibahas di OTP WhatsApp vs SMS, sedangkan implementasi OTP konvensional di Laravel ada di tutorial login OTP WhatsApp Laravel.

Biaya dan Cara Mencoba

LoginWA menagih satu kuota untuk setiap login Reverse OTP yang berhasil. Sesi kedaluwarsa atau ditinggalkan tidak dihitung. Paket Free memberi 100 pesan per bulan untuk pengujian, sedangkan paket berbayar mulai dari $1. Angka dan kuota yang berlaku selalu dicek di halaman harga.

Mulai dengan membuat akun di LoginWA, buat app dan API key, lalu panggil endpoint reverse/start. Tampilkan wa_link hanya pada sesi browser yang memintanya dan buat sesi login setelah menerima verified. Itu seluruh fondasinya: pengguna mengirim satu pesan, server menerima bukti nomor, dan nomor bisnis tidak perlu mengirim OTP sama sekali.