Bird vs 360dialog
Bird vs 360dialog dla WhatsApp
360dialog to dostawca wyłącznie WhatsApp i w tym porównaniu to skupienie jest widoczne. Przekazują payload Meta bez zmian, publikują cennik i prowadzą własny hostowany serwer MCP. Bird to platforma, w której WhatsApp jest jednym z wielu kanałów, a agent może na nim wysyłać wiadomości.
W czym 360dialog jest świetny.
Czym różni się Bird.
W czym 360dialog jest świetny
Payload Meta, bez zmian. Ich ciało żądania to kształt wiadomości Cloud API: messaging_product, recipient_type, to, type i odpowiadający obiekt typu. Zespół, który już ma kod Cloud API, zmienia host i nagłówek autoryzacji, zachowując payload — to najkrótsza ścieżka migracji w tym porównaniu, której Bird nie może zaoferować.
Opublikowany cennik, samoobsługowo. Każdy tier to miesięczna kwota za numer WhatsApp, a opłaty konwersacyjne Meta są przekazywane osobno; tiery partnerskie publikują również opłaty platformowe i za kanał. Możesz wyliczyć koszty wdrożenia ze strony internetowej, nie rozmawiając z nikim.
WhatsApp to cała firma. Brak e-maila, SMS, głosu — i strona statusu oddzielająca ich własne komponenty od komponentów Meta. Jeśli WhatsApp to Twój jedyny kanał i chcesz dostawcę, którego roadmapa nie może zostać odciągnięta w inną stronę, to skupienie jest argumentem — i to realnym.
Czym różni się Bird
Agent, który może wysłać wiadomość. Obaj prowadzą hostowany serwer MCP i tu leży różnica: narzędzia 360dialog zarządzają szablonami, profilami i webhookami, a ich dokumentacja opisuje tworzenie przykładowego ciała JSON do wysyłki przez ich Messaging API. 43 narzędzia WhatsApp Bird obejmują samą wysyłkę i rejestrację numeru.
Ponowienie, które nie wyśle podwójnie. Nagłówek Idempotency-Key przy wysyłce sprawia, że powtórzenie jest bezpieczne. Ich dokumentacja wiadomości nie wspomina o kluczu ani nagłówku idempotentności, a na WhatsApp duplikat otwiera drugą płatną konwersację zamiast po prostu się powtórzyć.
Typowany SDK zamiast koperty Meta. Przekazywanie kształtu Cloud API oznacza dziedziczenie jego ergonomii: messaging_product w każdym żądaniu i typ treści powtórzony zarówno w type, jak i w obiekcie obok. Wysyłka Bird to jedno typowane wywołanie, którego ciało nazywa treść bezpośrednio — w TypeScript, Python, Go lub PHP.
Macierz
Funkcjonalność po funkcjonalności.
Obaj są Meta BSP i obaj prowadzą hostowany serwer MCP, co czyni to najbliższym porównaniem w serii na osi, na której Bird zwykle wygrywa. Przeczytaj wiersz agenta na stronach Twilio i Infobip: tam Bird wygrywa z innych powodów, a tutaj zależy od jednego — czy agent może wysłać.
| Capability | Bird | 360dialog | Who wins? |
|---|---|---|---|
| Żądanie wysyłki | JSON na /v1/whatsapp/messages na Twoim regionalnym hoście z kluczem API jako bearer, a ciało żądania nazywa typ treści bezpośrednio. | JSON na endpoint messages na hoście WABA z nagłówkiem D360-API-KEY. Ciało żądania to kształt Cloud API Meta: messaging_product, recipient_type, to, type i odpowiadający obiekt. | |
| Bezpieczne ponowienia | Nagłówek Idempotency-Key przy wysyłce sprawia, że ponowienie jest bezpieczne. | Ich dokumentacja wiadomości nie wspomina o kluczu ani nagłówku idempotentności, więc ponowienie po przekroczeniu limitu czasu może wysłać wiadomość dwukrotnie. | |
| Co może zrobić agent | 43 narzędzia WhatsApp na hostowanym serwerze mcp.bird.com, w tym sama wysyłka, cykl życia szablonów przez zgłoszenie do Meta, rejestracja i profil numeru oraz statystyki. | Hostowany serwer na mcp.360dialog.com/mcp, którego narzędzia tworzą, podglądają, listują i usuwają szablony, ustawiają nazwę wyświetlaną kanału i profil, konfigurują webhooki oraz odczytują konta, kanały, saldo i faktury. Ich dokumentacja opisuje generowanie przykładowego ciała JSON do wysyłki przez ich Messaging API. | |
| Jak zachowuje się narzędzie z ograniczonym dostępem | Narzędzie, którego Twoje uprawnienie nie może wywołać, pozostaje widoczne i jest opatrzone adnotacją z wymaganym zakresem, a odmowa odpowiada krokiem podwyższenia OAuth. Ukrywanie było testowane i usunięte: powodowało, że brakujący zakres był nieodróżnialny od brakującej funkcjonalności, a agenci wyciągali ten drugi wniosek. | Zakresy są wybierane w momencie autoryzacji, a odmowa jednego ukrywa odpowiednie narzędzia, więc agent nigdy nie widzi narzędzia, którego nie może wywołać. | |
| Typy treści | Jedno ciało żądania wybiera tekst, szablon, obraz, wideo, audio, naklejkę, dokument, lokalizację, interaktywne lub karty kontaktów. | Jeden endpoint wysyłki obsługuje pełną listę typów Meta: text, image, audio, video, document, sticker, location, contacts, interactive, template i reaction. | |
| Typowane SDK | Typowane SDK dla TypeScript, Python, Go i PHP, generowane z API. | W ich indeksie dokumentacji nie pojawiają się oficjalne SDK językowe. Ponieważ payload jest w formacie Meta, istniejący klient Cloud API działa z ich hostem. | |
| Kanały poza WhatsApp | SMS, e-mail, głos, Verify i Realtime działają pod tym samym bazowym URL i kluczem, więc drugi kanał to kolejny endpoint, a nie kolejny dostawca. | WhatsApp to cały produkt. RCS wymaga zatwierdzenia kontaktu zamiast samoobsługi, a e-mail, SMS i głos nie są dostępne. | |
| Opublikowany cennik | Stawki są publikowane z podziałem na kraje na stronie cennika WhatsApp. | Każdy plan jest publikowany jako kwota miesięczna za numer, a opłaty Meta za konwersacje są przekazywane osobno, bez narzutu. |
Ta sama wiadomość
Wysyłanie jednego szablonu WhatsApp.
Żądanie 360dialog to żądanie Meta — i o to właśnie chodzi: jeśli już wysyłasz przez Cloud API, zmienia się tylko host i nagłówek autoryzacji. W Bird wywołanie jest typowane, typ treści jest nazwą pola, a nie wartością powtarzaną obok obiektu, i obsługuje Idempotency-Key.
360dialog
const orderId = "ord_8f21";
const response = await fetch("https://waba-v2.360dialog.io/messages", {
method: "POST",
headers: {
"D360-API-KEY": process.env.D360_API_KEY!,
"Content-Type": "application/json",
},
body: JSON.stringify({
messaging_product: "whatsapp",
recipient_type: "individual",
to: "15551234567",
type: "template",
template: {
name: "order_shipped",
language: { code: "en_US" },
components: [
{ type: "body", parameters: [{ type: "text", text: orderId }] },
],
},
}),
});
const result = await response.json();
console.log(result.messages[0].id);
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);
Koszt migracji
Umiarkowany.
Wywołanie wysyłki to faktyczne przepisanie, a nie zmiana nazwy, ponieważ opuszczasz kopertę Meta. messaging_product i recipient_type znikają, typ treści przestaje być wartością powtarzaną obok obiektu i staje się samym polem, a nagłówek D360-API-KEY zamienia się w klucz bearer. W zamian wywołanie staje się typowane, a ponowienie jest bezpieczne.
Kwestia harmonogramu dotyczy Meta, a nie żadnego z dostawców. Szablony są zatwierdzane w ramach konta WhatsApp Business, do którego należą, więc zmiana dostawcy oznacza ponowne przesłanie i oczekiwanie. Bird obsługuje tworzenie, wersjonowanie per język i przesyłanie przez API oraz jako narzędzia agenta, co sprawia, że ponowne przesłanie można oskryptować zamiast wpisywać ręcznie.
Pytania, które ludzie faktycznie zadają
Czy Bird to dobra alternatywa dla 360dialog?
Oba mają serwer MCP. Jaka jest faktyczna różnica?
Które lepiej radzi sobie z brakującym uprawnieniem?
Czy coś tracę, odchodząc od formatu payload Meta?
Co dalej
Najlepiej zacząć od przewodnika wysyłki: obejmuje wywołanie wysyłki i reguły okna.