WhatsApp error 131021 (recipient cannot be sender): why your own number is in the send list

WhatsApp error 131021 is the simplest error on Meta's list. The error codes page describes it as "Sender and recipient phone number is the same" and the solution is just as short: "Send a message to a phone number different from the sender." A WhatsApp business number cannot message itself. The interesting question is not what the error means, but how your own number got into the list of people you were messaging, because if nobody fixes that, the same failure appears in every campaign.

How a business ends up messaging itself

A Cloud API number is not usually logged into a phone, so nobody sends to it by hand. It gets into recipient lists indirectly:

• First tests. A developer connects the number and sets the test recipient in a script or .env file to "our WhatsApp number", meaning the business number itself.
• Store test orders. The shop placed test orders with the business mobile as the customer number. Every order update or abandoned-cart template for those orders now targets the sender.
• Staff and admin alerts. An alert such as "New lead received" is set to go to the business number, so the owner sees it in the app. On a Cloud API number that means sending to yourself.
• Imported contacts. A CSV export from a CRM, from Google Contacts or from the old phone includes the business's own number, often saved as "Office" or the shop's name.
• Coexistence confusion. On a number that runs on both the WhatsApp Business app and the Cloud API, the owner may expect to "forward" a broadcast to their own chat. The number is still the same sender.

What the error looks like

Values illustrative; 919829012345 is both the sender and the to number here:

{
  "error": {
    "message": "(#131021) Recipient cannot be sender",
    "type": "OAuthException",
    "code": 131021,
    "error_data": {
      "messaging_product": "whatsapp",
      "details": "Sender and recipient phone number is the same."
    },
    "fbtrace_id": "AoT5mQ8rWz1kXcN3vLp7yHb"
  }
}

There is no message ID because nothing was sent. Meta charges only for delivered messages, so this costs nothing.

Step-by-step fix

1. Confirm the match. Look up the display phone number of the sending phone number ID (in WhatsApp Manager under phone numbers, or with a GET on the phone number ID) and compare it with the to value, both in the same format.
2. Find where the recipient came from. Was it a test value, an order, an alert setting or a contact? The answer tells you which system to fix.
3. Remove or change the entry. Replace a test recipient with a real personal number; correct the customer number on test orders; point staff alerts at a team member's personal WhatsApp.
4. Add a guard. Before sending, drop any recipient that equals a number connected to your account (see the code below).
5. Resend only if needed. If the message was meant for a person, send it to their own number. If it was a stray test, there is nothing to resend.

A guard like this belongs in the code that builds the recipient list (illustrative):

const digits = (n: string) => n.replace(/\D/g, '');

function withoutOwnNumbers(recipients: string[], ownNumbers: string[]): string[] {
  const own = new Set(ownNumbers.map(digits));
  return recipients.filter((r) => !own.has(digits(r)));
}

// ownNumbers = display numbers of every phone number on the account,
// e.g. ['+91 98290 12345'] -> '919829012345'

Normalise both sides before comparing. +91 98290 12345, 09829012345 and 919829012345 are the same phone for this purpose, so strip symbols and make sure each has the country code before you compare.

How to test a Cloud API number properly

To see what your customers see, use a second phone with a personal WhatsApp account. Either message the business number from that phone (this also opens a 24-hour customer service window, so you can test free-form replies) or send a template from the business number to it. Keep a short list of team test numbers in configuration rather than in code. Our WhatsApp Business API setup guide covers connecting a number and sending the first test.

A worked example

Priya runs Kesar Sweets in Ahmedabad. Her abandoned-cart template goes to a few hundred customers every day, and each daily report shows exactly one failure with 131021 (illustrative). The recipient is the shop's own WhatsApp number.

Tracing it back, she finds two test orders placed in the store with the shop number as the customer phone during setup, both still "abandoned". She deletes the test orders, changes the store's staff alert to her manager's personal number, and adds the shop number to an exclusion list. The daily failure disappears, and the failure count in her reports now means something again, which matters more than the one message.

Preventing 131021

• Exclude your own numbers from every audience automatically, including all numbers in the business portfolio, not only the sending one.
• Never use the business number as a test customer in stores, forms or CRMs. Use a personal test number.
• Send staff alerts to staff phones, never to the business number itself.
• Clean imports. Remove the business's own numbers when you import a contact list.
• Keep failure reports clean so a real problem is not hidden among a few expected self-send failures.

How Broadchat shows 131021

Broadchat has no special handling for 131021: the failed message shows Meta's own error text, and only that recipient is marked failed while the rest of a campaign carries on. To stop it recurring, remove or correct the contact that holds your business number in your contacts, and keep alert numbers pointed at a team member's phone.

For other codes, see the WhatsApp API error codes cheat-sheet, including request-body errors such as 131008 and 131009. The plain-English guide to the WhatsApp Business API explains how numbers, accounts and portfolios relate. Agencies onboarding many clients can run setup and testing in one panel under their own brand through the white-label program.