Infobip API + MCP vs YCloud

Infobip API + MCP 74

API keys with scopes, expiry dates and optional IP allowlists, plus OAuth 2.0. The hosted MCP servers accept OAuth 2.1 with discovery (30). Scopes separate reading logs from sending traffic, and splitting MCP servers by job keeps an agent to one channel. No confirmation step before sends (15 of 20). Inbound messages are untrusted text. Webhook subscriptions can carry HMAC signatures (X-Hub-Signature), Basic or OAuth credentials or mTLS so an endpoint can verify events, as the webhooks page read on 4 November for the Infobip Calls listing says, but there is no prompt-injection guidance (0 of 15). Message logs and delivery reports by API, and the Account Management MCP lists audit logs among its tools (12 of 15). security.txt, re-read on 4 November, is valid to 2030 and points to a coordinated vulnerability disclosure policy, and the security procedures page says to email Infobip to request access to its bug bounty on Bugcrowd. ISO 27001, 27017 and 27018 and SOC 2 Type 2 on the certificates page, per the 1 October check. No public advisories found (17 of 20, as the Infobip Calls listing and Perplexity's decision-model listing read a disclosure programme, a private Bugcrowd bounty and SOC 2). 30 + 15 + 0 + 12 + 17 = 74.

YCloud 31

One API key in the X-API-Key header, never in the URL, rotated by creating a new key and revoking the old one; no scopes found (20 of 30). Trial accounts send only to pre-verified numbers; no read-only key or approval step (4 of 20). Inbound WhatsApp and SMS text arrives through webhooks, with no prompt-injection guidance (0 of 15). Every response carries a request ID; no operator request log was found in the docs (5 of 15). No certification is named on the pages read, the about page shows an unlabelled ISO image, and there is no security.txt or disclosure policy (2 of 20). 20 + 4 + 0 + 5 + 2 = 31.

Infobip API + MCP 82

Closed service with clear service terms (15). Privacy notice, a data retention notice, a data transfer agreement, information security terms and a sub-processor page, per the 1 October check (25 of 30). A deprecation policy, re-read on 4 November, says deprecated endpoints keep working until a sunset date, are flagged in the OpenAPI file and in Deprecation, Sunset and Link response headers, and trigger email to active users. Infobip sets the period per endpoint with no fixed minimum, and no dated messaging notice was found in the release notes read (10 of 20, as the Infobip Calls listing). The sub-processor page says where customer data is stored and accessed, lists the EU region-locked data centre separately, and sends change alerts by email, per the 1 October check (15 of 20). 15 + 25 + 10 + 15 = 65.

YCloud 53

Closed service with terms of 3 September 2026 that don't name the contracting entity; the about page names YCloud International Pte. Ltd. The Node SDK is MIT (12 of 30). The privacy policy (3 April 2026) gives no retention periods, mentions no DPA and says the primary servers are in Singapore (8 of 30). The terms promise reasonable notice of changes only to those who subscribe to it; v1 is kept as legacy (7 of 20). No sub-processor list; the data location is named (5 of 20). 12 + 8 + 7 + 5 = 32.

Infobip API + MCP 66

The MCP servers split by channel, from 1 or 2 tools on the Message server to 27 on RCS, with SMS at 10, re-read in the repository on 4 November. API lists weren't checked for field selection (18 of 25). Message logs and delivery reports by API, filters not re-checked (15 of 20). An error code reference and a handling-errors guide that says which errors to retry (15 of 20). No idempotency key, but the handling-errors guide says a retried send may deliver twice and to look the message up in the logs or wait for a delivery report first (10 of 20, documented retry semantics without a key, as the Infobip Calls listing, scalekit-agentkit and deepl-api). The official Python client's last release was 6.0.0 in January 2026, the JavaScript SDK's in 2023, and each account has its own base URL (8 of 15). 18 + 15 + 15 + 10 + 8 = 66.

YCloud 83

List endpoints use a documented pagination guide with limits; send responses are small (18 of 25). Pagination and filters (18 of 20). Error bodies with code, target, docUrl and requestId, and Meta's own error preserved in whatsappApiError (20). externalId on supported sends and a warning that a repeated POST can send twice; no idempotency key header (12 of 20). A send needs a recipient and content; official SDKs for Node.js, Java, Go and PHP (15). 18 + 18 + 20 + 12 + 15 = 83.

Infobip API + MCP 25

No x402, MPP or L402 (0). Per-country SMS prices are public but shown as averages across networks, with per-network prices in the portal. The page's wording was re-read on 4 November, while its figures load by script and rest on the 30 September check (15 of 20). The free trial page, re-read on 4 November, gives self-signup accounts 60 days with free credits that cover about 100 messages a channel, sending only to the phone number and email address verified at sign-up. It doesn't say whether a card is needed (10 of 20). A person signs up in a browser (0). 0 + 15 + 10 + 0 = 25.

YCloud 35

No x402, MPP or L402 (0). Plan prices public, WhatsApp at Meta's rate with no markup and email at $0.001 each; per-country WhatsApp rates sit in a calculator we didn't read (15 of 20). The Free plan includes the messaging API with no card (20). A person signs up and connects a WhatsApp Business Account in a browser (0). 0 + 15 + 20 + 0 = 35.

Infobip API + MCP 72

Statuspage at status.infobip.com with components and history (20). Its history pages, re-read on 4 November, list no incident since 6 August that stopped the messaging APIs everywhere. The largest were a Global (Europe) traffic processing degradation on 15 August (03:42 to 05:52 UTC), a Global (Europe) Customer Portal and HTTP API degradation on 26 August (11:41 to 12:56 UTC), processing issues in five regions on 25 September (12:27 to 12:57 UTC, the United States not among them), SMPP down for accounts on US infrastructure from 23:02 UTC on 19 October to 00:40 on 20 October, and a US HTTP API degradation on 28 October (17:15 to 17:42 UTC). Each names one region, a group of regions, one channel or one protocol, so this run reads them as partial and minor (20), where the 1 October check read the 10 and 15 August Europe degradations as two majors (5). The 1 October third-party incident count (IsDown) is struck, a barred status mirror. The rate-limits page gives numbers for some messaging endpoints (120 requests a minute for SMS logs, 60 for Email logs and reports), says most send endpoints have none and that each endpoint's reference lists its limits, but the references render by script and weren't read (10 of 15). The rate-limits and handling-errors pages give exponential backoff with a retry cap for 429, and say a retried send may deliver twice, Infobip has no public idempotency key, and to check message logs or delivery reports before retrying (12, safe-retry guidance without a key, as the Infobip Calls listing). No SLA found (0). The SMS and WhatsApp APIs are generally available, and the Message, Provision and Observe MCP servers are early access (10). 20 + 20 + 10 + 12 + 0 + 10 = 72.

YCloud 79

Read with the hosted lines. status.ycloud.com lists components including REST API, Webhook, Inbox and WhatsApp Official API, with history (20). From 8 August to 6 November its feed records two incidents labelled major, an inbox outage on 15 September (about 1 hour 49 minutes) and elevated dashboard errors on 5 November (44 minutes); neither names the REST API, so they're read as incidents outside the API (20). Limits with numbers per endpoint, account and sender (15). 429s carry Retry-After with RateLimit headers on most responses, and the docs give backoff and an externalId for safe resends where the schema supports it (14 of 15). No SLA; the terms say availability can't be guaranteed (0). API v2 is generally available (10). 20 + 20 + 15 + 14 + 0 + 10 = 79.