irim melalui WhatsApp jika penerima telah memberikan persetujuan untuk menerima pesan dari Anda di sana dan memiliki akun WhatsApp yang aktif; kirim melalui SMS, atau beralih ke SMS, dalam kasus lainnya. Pada Cloud API WhatsApp, pesan ke nomor yang tidak dapat menerimanya akan gagal dengan error 131026, dan Anda hanya akan mengetahuinya dari status webhook, bukan dari respons pengiriman. Pola yang andal adalah mencatat persetujuan saluran setiap pelanggan saat opt-in, memeriksa apa yang secara hukum dapat Anda lakukan sebelum mengirim, dan membiarkan status WhatsApp yang gagal memicu SMS. BroadNet menjalankan kedua saluran di balik satu Omnichannel API dengan aturan fallback yang eksplisit.
Poin-poin utama
- Error 131026 berarti Meta tidak dapat mengirimkan pesan. Meta mencantumkan tiga kemungkinan alasan: nomor tersebut bukan nomor WhatsApp, penerima belum menyetujui ketentuan terbaru, atau penerima menggunakan versi WhatsApp yang lama.
- Respons API yang berhasil hanya berarti permintaan telah diterima. Pengiriman dilaporkan kemudian melalui status webhook: terkirim (sent), terkirim (delivered), dibaca (read), atau gagal (failed), dengan array kesalahan (errors array) saat terjadi kegagalan.
- Memiliki akun WhatsApp bukan berarti mendapatkan izin untuk mengirim pesan kepada seseorang: kebijakan Meta mewajibkan nomor orang tersebut dan persetujuan (opt-in) mereka untuk menerima pesan dari Anda.
- Di luar jendela layanan pelanggan 24 jam, WhatsApp hanya menerima pesan template (jika tidak, akan muncul error 131047).
- Tipe saluran adalah filter pertama: pengiriman SMS ke nomor telepon tetap atau nomor bebas pulsa biasanya gagal dan tetap dikenakan biaya pesan.
- Fallback bekerja paling baik sebagai aturan di platform pengiriman: WhatsApp terlebih dahulu di mana pelanggan memilihnya, SMS saat status gagal atau tidak ada persetujuan WhatsApp.
Apa arti kesalahan WhatsApp 131026?
Dalam referensi kesalahan Cloud API Meta, 131026 adalah "Tidak dapat mengirim pesan". Meta memberikan tiga kemungkinan alasan: "Nomor telepon penerima bukan nomor telepon WhatsApp", penerima "belum menyetujui Ketentuan Layanan dan Kebijakan Privasi yang baru", atau penerima "menggunakan versi WhatsApp lama". Saran perbaikan dari Meta adalah meminta orang tersebut, "menggunakan metode komunikasi non-WhatsApp", untuk mengonfirmasi bahwa mereka dapat mengirim pesan ke nomor bisnis Anda, menyetujui ketentuan terbaru, atau memperbarui aplikasi.
Dengan kata lain, 131026 adalah sinyal perutean, bukan bug dalam kode Anda. Untuk kode OTP, laporan pengiriman, atau pengingat janji temu, metode non-WhatsApp yang dimaksud oleh Meta biasanya adalah SMS, dan harus dikirim secara otomatis alih-alih setelah tiket dukungan.
Mengapa ID pesan tidak berarti pesan telah terkirim?
Pengiriman bersifat asinkron. API menerima permintaan dan mengembalikan ID pesan; apa yang terjadi selanjutnya akan tiba di webhook Anda. Webhook status-pesan Meta melaporkan nilai-nilai ini:
| Status | Deskripsi Meta | Apa yang harus dilakukan |
|---|---|---|
| terkirim | Pesan berhasil dikirim dari server Meta | Tunggu status terkirim atau gagal |
| terkirim | Pesan berhasil terkirim ke perangkat pengguna WhatsApp | Tidak perlu fallback |
| dibaca | Pesan ditampilkan dalam utas obrolan terbuka di perangkat pengguna | Tidak perlu fallback |
| gagal | Kegagalan dalam mengirim atau menyampaikan pesan ke perangkat pengguna | Kesalahan baca[].code; gunakan fallback ke SMS untuk pesan yang sensitif terhadap waktu |
Status gagal menyertakan array kesalahan dengan kode numerik, judul, kolom detail, dan tautan ke referensi kesalahan. Catat kode tersebut bersama dengan pesan: ini memberi tahu Anda apakah harus mencoba lagi, beralih saluran, atau memperbaiki templat. Logika yang sama berlaku untuk SMS, di mana laporan pengiriman (DLR) dari operator berperan sebagai webhook status.
Bisakah Anda mengirim pesan kepada seseorang di WhatsApp hanya karena mereka memiliki akun?
Tidak. Kebijakan Perpesanan WhatsApp Business menyatakan bahwa Anda "hanya boleh menghubungi orang melalui WhatsApp jika: (a) mereka telah memberikan nomor ponsel atau nama pengguna mereka kepada Anda; dan (b) Anda telah menerima izin opt-in dari penerima yang mengonfirmasi bahwa mereka bersedia menerima pesan atau panggilan berikutnya dari Anda." Anda juga harus menghormati setiap permintaan untuk berhenti, baik di dalam maupun di luar WhatsApp.
Jadi, pemilihan saluran dimulai sejak opt-in, bukan pada saat pengiriman. Tanyakan kepada pelanggan saluran mana yang mereka terima, simpan pilihan tersebut beserta stempel waktu, dan hanya kirimkan pesan melalui saluran yang telah mereka setujui. Hukum setempat menambahkan aturannya sendiri: lihat panduan kami tentang PDPL UEA untuk pemasaran SMS dan WhatsApp sebagai salah satu contoh.
Bagaimana dengan jendela waktu 24 jam dan kesalahan 131047?
Pesan WhatsApp format bebas hanya diizinkan dalam waktu 24 jam sejak pesan terakhir pelanggan kepada Anda. Di luar waktu tersebut, Cloud API akan mengembalikan kode 131047, "Telah berlalu lebih dari 24 jam sejak penerima terakhir kali membalas nomor pengirim", dan solusi dari Meta adalah dengan "mengirimkan pesan templat kepada penerima sebagai gantinya". Lihat apa itu jendela waktu 24 jam WhatsApp.
Untuk desain fallback, ini berarti dua kegagalan yang berbeda: 131047 dapat diatasi dengan beralih ke templat yang telah disetujui di WhatsApp, sedangkan 131026 diatasi dengan beralih saluran. Tangani keduanya secara berbeda dalam logika retry Anda.
Saluran mana yang harus Anda gunakan terlebih dahulu?
Tidak ada jawaban tunggal untuk setiap pasar; hal ini bergantung pada pesan dan pada apa yang telah disetujui oleh setiap pelanggan. Kumpulan aturan per penerima mencakup sebagian besar kasus:
| Situasi | Saluran pertama | Cadangan |
|---|---|---|
| Pelanggan telah memberikan persetujuan untuk WhatsApp dan pernah mengirim pesan kepada Anda sebelumnya | WhatsApp (templat di luar jendela 24 jam) | SMS saat status gagal |
| Pelanggan telah memberikan persetujuan untuk WhatsApp, belum ada riwayat | Templat WhatsApp | SMS saat status gagal atau tidak ada status dalam batas waktu Anda |
| Tidak ada persetujuan WhatsApp yang tercatat | SMS | Suara untuk OTP jika didukung |
| Pesan WhatsApp sebelumnya gagal dengan 131026 | SMS | Minta pelanggan untuk mengonfirmasi WhatsApp mereka pada kontak berikutnya |
| Nomor adalah saluran tetap atau bebas pulsa | Bukan SMS: biasanya gagal | Panggilan suara, atau minta nomor seluler |
| Pelanggan telah memberikan persetujuan untuk RCS, Telegram atau Viber | Saluran tempat Anda dapat mengirimkan pesan | SMS |
Untuk tampilan per pasar (di mana WhatsApp, RCS atau SMS memimpin), baca panduan saluran SMS vs WhatsApp vs RCS kami.
Apa yang dapat Anda periksa sebelum mengirim?
Pemeriksaan pertama sama sekali bukan tentang aplikasi: melainkan tipe lini. Pengiriman SMS ke nomor telepon rumah atau nomor bebas pulsa biasanya gagal namun tetap dikenakan biaya pesan. MobileValidate, sebuah merek BroadNet dalam pratinjau pribadi, mengembalikan tipe lini, operator saat ini dan, untuk nomor yang telah dipindah-tangankan (ported), operator asalnya; BroadNet HLR Lookup menambahkan status jaringan secara langsung, memberi tahu Anda apakah lini tersebut dapat dijangkau saat ini.
Untuk pelanggan yang telah memberikan persetujuan ke saluran lain, MobileValidate juga dapat memeriksa apakah nomor mereka terdaftar di Telegram, Viber atau Zalo secara real-time, dan pada Signal, iMessage, RCS, LINE atau Botim dalam pekerjaan massal; pemeriksaan RCS melaporkan platform perangkat genggam jika tersedia. Kebijakan penggunaan yang dapat diterima membatasi pemeriksaan ini hanya untuk pencegahan penipuan dan pemilihan saluran untuk kontak yang telah memberikan persetujuan. Daftar lengkap pemeriksaan tersedia di mobilevalidate.com. MobileValidate adalah layanan independen, tidak berafiliasi, didukung, atau disponsori oleh platform yang diperiksanya; nama-nama mereka hanya digunakan untuk mendeskripsikan cakupan pemeriksaan.
Untuk WhatsApp itu sendiri, sinyal yang dapat diandalkan adalah sinyal yang diberikan oleh Meta: opt-in pelanggan itu sendiri, balasan mereka, serta status terkirim atau gagal dari pesan terakhir Anda. Simpan hasil WhatsApp terakhir per pelanggan dan biarkan hal tersebut memandu pengiriman berikutnya.
Bagaimana BroadNet menangani fallback?
BroadNet adalah penyedia solusi bisnis resmi Meta dan menjalankan WhatsApp Business API, SMS, RCS dan suara dalam satu platform. Omnichannel API menerima satu permintaan dengan aturan fallback eksplisit di seluruh SMS, WhatsApp, RCS dan suara, serta mengembalikan laporan pengiriman yang terpadu, sehingga status WhatsApp yang gagal akan menjadi SMS tanpa kode tambahan pada aplikasi Anda.
- Untuk kode OTP, OTP API mengirimkan dengan fallback otomatis melalui SMS, WhatsApp, suara dan Flash Call; MyOTP.App mencakup SMS, WhatsApp dan Telegram dari satu akun.
- Tetapkan batas waktu untuk pesan yang sensitif terhadap waktu: jika status terkirim maupun gagal tidak tiba tepat waktu, kirimkan fallback.
- Siapkan templat yang telah disetujui untuk setiap jenis pesan yang mungkin Anda butuhkan di luar jendela 24 jam.
- Nonaktifkan saluran untuk pelanggan setelah 131026 hingga mereka mengonfirmasinya kembali, agar Anda tidak membayar untuk kegagalan yang berulang.
Untuk pola lainnya, baca strategi failover multi-saluran kami.
Seperti apa daftar periksa rute per-penerima?
- Saat opt-in, catat saluran mana yang diterima pelanggan, beserta tanggal dan redaksi yang mereka setujui.
- Periksa tipe nomor dari nomor baru dan minta nomor seluler jika nomor tersebut adalah telepon kabel atau bebas pulsa.
- Pilih saluran pertama dari persetujuan dan riwayat pelanggan, bukan hanya berdasarkan setelan default negara.
- Di luar jendela 24 jam, hanya kirimkan templat WhatsApp.
- Pantau webhook status dan laporan pengiriman; perlakukan kegagalan dan waktu habis (time-out) sebagai pemicu fallback.
- Gunakan fallback ke SMS untuk pesan yang sensitif terhadap waktu dan catat kode kesalahan WhatsApp bersama dengan pesan tersebut.
- Tinjau kegagalan setiap minggu: kenaikan 131026 pada satu segmen biasanya berarti nomor sudah tidak aktif atau persetujuan tidak ditemukan.
Pertanyaan yang sering diajukan
Apa arti kesalahan WhatsApp 131026?
"Pesan tidak dapat dikirim." Meta mencantumkan tiga kemungkinan alasan: nomor tersebut bukan nomor WhatsApp, penerima belum menyetujui Ketentuan Layanan dan Kebijakan Privasi terbaru, atau penerima menggunakan versi WhatsApp yang lama.
Haruskah saya mencoba mengirim ulang pesan yang gagal dengan kode 131026?
Jangan langsung mencoba di WhatsApp. Kirimkan konten yang sensitif terhadap waktu melalui SMS sebagai gantinya, dan mintalah pelanggan melalui saluran lain untuk mengonfirmasi nomor WhatsApp mereka.
Apakah respons 200 dari API WhatsApp berarti pesan telah terkirim?
Tidak. Itu berarti permintaan telah diterima. Pengiriman dilaporkan oleh webhook status sebagai terkirim (sent), tersampaikan (delivered), terbaca (read), atau gagal (failed).
Dapatkah saya mengirim pesan kepada pelanggan di WhatsApp jika saya tahu mereka memiliki akun?
Tidak. Kebijakan Meta mengharuskan orang tersebut memberikan nomor mereka kepada Anda dan memberikan persetujuan (opt-in) untuk menerima pesan dari bisnis Anda di WhatsApp.
Apa itu error 131047?
Lebih dari 24 jam telah berlalu sejak pelanggan terakhir kali membalas. Kirimkan pesan templat yang telah disetujui sebagai gantinya, bukan pesan format bebas.
Saluran mana yang harus menjadi fallback untuk WhatsApp?
SMS dalam kebanyakan kasus, karena dapat menjangkau nomor seluler apa pun. Untuk kode OTP, suara adalah fallback tambahan jika platform mendukungnya.
Bisakah saya memeriksa nomor sebelum mengirim?
Ya, sesuai dengan dasar hukum Anda. Periksa tipe jalur terlebih dahulu; untuk pelanggan yang telah memberikan persetujuan (opt-in), MobileValidate dapat memeriksa registrasi pada aplikasi seperti Telegram, Viber, dan RCS, serta BroadNet HLR Lookup memberikan status jaringan secara langsung.
Bagaimana cara BroadNet mengirim SMS fallback?
Omnichannel API menerapkan aturan fallback Anda dalam satu permintaan, dan OTP API akan beralih secara otomatis di antara SMS, WhatsApp, suara, dan Flash Call.
Kami membaca setiap sumber di bawah ini pada 27 September 2026. Lihat standar editorial kami.
Sumber
- Meta untuk Developer — kode kesalahan WhatsApp Cloud API (131026, 131047), diakses 27 September 2026: developers.facebook.com.
- Meta untuk Developer — referensi webhook status pesan, diakses 27 September 2026: developers.facebook.com.
- Kebijakan Perpesanan WhatsApp Business — persyaratan opt-in dan opt-out, diakses 27 September 2026: whatsappbusiness.com/policy.
- MobileValidate — referensi layanan dan pencarian operator, terakhir diperbarui 25 September 2026: mobilevalidate.com/docs/services, mobilevalidate.com/services/carrier-lookup.
- MobileValidate — kebijakan penggunaan yang dapat diterima, diakses 27 September 2026: mobilevalidate.com/legal/acceptable-use.