Platform isolation
In Platform mode, Nervly sends through its own provider accounts. Those accounts are structured so your traffic is separated from other workspaces wherever the provider supports it — and the console names the providers where it does not.
The shared floor and per-workspace children
Every Platform-mode workspace starts on the shared floor: the deployment-wide
platform account for each provider. The floor is the default, and it is a
permanent supported steady state rather than a degraded one. A per-workspace
child account — one child per (workspace, provider) pair — is an opt-in
enhancement layered on top, requested by an operator only.
Platform mode never waits on provisioning. Floor providers are sendable
immediately, and a child that is requested or provisioning never blocks a
send: the floor keeps carrying traffic until the child is ready. A create
failure that never reached ready and holds no provider reference also stays on
the floor. Once a child is ready, that provider's traffic uses the child's own
credentials. If a child that was ever ready then becomes failed, the send
fails closed for that provider — a broken or unknown child never silently
falls back to the shared floor.
Isolation states
Nervly reports isolation honestly, per provider, as exactly one of three visually distinct states — never a single "isolated" badge:
| Badge | State | What it means |
|---|---|---|
| native child · isolated | native_child | A real child account with its own credentials, sender resources and provider-enforced separation. |
| logical namespace | logical_namespace | A provider-enforced tenant handle short of a child: own sender identity, shared account and reputation. |
| shared floor | shared_only | The shared platform credential with Nervly-side attribution only; no provider fence. |
| Provider | Isolation state |
|---|---|
| Postmark, ZeptoMail, SendGrid, Twilio, Infobip | native_child |
| Resend | logical_namespace |
| Termii, Sendchamp, Cloudflare Email, push (FCM / APNs) | shared_only |
The deferred-native providers — Sinch, Africa's Talking and Meta WhatsApp — also run on the shared floor; they are candidates for a native child once the provider's gating allows it. On the shared floor the account and its reputation are shared, and separation for those providers is Nervly-side only, which is why the console shows the badge rather than an isolation claim.
The Providers page
The console's Providers page carries the Platform surface in two sections.
Platform child accounts
One row per provider in the native-child set shows the isolation badge, the provider's channels, the provisioning state and the child credential's masked hint — never a credential value. A banner states that Platform mode never waits on provisioning.
The row state is a closed machine:
| State | Meaning |
|---|---|
requested | The intent is recorded; the provisioning sweep has not started. |
provisioning | The provider call is in flight. |
ready | The child exists and carries this provider's traffic. |
failed | A create that never reached ready and holds no provider reference stays on the shared floor and can be retried; a child that was ever ready then failed is fail-closed for that provider. |
tearing_down | The child is being parked or removed. |
torn_down | The child is gone; the workspace is back on the shared floor. |
suspended | Not a per-provider state: a workspace-wide platform-spend state, set by an explicit operator suspension or the cap being reached. Every platform send for the workspace is refused with the distinct spend-cap refusal until the operator lifts the suspension or the cap is raised. |
The only manual action is the owner/admin-only
POST /console/platform/workspaces/{id}/isolation. It records the request and
returns immediately — the provider call happens asynchronously — and a repeat
request for the same provider is idempotent. There is no self-serve teardown.
The matching read is GET /console/platform/workspaces/{id}/isolation, which
returns one row per provider.
Platform path
The Platform path section is the price composer described in Quotas and billing: it reads the configured provider contributions and submits your selection with the subscription.
Next
- Provider credentials — BYO, Both and Platform
- Quotas and billing — the Platform path price
- Channels & providers — which provider backs each channel