Bird vs Infobip
Bird vs Infobip pour WhatsApp
Tous deux sont des Meta Business Solution Providers avec une API WhatsApp et une API de templates derrière, cette comparaison porte donc sur la forme plutôt que sur la portée. Infobip attribue à chaque type de message son propre endpoint ; Bird offre un seul endpoint pour tous les types et place le choix dans le body.
Ce qu'Infobip fait très bien.
Ce qui distingue Bird.
Ce qu'Infobip fait très bien
Un endpoint qui décrit ce qu'il envoie. Un message texte et un message template sont des chemins distincts dans leur API WhatsApp sortante, si bien qu'une requête se décrit elle-même et qu'un payload ne peut pas contenir une combinaison que l'endpoint n'accepte pas. Lire leur intégration vous dit ce qu'elle envoie sans avoir à lire le body.
Une couverture que Bird n'égale pas. Le même compte et la même URL de base atteignent WhatsApp, SMS, e-mail, voix, RCS, Viber et plus encore, et leurs cinq clients API maintenus sont Java, C#, PHP, Go et Python. Un environnement Java ou C# y est mieux servi et utilise l'API HTTP de Bird à la place.
Une surface agent découpée par produit. Quinze serveurs MCP distants en HTTP, un par produit, authentifiés par une clé API ou OAuth 2.1 avec découverte de scopes. Atteindre WhatsApp seul se fait via un endpoint propre, et un agent limité à WhatsApp ne peut pas déborder sur le reste du compte.
Ce qui distingue Bird
Un réessai qui ne peut pas envoyer en double. Un en-tête Idempotency-Key sur l'envoi rend la répétition sûre. Les clients API générés d'Infobip ne portent aucune clé ni en-tête d'idempotence sur aucun endpoint, et un message WhatsApp en double ouvre une seconde conversation facturable en plus d'agacer le destinataire.
Un seul endpoint d'envoi, tous les types de contenu. Texte, template, image, vidéo, audio, sticker, document, localisation, cartes interactives et de contact sont des champs d'une seule requête. Ajouter un type de contenu revient à ajouter un champ, pas un nouveau chemin, une nouvelle méthode client et un nouveau point d'appel.
Tout le canal derrière une seule connexion agent. 43 opérations WhatsApp sur un seul serveur hébergé à mcp.bird.com : envoi, cycle de vie des templates y compris la soumission à Meta, enregistrement et profil du numéro, et statistiques. Une seule connexion au lieu d'une par produit.
Le comparatif
Capacité par capacité.
Tous deux sont des Meta BSP et tous deux créent des templates via une API, les lignes qui font la différence sont donc rares. Lisez la ligne agent en regard de la page Twilio : c'est un avantage net pour Bird car le serveur de Twilio est uniquement documentaire, tandis qu'ici c'est équilibré car les serveurs d'Infobip opèrent effectivement le compte. Le verdict change selon le concurrent, pas selon nous.
| Capability | Bird | Infobip | Who wins? |
|---|---|---|---|
| Requête d'envoi | JSON vers /v1/whatsapp/messages sur votre hôte régional avec une clé API bearer, et le body sélectionne le type de contenu. | JSON vers un chemin par type de message dans leur API WhatsApp sortante, sur votre URL de base personnalisée, avec une clé API portant un scope d'envoi. | |
| Réessais sécurisés | Un en-tête Idempotency-Key sur l'envoi rend le réessai sûr. | Leurs clients API générés, construits à partir de leur propre spécification, ne portent aucune clé ni en-tête d'idempotence sur aucun endpoint, si bien qu'un réessai après un timeout peut envoyer deux fois. | |
| Ajout d'un type de contenu | Un champ sur la même requête. Un seul endpoint gère texte, template, image, vidéo, audio, sticker, document, localisation, cartes interactives et de contact. | Un endpoint différent, donc une méthode client et un point d'appel différents, pour chaque type de message. | |
| Création et approbation de templates | Créés, versionnés par langue et soumis à Meta via l'API, chaque étape étant également exposée comme outil agent. | Leur API de gestion du service WhatsApp crée et gère également les templates via une API. | |
| Surface agent | Un seul serveur hébergé à mcp.bird.com avec 43 opérations WhatsApp, l'agent se connecte une seule fois et accède à l'envoi, aux templates, aux numéros et aux statistiques. | Quinze serveurs MCP distants en HTTP, découpés par produit, authentifiés par une clé API ou OAuth 2.1 avec découverte de scopes. WhatsApp en fait partie, et atteindre d'autres produits nécessite des connexions supplémentaires. | |
| Événements de livraison et entrants | Un webhook d'espace de travail abonné aux types d'événements WhatsApp que vous définissez, tels que whatsapp.delivered, whatsapp.read et whatsapp.received, signés selon le standard Standard Webhooks. | Un webhook par configuration, avec des rapports de livraison également disponibles en pull si vous préférez interroger plutôt que recevoir. | |
| Un seul hôte pour tout le canal | Envoi, templates, numéros et événements partagent une URL de base et une clé, sur votre hôte régional. | Une URL de base personnalisée par compte sert tous les produits, WhatsApp, SMS et le reste sont donc des chemins sous celle-ci. | |
| Langages SDK | SDK typés pour TypeScript, Python, Go et PHP, ainsi que des clients temps réel pour Swift, Kotlin et le navigateur. | Cinq clients API maintenus : Java, C#, PHP, Go et Python. Le client Node se trouve dans une organisation communautaire séparée, en version 0.3.2, dernière publication en novembre 2023. |
Le même message
Envoi d'un template WhatsApp.
La différence se situe au niveau du endpoint. Infobip adresse directement le chemin du template, ce qui rend la requête auto-descriptive ; Bird adresse un seul endpoint messages et nomme le template dans le corps, ce qui permet au type de contenu suivant d'être un champ plutôt qu'un nouveau point d'appel. L'envoi Bird accepte également un Idempotency-Key.
Infobip
const response = await fetch("https://your-base-url.api.infobip.com/whatsapp/1/message/template", {
method: "POST",
headers: {
Authorization: `App ${process.env.INFOBIP_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
messages: [
{
from: "15557654321",
to: "15551234567",
content: {
templateName: "order_shipped",
language: "en_US",
templateData: { body: { placeholders: ["ord_8f21"] } },
},
},
],
}),
});
const result = await response.json();
console.log(result.messages[0].messageId, result.messages[0].status.name);
Bird
import { BirdClient } from "@messagebird/sdk";
const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });
const orderId = "ord_8f21";
const { data, error } = await bird.whatsapp
.send(
{
from: "+13124495648",
to: "+15551234567",
template: {
slug: "order_shipped",
language: "en_US",
components: [{ type: "body", parameters: [{ type: "text", text: orderId }] }],
},
},
{ idempotencyKey: orderId },
)
.safe();
if (error) console.error(error.message);
else console.log(data.id, data.status);
Coût de migration
Faible à modéré.
Les deux côtés utilisent du JSON avec une clé de type bearer, les champs se transposent donc lisiblement : from et to conservent leurs noms et le template passe du chemin au corps de la requête. L'effort augmente avec le nombre de types de messages envoyés, car chaque endpoint par type d'Infobip se regroupe sur le même appel Bird — c'est une simplification plutôt qu'une réécriture.
Le point de planification relève de Meta plutôt que de l'un ou l'autre fournisseur. Les templates sont approuvés pour le WhatsApp Business Account auquel ils sont rattachés, donc changer de fournisseur implique de les soumettre à nouveau et d'attendre. Bird prend en charge la création, le versionnement par langue et la soumission via l'API, ce qui rend la resoumission scriptable.
Questions réellement posées
Bird est-il une bonne alternative à Infobip pour WhatsApp ?
Les deux permettent-ils à un agent IA de gérer le compte ?
Quel effort représente la migration de l'appel d'envoi ?
Mes templates seront-ils conservés ?
Pour aller plus loin
Le guide d'envoi est le point de départ : il couvre l'appel d'envoi et les règles de fenêtre de conversation.