Quick answer: The fraud conversation in communications APIs has moved past SMS pumping. The active 2026 discussion runs one layer deeper — at the provider's API surface itself: stolen API keys resold through CAPTCHA-solving farms, forged webhook payloads that inject fake delivery or billing events into your systems, and account takeover at the provider console that mints credentials under your name. None of these require a carrier compromise; all three abuse the contract between your organization and the platform. Devotel Orbit's answer to each is a shipped, tenant-owned control: scoped and IP-bound API keys, SAML single sign-on scoped to your organization, and a receiver-side rule that a webhook delivery counts only after your own verification passes. This post walks the three threat shapes, maps each to the control that answers it, and ends with the buyer's checklist for arguing security in a CPaaS deal.
The prior post in this lane, the enterprise CPaaS due-diligence checklist, covers identity lifecycle — SCIM provisioning, audit evidence, tenant isolation. This one covers the abuse cases: what happens when the credential, the event stream, or the dashboard session is the attacker's entry point.
API-layer threats vs. dashboard-layer threats
CPaaS accounts are attacked through two doors, and the doors get different defenses. Keep them separate when you evaluate a provider, because a vendor that answers one well and the other vaguely has told you where their security program ends.
The API door: keys as inventory. A leaked secret key (dv_live_sk_...-class material at any provider) is a transferable asset. The 2026 version of this trade is industrialized: CAPTCHA-solving farms and credential shops buy leaked API keys extracted from frontend bundles, CI logs, and pasted support tickets, then resell them downstream to senders who want traffic that bills to someone else. The buyer of the key does not need to touch your dashboard — the API is the whole attack. What contains this shape is not key rotation discipline alone; it is what the key is structurally allowed to do. A read-only public key embedded in a browser bundle is publishable by design and useless to a reseller. A secret key pinned to an IP allowlist fails authentication from the reseller's infrastructure. A key with a hard usage envelope caps the damage even in the worst case. Each of these is a shipped Orbit control, detailed in the next section.
The event-stream door: forged webhooks. Outbound webhooks invert the trust direction of the API. You authenticate to the provider on API calls; on webhooks, the provider calls you — and anyone on the internet can POST to your receiver URL. A forged message.delivered or call.completed payload is not a nuisance; it is a fraud-injection primitive. Fake delivery confirmations poison your analytics and your customer-facing status pages. A forged billing or low-balance event can trigger whatever automated response a tenant wired to it. Teams that treat receiver URLs as secret learn otherwise when the URL leaks through a frontend error handler or a log line. The only durable answer is verification at the receiver — and the honest version of that answer is owned by the tenant, not claimed by the platform. Section three covers it.
The dashboard door: account takeover at the provider layer. The highest-impact attack on a CPaaS tenant does not touch the API at all. A phished or session-hijacked dashboard owner resets credentials, mints a fresh secret key, registers a webhook endpoint under attacker control, and exfiltrates through a channel that looks, to the provider, like the customer's own configuration. Platform-side MFA reduces the odds of the initial compromise; it does not change the blast radius once a session is live, and it does nothing for the organizational question — who in your company is allowed to hold that power. That question is answered by identity plumbing on the tenant side: org-scoped SAML single sign-on that routes dashboard sign-in through your own IdP, and SCIM deprovisioning that revokes access and active sessions when someone leaves. An IdP-enforced conditional-access policy travels with the dashboard session; a per-vendor MFA checkbox does not.
Shipped controls: scoped keys and org-scoped identity
Every control in this section is tenant-owned: an owner in your organization turns it on, configures it, and can turn it off. None of them is a platform mandate, and an organization that never touches these settings keeps working.
Key scopes, with public keys restricted to read-only by construction. Orbit's API key model separates server-side secret keys from browser-embeddable public keys, and the restriction is enforced at creation, not by convention. A public key (dv_live_pk_ / dv_test_pk_) is limited to read-only scopes; request a write or administrative scope — messages:write, contacts:write, admin, the * wildcard, or the sensitive account reads billing:read / settings:read — and the create call is rejected with a 422. The mechanics, including the Authorization: Bearer fallback for environments that block custom headers, are in the authentication reference. The consequence for the leaked-key trade above: the key you ship in a browser or mobile bundle, the one most exposed by construction, is the one a credential shop cannot turn into billable traffic.
Administrative scopes are restricted, not blanket. Secret keys carry the scopes you grant and nothing implicit; the administrative scope exists as a distinct grant rather than an ambient property of being a secret key. The practical posture is one key per integration, scoped to that integration's actual verbs, so a leaked support-automation key cannot send traffic and a leaked messaging key cannot read billing. Combine with rotation — a scheduled rotation is a two-minute change, so an unscheduled one is not an incident.
The containment layer for the worst case. Two per-key limits bound the damage when a key leaks anyway: a hard usage envelope (usage limits) that stops the draw at a configured ceiling, and operator-set monthly budgets (budget alerts) that flag the key at warning and exceeded bands in the dashboard. A key being exercised by a reseller surfaces as a badge, not a line item on the invoice. And at the network layer, a per-key IP allowlist — up to 50 IPs or CIDR ranges per key — rejects off-network requests with a 401 before authentication completes, which converts a leaked key from a transferable asset into a non-transferable one.
Org-scoped SAML isolates identity. SAML single sign-on in Orbit is per organization: each organization gets its own metadata, login, callback, and logout endpoints keyed by its organization slug, configured under Settings → Single sign-on and exercised with a built-in test connection before it is enabled. Sign-in routes through your IdP, so your conditional-access policies, your device posture checks, and your MFA requirements apply — and a phished vendor-side password stops being the entry point. SCIM completes the shape on the lifecycle side: unassigning a user in the IdP revokes their Orbit access and every active session on the next sync, which is what "account takeover defense" actually means in practice — the session does not outlive the directory assignment. Both are documented end to end in the authentication reference.
Webhook forgery and the receiving-side control
This section is deliberately precise about who verifies what, because "the platform secures your webhooks" is the most abused sentence in CPaaS security marketing.
Orbit signs outbound webhook deliveries with an HMAC signature carried on the request, and the delivery pipeline is honest about what that does and does not mean. The signature is material for your receiver to check; verification happens at your endpoint, in code you own. Orbit does not run your receiver — it cannot reject a forged payload on your behalf, and any provider that phrases this as platform-side protection is claiming something no provider ships. The tenant-owned rule to write down and enforce is simple: a delivery never counts until verification passes. A failed signature check drops the event before your handler runs, and spoofed payloads never enter your dedup set. The verification contract and the failure shapes are documented in troubleshooting signature failures, and the fan-out model that dedupes on the envelope id is in webhook delivery semantics.
The forgery discussion matters precisely because the receiving-side control is where it is answered. If your receiver verifies signatures, a forged payload is a dropped request. If your receiver accepts unverified payloads, a forged delivery confirmation flows straight into whatever consumes it — and this failure is silent, because the forgery looks identical to a legitimate delivery until someone audits the status page against the provider's records. One practical reading of the verification rule, applied to the events taxonomy: treat every event class that can alter money, message state, or customer-visible status as verify-before-consume, not merely verify-when-convenient.
Kin to forgery is endpoint enumeration: an attacker who registers a webhook endpoint on your account receives your event stream, and an attacker probing your receiver URL learns what your verify-before-consume discipline is worth. The dashboard-side defense above (org-scoped SAML plus the audit log, which records endpoint registration with actor, timestamp, and source IP) answers the first; the receiving-side rule answers the second.
Arguing security in a CPaaS deal: the buyer checklist
Security posture wins deals at short-list time, and the questions below are the ones a buying committee can run against any candidate — Orbit included. Ask for the documentation, not the marketing answer, on each.
- Is there a browser-embeddable key class, and is its read-only restriction enforced at creation? A public key that can hold write scopes is a leaked-key asset waiting for a buyer. Enforced restriction beats policy.
- Can administrative scope be withheld per key? One key per integration, scoped to that integration's verbs. Ambient administrative access on every secret key multiplies the blast radius of any single leak.
- Can usage be bounded per credential, with a warning before the ceiling? Hard envelopes plus budget alerts turn a leaked key into a bounded incident instead of an invoice surprise.
- Can a key be pinned to network sources? IP allowlisting at the key layer makes leaked credentials non-transferable — the single strongest answer to the credential-resale trade.
- Does dashboard identity route through our IdP, org-scoped? SAML per organization, not a shared vendor SSO page, so your conditional-access policies apply. Bonus point when SCIM revocation kills sessions, not just seats.
- Who verifies webhook signatures — and whose docs say so? The credible answer names the tenant-owned verification rule and documents the exact contract. The non-credible answer claims the platform does it for you.
- Does the audit trail catch endpoint registration and key creation? Event-stream hijack and rogue-key minting both leave an audit row if the ledger is truly append-only — actor, action, timestamp, source IP, exportable to your SIEM.
A vendor that answers all seven with shipped documentation survives the questionnaire stage; one that answers with roadmap language self-selects out.
Frequently asked questions
Is public-key restriction a marketing claim or an enforced rule?
Enforced. A public-key create call that includes a write or administrative scope is rejected with a 422 naming the offending scope — the authentication reference shows the exact rejection response. Read-only is the only shape a public key can hold.
If webhook verification is tenant-owned, what does Orbit actually do?
Orbit signs each outbound delivery and documents the verification contract, the rotation behavior, and the failure shapes. Your receiver checks the signature on every request and drops failures before the handler runs. That split — platform signs, tenant verifies — is the honest model; treat "platform-verified webhooks" claims from any provider as a flag, not a feature.
Does SAML SSO also govern API keys?
No. SSO controls how people sign in to the dashboard; API keys remain the server-to-server mechanism, and SCIM governs which users exist. The three are independent per-organization settings, which is the model enterprise IdPs expect — the authentication reference keeps them in separate sections for exactly this reason.
What is the smallest posture that materially raises the cost of attack?
Three moves, all tenant-owned: a scoped public key for anything client-side, an IP allowlist on each server-side secret key, and SAML SSO routed through your IdP. The first limits what a leaked client key can do, the second makes a leaked server key non-transferable, and the third moves dashboard compromise behind your own conditional-access policy.