A support team answering conversations needs different tooling from a service sending automated notifications. Test the workflow your team will operate before comparing a provider's price per message. If you need other channels, confirm that the same platform and account can support them.
What does the provider control, and what does Meta control?
Meta sets the channel's policies and template-approval rules. The provider supplies the integration, tooling and support your team uses.
Meta's business policy governs customer permission and when a template is required. A provider cannot waive those requirements or guarantee that Meta approves a template.
Provider behavior still affects whether your application sends a valid request and handles the result correctly. Evaluate validation, error reporting, retry support and delivery visibility as part of the integration.
Confirm who owns the WhatsApp Business Account and who retains administrative access. Ask how the number and account can move when you change providers.
Use this ownership and readiness check before authorizing a provider connection:
| Asset or step | Confirm before signup | Evidence to retain |
|---|---|---|
| Business portfolio | The Meta business container, legal business and administrator are correct | Administrator access and business details |
| WhatsApp Business Account | The account holds the templates and intended number | Account identifier and owner |
| Phone number | Your team controls the number and its verification route | Number, OTP route and registration state |
| Provider access | The authorization screen shares only the intended assets | Consent record and provider workspace |
| Connection result | The account moves from pending to connected | Status, next action and error details |
Complete the provider's signup flow from the business administrator's account. A finished browser flow does not prove that verification or sending is complete. Read the connected number's status before designing a send test.
How should I compare prices?
Compare applicable Meta message charges and every provider fee for the same expected workload.
Meta's platform pricing depends on message category and recipient market. It charges for delivered messages, with exemptions for qualifying messages and volume tiers where applicable.
Ask the provider to separate its charges from Meta's. Include any number, seat, setup or support fees in the proposal before calculating your operating cost.
Check the returned cost object when reconciling a send. Its transaction_amount is Bird's platform charge. Its passthrough_amount is the Meta message charge Bird passes on. The cost can be null before pricing or when a message is rejected before pricing. A missing price does not prove that a message is free.
Use Bird's WhatsApp pricing for the published rates. Compare total costs for the workflow, including the people needed to operate it.
Compare 360dialog, Wati, Twilio and Infobip using the same expected workload.
Which API operations should I test?
Test sending, account setup and recovery using the credentials your application will actually hold.
| Task | What to verify |
|---|---|
| Send a message | Required fields, validation errors and the returned message identifier |
| Manage templates | Creating a draft, submitting it and retrieving a rejection reason |
| Connect a number | Ownership requirements, verification and the path to a usable sender |
| Inspect delivery | Status, event history and the explanation for a failure |
| Retry an operation | Idempotency behavior and documented rate-limit handling |
Confirm which tasks require a signed-in person rather than an application credential. Support in a CLI or MCP tool does not establish that a workspace API key can perform every operation.
When evaluating an SDK, check the published package and the operations it exposes. Request snippets alone do not establish that a maintained library covers your workflow.
Run the number precheck before buying a candidate for Bird's connection flow.
What delivery and support evidence should I require?
Require identifiable delivery events, verifiable webhooks and enough retained history to investigate a failed send.
A successful send response does not establish delivery. Ask the provider to demonstrate a later failure and show how your application receives its reason.
Bird exposes separate failed and rejected outcomes. Confirm how your handlers act on each outcome before using the integration in production.
Check the webhook signing scheme and delivery-retry behavior. Agree how long messages and events remain available, including what you can export when leaving.
Give support a message identifier when investigating an individual send. Ask which additional request details the provider needs so your logs can preserve them.
Bird support can investigate the reported state; Meta controls restriction and ban reviews.
Which provider should I choose?
- Choose an inbox product when the main task is people answering customer conversations.
- Choose an API provider when your application must own sending, delivery handling and retry state.
- Choose a platform covering your required channels when the workflow spans more than WhatsApp.
- Sign only after testing the required operations and agreeing costs, account access and migration arrangements.
In short
Separate Meta's rules from the provider's service.
Meta sets messaging policies and reviews templates. Your provider supplies the integration and support around those rules.
Compare the complete price.
Include applicable Meta message charges and the provider's own fees, including any seats, numbers or setup work.
Test the operations you need.
A send API does not establish that you can manage templates, numbers and failure recovery without dashboard work.
Agree how you can leave.
Confirm account ownership, number migration and data export before signing with a provider.