Carrier connections

A carrier connection holds the credentials Helium MVNE uses to talk to a carrier on your operator's behalf. Each connection is environment-scoped and per-connection resolved at every call — Helium MVNE never uses Application-config or shared secrets for carrier auth.

Carrier connections are managed from the operator dashboard, not from the API. Operator API keys cannot read, rotate, or delete carrier credentials — a compromised integration key must not yield the ability to redirect carrier traffic.

T-Mobile in v1

v1 supports T-Mobile TAAP. A live T-Mobile connection needs:

• client_id / client_secret (issued by T-Mobile)
• POP-token private key (RSA, per-connection)
• Allowed source-IP range (enforced on inbound webhooks)

Sandbox environments use the Simulated adapter — no credentials required. The Simulated adapter honors the full T-Mobile API contract plus state-machine triggers (see Testing in sandbox).

Creating a connection (live)

From the dashboard: Settings → Carrier connections → Add connection, select tmobile, paste your client_id + client_secret, upload the POP private key, and save. On save, Helium MVNE runs a verify step against the carrier and reports any credential issues up front. A failed verify does not persist the connection.

Sandbox workspaces come with a simulated carrier connection pre-provisioned — nothing to create, it just works.

Verify / rotate

Both are dashboard actions on the carrier-connection detail page:

• Verify — round-trip a no-op call against the carrier; updates status + last_verified_at.
• Rotate key — upload a new POP private key; Helium MVNE swaps it atomically, with a short cache window to drain in-flight calls.

Credential material is encrypted at rest and never returned in API responses or in the dashboard after creation.