Providers

A provider is the backend that actually delivers a message. You connect one or more per channel in the dashboard under Settings, Providers. Credentials are encrypted the moment you save them, and plaintext never leaves the POST body. For how MessagePipe chooses among several providers, see Providers.

Catalog

WhatsApp, Telegram, and Signal are delivered over the chat channel (Channels).

Credential notes

• SendGrid: a SendGrid API key with Mail Send permission.
• Mailgun: your Mailgun private API key plus the verified sending domain.
• Amazon SES: an IAM access key pair with SES send permission and the SES region (for example us-east-1).
• SMTP: any SMTP server. Host, port, and login credentials.
• Resend: an API key. A key limited to sending access is enough.
• Postmark: the Server API token of the server you send from. Set the optional message_stream in the provider settings to use a stream other than the default transactional one.
• MailerSend: an API token with email access. Custom headers need a MailerSend Professional plan or above; on a lower plan sends that carry custom headers are refused.
• ZeptoMail: the Send Mail token for a Mail Agent and its bounce address. region selects the data centre (us, eu, in, au, jp, ca, sa, cn; default us) and must match where the Mail Agent was created.
• Mailtrap: an API token. stream picks transactional (default), bulk, or sandbox; sandbox needs the numeric inbox_id.
• Elastic Email: an API key with send access. The optional channel_name and pool_name settings route through a named channel or IP pool. For delivery events, add a webhook under Settings > Notifications (a PRO-plan feature) with Sign requests on, then save the whsec_… secret it shows once as webhook_secret.
• Bird email (SparkPost): a SparkPost API key. Use region: eu for EU accounts. This is registered as the sparkpost provider type.
• Twilio: account SID, auth token, and the from_number you send from.
• Termii: a Termii API key and an approved alphanumeric sender_id. Termii gives each account its own base URL (shown on the dashboard); set it as base_url (for example https://api.ng.termii.com) if yours is not the default https://v3.api.termii.com. It must be an https termii.com host. Choose the route under Sending on the provider page: use dnd for OTP and other transactional traffic (the default, generic, is promotional and skips numbers on Do Not Disturb), or whatsapp. For delivery events, paste your Termii secret key as webhook_secret; requests are verified through the X-Termii-Signature header (HMAC-SHA512 of the body). A request without the header is checked against the shared-secret headers instead, for webhooks relayed through a proxy of your own; set the provider config require_signature to "true" to refuse any request that is not signed.
• Infobip: your Infobip API key and the account base_url (for example https://xxxxx.api.infobip.com).
• Amazon SNS: an IAM access key pair with SNS publish permission and the region.
• Telnyx: an API v2 key and a from_number (or a messaging profile).
• Bandwidth: your account id, the messaging application id, a from_number, and OAuth client credentials (client_id, client_secret). Legacy username/password login still works until Bandwidth retires it on 2 December 2026.
• Plivo: the Auth ID and Auth Token, plus a sender_id (number or approved sender).
• Sinch: the SMS service plan id and its API token. region is one of us, eu, au, br, ca. This uses Sinch's SMS REST API, not the Conversation API.
• Vonage: the API key and secret, and a sender_id. This uses the Messages API with key and secret auth; application JWT auth is not supported.
• Bird SMS: a Bird workspace access key (bk_…) and the channel sender_id. EU workspaces are detected from the key or region: eu. This is Bird's current API, which replaces the old MessageBird one.
• MessagePipe managed email (messagepipe_email): no credentials. Sends through MessagePipe's own Amazon SES account and is billed from the managed email credit bucket (email_managed), not the BYOK email bucket. See Managed email.
• MessagePipe (managed): no credentials. Sends through MessagePipe's own provider account, so you can send SMS without any provider setup of your own.
• FCM: the Firebase project_id and an access_token for the FCM v1 API.
• APNs: token-based auth, the Apple team_id, the key key_id, the .p8 private_key, and your app bundle_id.
• OneSignal: your OneSignal app_id and a REST API key.
• WhatsApp: the Meta phone_number_id and a WhatsApp Business access_token.
• WhatsApp via Twilio: Twilio account SID, auth token, and your WhatsApp-enabled from_number.
• Telegram: a bot token from BotFather.
• Signal: the registered phone_number and the api_endpoint of your signal-cli REST API instance.

Termii sender IDs and batching

Termii only sends from sender IDs it has approved. The provider page lists the IDs registered on your Termii account with their status, and Request a sender ID files a new one (3 to 11 letters and digits, your company name, and a sample message). Termii reviews it by hand, so it stays pending until approved. The same is available as GET and POST /providers/{id}/sender-ids.

By default every message is its own request to Termii, and its delivery report is matched to it exactly. Send mode on the provider page can instead be set to batch, which sends up to 100 recipients of the same message in one call to Termii's bulk endpoint. Batching:

• applies to the Generic and DND routes only, and only to messages with the same text and sender that are in flight at the same moment;
• needs the dispatcher to run sends together: set DISPATCH_BATCH_SIZE (above 1) on the send-dispatch-worker. Without it, batch behaves like the default;
• holds a message for up to DISPATCH_BATCH_WINDOW_MS (250 by default) so others can join it, so a lone message is a little slower;
• stores each message under Termii's batch message_id joined with the recipient (<message_id>:<number>) and matches a delivery report to it by its receiver. Termii documents one message_id per bulk call, not how its delivery reports name a batched message, so check that reports arrive for a few batched test messages before relying on it. A bulk call that Termii refuses fails over message by message, as an unbatched send does.

Test an SMS provider

To prove an SMS provider works end to end, open it under Settings > Providers, enter your phone number in international format (for example +2348012345678) and choose Send test SMS. It sends a short fixed message through that provider, bypassing credits and routing. Each provider accepts one test every 30 seconds and a workspace 25 a day, each test is recorded in the audit log (with the number masked), and the MessagePipe managed provider can't be tested this way.

Managed email

Managed email sends through MessagePipe's own Amazon SES account instead of your keys. A workspace can have several SES tenants: one per project and sender domain. A send goes out only when its from domain has an active tenant with a verified identity in that project. Otherwise the provider is skipped as tenant_not_ready and the send fails over to the next provider. Likewise, a paused or suspended SES sender (sending_paused) is skipped at once and never retried in place. Only real credential errors (auth_failed) fail a send outright. BYOK providers, including your own Amazon SES keys, are unaffected by the managed layer.

Publishing the DNS records automatically

A new sender domain comes with a handful of DNS records (three DKIM CNAMEs, the MAIL FROM MX and SPF records, and DMARC). You can add them by hand, or connect Cloudflare on the Managed email screen and let MessagePipe publish them.

Create a Cloudflare API token with Zone → Zone → Read and Zone → DNS → Edit, limited to the zone your sender domain is in, and paste it into Connect Cloudflare. MessagePipe stores it encrypted and never shows it again. A connection is either the workspace default or limited to one project (the project's own connection is tried first).

Set up DNS automatically reads your DNS first and shows what it would do for each record. Nothing is written until you press the button.

• A record that is missing is added.
• A record that is already right is left alone.
• A record that differs is a conflict, and you choose for each one: keep what I have (the default), merge (add MessagePipe to your existing SPF record, or add its MX alongside yours), or replace. Existing records are never changed without that choice.
• Where changing one record cannot be done safely (for example a CNAME that cannot share a name with other records, or two SPF records), the row is marked do this by hand and nothing is touched.

MessagePipe keeps a list of what it published. When you delete the domain you can have it take those records back: it deletes only records it created and that still have the content it gave them, and puts back any record it merged into. A record you have edited since is left alone. If another project in the workspace still uses the domain, the records stay. If you remove the connection first, MessagePipe can no longer take its records back and you remove them by hand.

Operators configure the managed account on the services that send and receive its events:

Delivery events by provider

Terminal statuses (delivered, bounced, failed) arrive through provider delivery webhooks, so coverage depends on the provider:

• Report delivery events: SendGrid, Mailgun, Amazon SES, MessagePipe managed email, Resend, Postmark, MailerSend, Bird email (SparkPost), Elastic Email, Twilio, Termii, Infobip, Telnyx, Plivo, Bandwidth, Sinch, Vonage, Bird SMS, WhatsApp (Cloud API), WhatsApp via Twilio.
• Send only, no events yet: ZeptoMail and Mailtrap send normally, but MessagePipe does not ingest their webhooks, so sends settle at sent.
• No HTTP delivery webhook: SMTP, Amazon SNS, MessagePipe managed, Telegram, Signal, and the push providers (FCM, APNs, OneSignal). Sends through these settle at sent; there is no downstream delivery callback.

Webhook verification

Each provider signs (or does not sign) its webhooks differently, so the verification secret you save differs:

Unverified webhooks are dropped. Webhook timestamps are checked within five minutes for the providers that sign one.

Failover note

auth_failed and payload_too_large are terminal errors, so a bad API key or an oversized message does not fail over to your next provider. Only rate limits, 5xx responses, timeouts, and connection failures do.

Pointing each live provider's dashboard webhook at the ingress and verifying it is part of going to production. Until then, downstream metrics stay empty even though sends flow. See Webhooks and Delivery logs.