Subaccounts API

For platforms reselling Orbit to their own customers — agencies, MSPs, vertical SaaS. A parent org creates and operates subaccount orgs, each with its own API keys, isolated data, optional custom branding and domain, and per-subaccount pricing. Base path: /api/v1/subaccounts Authentication: Parent-org session JWT or API key with admin role. Response envelope: Every endpoint on this page returns {"data": ..., "meta": {...}}. meta carries request_id (the server’s unique reference for the call — pass it to support when reporting a problem) and timestamp. List endpoints add pagination fields under meta: cursor (opaque next page), has_more, and on counts total.

Using the SDKs

import { Orbit } from "@devotel-orbit/node";

const orbit = new Orbit({ apiKey: process.env.ORBIT_API_KEY! });

const res = await orbit.subaccounts.list();

Python (same call via the SDK’s escape hatch):

from orbit_sdk import OrbitClient

client = OrbitClient.from_env()  # reads ORBIT_API_KEY

res = client.request("GET", "/subaccounts")

The Python SDK is core-scope — it wraps the 8 core resources (messaging, voice, contacts, campaigns, verify, numbers) and reaches everything else through the generic client.request() escape hatch above. See the Python SDK. Returns the typed ApiResponse envelope. See the SDK index at SDK quickstart.

Lifecycle

Method	Path	Purpose
`POST`	`/api/v1/subaccounts/`	Create a subaccount
`POST`	`/api/v1/subaccounts/provision`	Create a fully-configured subaccount — org, plan, pricing, branding & funding — in one call
`GET`	`/api/v1/subaccounts/`	List subaccounts
`GET`	`/api/v1/subaccounts/{id}`	Get a subaccount
`PUT`	`/api/v1/subaccounts/{id}`	Update name / contact / metadata
`DELETE`	`/api/v1/subaccounts/{id}`	Delete a subaccount — releases its phone numbers and removes its data; the account stays listed under your deleted subaccounts
`POST`	`/api/v1/subaccounts/{id}/finalize`	Activate a pending (wizard-created) subaccount
`POST`	`/api/v1/subaccounts/{id}/suspend`	Suspend (blocks API + UI access)
`POST`	`/api/v1/subaccounts/{id}/reactivate`	Lift a suspension

A subaccount created through the multi-step wizard starts as pending so an aborted setup never leaves a billing-active tenant behind. POST /api/v1/subaccounts/{id}/finalize promotes it to active on the final Launch step. It is idempotent — calling it on an already-active subaccount returns 200 and changes nothing. POST /api/v1/subaccounts/provision finalizes for you as its last step.

Single-call provisioning

POST /api/v1/subaccounts/provision stands up a complete, branded, funded subaccount in a single request — the API equivalent of the five-step new-subaccount wizard (organization → plan & limits → reseller pricing → funding → branding). Reach for it when you provision tenants from your own portal or back-office automation and don’t want to orchestrate the separate create → pricing → branding → transfer-credits → finalize calls yourself.

Wizard vs single call

	Single call (`POST /provision`)	Dashboard wizard steps
Calls	One atomic request	`POST /` → `PUT /{id}/pricing` → `PUT /{id}/branding` → `POST /{id}/transfer-credits` → `POST /{id}/finalize`
Isolation	All-or-nothing: any failed step rolls the child org back, so no half-provisioned subaccount survives	An aborted wizard leaves a pending subaccount until `finalize` completes it
Governance	Pass the same plan, rate-limit, margin, spend-cap, branding, and initial-credits inputs as flattened body fields	The wizard takes these inputs step by step, so a human operator can pause and review
Pick it when	You provision tenants from a portal, form, or back-office automation	An operator onboards a single end-customer interactively

Pick the single call when anything programmatic triggers onboarding; pick the wizard when a person drives it. Both paths land on the same role gate — owner or admin on the parent org. The body flattens every wizard step. Only name is required; everything else is optional:

Field	Type	Notes
`name`	string	Display name for the subaccount. Required.
`slug`	string	Vanity slug; auto-derived from `name` when omitted.
`plan`	enum	`starter`, `growth`, `business`, or `enterprise`.
`max_team_members`	integer	Seat cap for the subaccount.
`rate_limit_per_second`	integer	Per-second API rate limit.
`reseller_margin_pct`	number	Markup applied over Orbit wholesale, `0`–`100`.
`monthly_spend_cap_cents`	integer	Hard monthly spend ceiling, in minor units (cents).
`initial_credits_cents`	integer	Optional credit seed transferred from the parent wallet.
`branding`	object	White-label overrides: `primary_color`, `accent_color`, `dashboard_name`, `support_email`.
`inherit_branding_from_parent`	boolean	Inherit the parent’s branding instead of setting your own.

The call is atomic: if any step fails after the org is created, the half-provisioned subaccount is rolled back so the slug stays free to retry. On success (201) the response carries the new subaccount plus its applied pricing, the branding_applied fields, the initial_credits transfer, and any non-blocking warnings — for example, a reseller margin below the recommended floor.

curl -X POST "https://api.orbit.devotel.io/api/v1/subaccounts/provision" \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Rahal Industries",
    "slug": "rahal-industries",
    "plan": "growth",
    "max_team_members": 5,
    "rate_limit_per_second": 20,
    "reseller_margin_pct": 25,
    "monthly_spend_cap_cents": 5000000,
    "initial_credits_cents": 1000000,
    "branding": {
      "primary_color": "#0EA5E9",
      "accent_color": "#F59E0B",
      "dashboard_name": "Rahal Hub",
      "support_email": "help@rahal.example"
    }
  }'

{
  "data": {
    "id": "org_sub_rahal_00x9",
    "name": "Rahal Industries",
    "slug": "rahal-industries",
    "plan": "growth",
    "subscription_status": "active",
    "pricing": {
      "reseller_margin_pct": 25,
      "monthly_spend_cap_cents": 5000000
    },
    "branding_applied": ["primary_color", "accent_color", "dashboard_name", "support_email"],
    "inherit_branding_from_parent": false,
    "initial_credits": { "transferred_cents": 1000000 },
    "warnings": []
  },
  "meta": {
    "request_id": "req_provision_001",
    "timestamp": "2026-08-25T10:00:00Z"
  }
}

To create a bare subaccount without the flattened wizard body, use the plain create path:

curl -X POST "https://api.orbit.devotel.io/api/v1/subaccounts/" \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Rahal Industries" }'

{
  "data": {
    "id": "org_sub_rahal_00x9",
    "name": "Rahal Industries",
    "slug": "rahal-industries",
    "plan": "starter",
    "subscription_status": "pending",
    "api_key": "dv_live_sk_9PmzRu2KqLsXfY7wBcNaV4tE",
    "created_at": "2026-08-25T10:00:00Z"
  },
  "meta": {
    "request_id": "req_create_001",
    "timestamp": "2026-08-25T10:00:00Z"
  }
}

The api_key in the response is the subaccount’s default key — shown once in plaintext; store it before you discard the response. subscription_status starts as pending here; POST /api/v1/subaccounts/{id}/finalize (owner or admin) flips it to active — POST /provision finalizes for you.

List subaccounts

Page through the subaccount tree with ?limit= (max 200) and ?cursor=:

curl "https://api.orbit.devotel.io/api/v1/subaccounts?limit=50" \
  -H "X-API-Key: $ORBIT_API_KEY"

{
  "data": [
    {
      "id": "org_sub_rahal_00x9",
      "name": "Rahal Industries",
      "slug": "rahal-industries",
      "plan": "growth",
      "subscription_status": "active",
      "createdAt": "2026-08-25T10:00:00Z"
    }
  ],
  "meta": {
    "request_id": "req_list_001",
    "timestamp": "2026-08-25T10:01:00Z",
    "cursor": "eyJjcmVhdGVkQXQiOiIyMDI2LTA4LTI1VDEwOjAwOjAwWiIsImlkIjoi...",
    "has_more": false
  }
}

meta.cursor is the opaque continuation token for the next page; has_more: false means the tree ends here. A fresh ?cursor=<value> call returns the next batch.

Get a single subaccount

curl "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9" \
  -H "X-API-Key: $ORBIT_API_KEY"

{
  "data": {
    "id": "org_sub_rahal_00x9",
    "name": "Rahal Industries",
    "slug": "rahal-industries",
    "plan": "growth",
    "subscription_status": "active",
    "parent": {
      "name": "Your Parent Org",
      "organizationId": "org_parent_9f2e",
      "tenantId": "tenant_parent_9f2e",
      "relationship": "reseller"
    },
    "createdAt": "2026-08-25T10:00:00Z"
  },
  "meta": {
    "request_id": "req_get_001",
    "timestamp": "2026-08-25T10:01:05Z"
  }
}

The parent block carries the current tenant hierarchy so the detail view can link back to the parent without a second call.

Update a subaccount

PATCH-style read-modify writes name, plan, seat limit, rate limit, and settings:

curl -X PUT "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9" \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Rahal Industries Co.", "plan": "growth" }'

{
  "data": {
    "id": "org_sub_rahal_00x9",
    "name": "Rahal Industries Co.",
    "slug": "rahal-industries",
    "plan": "growth",
    "subscription_status": "active"
  },
  "meta": {
    "request_id": "req_update_001",
    "timestamp": "2026-08-25T10:02:00Z"
  }
}

Lifecycle transitions

Suspend stops all send activity while the parent keeps billing ownership — reactivate flips it back. These are owner-only (owner on the parent org, per the router’s guard hierarchy); create/finalize/read paths accept owner or admin:

curl -X POST "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9/suspend" \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" -d '{}'

{
  "data": { "id": "org_sub_rahal_00x9", "status": "suspended" },
  "meta": { "request_id": "req_sus_001", "timestamp": "2026-08-25T11:00:00Z" }
}

POST /{id}/reactivate returns the same shape with "active". POST /{id}/finalize (owner or admin) returns { "id", "subscription_status": "active" } and is idempotent — a rerun on an already-active subaccount is a 200 no-op. DELETE /{id} is a soft delete — it releases phone numbers, marks the row deleted, and (on success) returns 204 No Content with no body.

Usage & credits

Method	Path	Purpose
`GET`	`/api/v1/subaccounts/{id}/usage`	Usage & cost for a single subaccount
`GET`	`/api/v1/subaccounts/{id}/usage/statement`	Billing-grade reseller statement for a period — per day × meter, with your reseller markup and margin earned (JSON)
`GET`	`/api/v1/subaccounts/{id}/usage/export.csv`	The same statement as a downloadable CSV to invoice your end-customer
`GET`	`/api/v1/subaccounts/usage-rollup`	Consolidated usage & cost across every subaccount for a period
`GET`	`/api/v1/subaccounts/usage-rollup/export.csv`	The consolidated rollup as a downloadable CSV
`POST`	`/api/v1/subaccounts/{id}/transfer-credits`	Move credits from parent to subaccount

GET /api/v1/subaccounts/usage-rollup?period=YYYY-MM returns one consolidated report across your whole subaccount tree for a billing period: grand totals plus a per-subaccount breakdown that reconciles line-for-line with each subaccount’s own usage. Omit period to default to the current UTC month.

Get usage

Read lifetime counters — credits used, message counts, calls made — without paging:

curl "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9/usage" \
  -H "X-API-Key: $ORBIT_API_KEY"

{
  "data": {
    "subaccount_id": "org_sub_rahal_00x9",
    "credits_used": 118492,
    "messages_sent": 1214,
    "messages_received": 97,
    "calls_made": 36,
    "api_calls": 8120,
    "current_plan": "growth",
    "rate_limit_per_second": 20,
    "data_retention_days": 365
  },
  "meta": {
    "request_id": "req_usage_001",
    "timestamp": "2026-08-25T10:03:00Z"
  }
}

Transfer credits

Transfer credits into a subaccount from the parent wallet; pass client_reference_id for safe retries on network failure:

curl -X POST "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9/transfer-credits" \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "amount_cents": 500000, "note": "Top-up for September", "client_reference_id": "po-1042" }'

{
  "data": {
    "transferred": true,
    "amount_cents": 500000,
    "parent_balance_cents": 191500,
    "child_balance_cents": 506200
  },
  "meta": {
    "request_id": "req_transfer_001",
    "timestamp": "2026-08-25T10:01:30Z"
  }
}

The response returns the balance deltas — the parent’s debited balance and the child’s credited balance after the transfer — so your portal can render the top-up ledger without a second call. Retrying with the same client_reference_id returns the original result instead of double-charging. Read a subaccount’s billing-grade statement — a line per day × channel/meter carrying quantity, wholesale cost, marked-up price under the subaccount’s reseller margin, and the margin earned:

curl "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9/usage/statement?period=2026-08" \
  -H "X-API-Key: $ORBIT_API_KEY"

{
  "data": {
    "period": "2026-08",
    "rows": [
      {
        "date": "2026-08-24",
        "channel": "sms",
        "quantity": 1214,
        "baseCost": 971,
        "billedPrice": 1295,
        "marginEarned": 324
      }
    ],
    "totals": {
      "quantity": 1214,
      "baseCost": 971,
      "billedPrice": 1295,
      "marginEarned": 324
    }
  },
  "meta": {
    "request_id": "req_statement_001",
    "timestamp": "2026-08-25T10:01:00Z"
  }
}

GET /api/v1/subaccounts/{id}/usage/statement?period=YYYY-MM returns the reseller statement for one subaccount: a line per day × channel/meter carrying quantity, base (wholesale) cost, the marked-up price under that subaccount’s reseller margin, and the margin you earned, plus a totals footer. GET /api/v1/subaccounts/{id}/usage/export.csv streams the identical figures as a CSV attachment so you can invoice your end-customer or hand it to an auditor. Both default to the current UTC month when period is omitted; a malformed period returns 422 VALIDATION_ERROR.

API keys

Method	Path	Purpose
`GET`	`/api/v1/subaccounts/{id}/api-keys`	List the subaccount’s API keys
`POST`	`/api/v1/subaccounts/{id}/api-keys`	Issue a new key for the subaccount

Issue a key for a subaccount from the parent — the response carries the plaintext key exactly once:

curl -X POST "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9/api-keys" \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Rahal storefront",
    "type": "secret",
    "scopes": ["messages:write", "contacts:read"]
  }'

{
  "data": {
    "id": "apikey_2Vwpld",
    "key": "dv_live_sk_9PmzRu2KqLsXfY7wBcNaV4tE",
    "keyPrefix": "dv_live_sk_",
    "lastFourChars": "V4tE",
    "name": "Rahal storefront",
    "type": "secret",
    "mode": "live"
  },
  "meta": {
    "request_id": "req_subkey_001",
    "timestamp": "2026-08-25T10:02:00Z"
  }
}

Own-org key management (rotate with a grace period, revoke) lives on the Organization API; scopes are validated against the same closed catalog there.

List a subaccount’s API keys

The parent can enumerate every key the subaccount has issued — secrets are masked and a total line tells you how many exist across pages:

curl "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9/api-keys?limit=25" \
  -H "X-API-Key: $ORBIT_API_KEY"

{
  "data": [
    {
      "id": "apikey_2Vwpld",
      "name": "Rahal storefront",
      "keyPrefix": "dv_live_sk_",
      "lastFourChars": "V4tE",
      "type": "secret",
      "active": true,
      "scopes": ["messages:write", "contacts:read"],
      "lastUsedAt": "2026-08-25T10:02:00Z",
      "createdAt": "2026-08-24T09:00:00Z"
    }
  ],
  "meta": {
    "request_id": "req_listkeys_001",
    "timestamp": "2026-08-25T10:04:00Z",
    "cursor": null,
    "has_more": false,
    "total": 1
  }
}

To rotate or revoke a subaccount’s key, use the subaccount’s own bearer (or a parent’s role-equivalent) against the Organization API keys endpoints — the same revoke path applies to any key of that org.

Branding & custom domains

Method	Path	Purpose
`GET`	`/api/v1/subaccounts/{id}/branding`	Get effective branding
`PUT`	`/api/v1/subaccounts/{id}/branding`	Override logo / colors / brand name
`POST`	`/api/v1/subaccounts/{id}/domains`	Add a custom domain (CNAME-verified)
`GET`	`/api/v1/subaccounts/{id}/domains`	List domains
`DELETE`	`/api/v1/subaccounts/{id}/domains/{domainId}`	Remove a domain
`POST`	`/api/v1/subaccounts/{id}/domains/{domainId}/verify`	Trigger DNS re-verification

Update branding

Every branding field is optional in the patch; explicit null clears a field:

curl -X PUT "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9/branding" \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "primary_color": "#0EA5E9",
    "accent_color": "#F59E0B",
    "dashboard_name": "Rahal Hub",
    "support_email": "help@rahal.example",
    "logo_url": "https://rahal.example/assets/logo.png"
  }'

{
  "data": {
    "primary_color": "#0EA5E9",
    "accent_color": "#F59E0B",
    "dashboard_name": "Rahal Hub",
    "support_email": "help@rahal.example",
    "logo_url": "https://rahal.example/assets/logo.png",
    "inherit_from_parent": false
  },
  "meta": {
    "request_id": "req_brand_001",
    "timestamp": "2026-08-25T10:05:00Z"
  }
}

GET /api/v1/subaccounts/{id}/branding returns the same merged shape — the effective branding after parent/child inheritance.

Custom domains & DNS verification

Claim a custom domain; the response carries the cname_target to place in DNS:

curl -X POST "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9/domains" \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "domain": "hub.rahal.example" }'

{
  "data": {
    "id": "dom_rahal_hub_01ax",
    "organization_id": "org_sub_rahal_00x9",
    "domain": "hub.rahal.example",
    "status": "pending",
    "cname_target": "domains.orbit.devotel.io",
    "cname_verified_at": null,
    "ssl_cert_provisioned_at": null
  },
  "meta": {
    "request_id": "req_domain_001",
    "timestamp": "2026-08-25T10:06:00Z"
  }
}

Point the domain’s DNS at cname_target, then re-check:

curl -X POST "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9/domains/dom_rahal_hub_01ax/verify" \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" -d '{}'

{
  "data": {
    "id": "dom_rahal_hub_01ax",
    "status": "verified",
    "cname_verified_at": "2026-08-25T10:07:00Z"
  },
  "meta": {
    "request_id": "req_dverify_001",
    "timestamp": "2026-08-25T10:07:00Z"
  }
}

GET /api/v1/subaccounts/{id}/domains returns the same row shape as an array; DELETE /.../domains/{domainId} is a 204 No Content purge.

White-label notification email

Method	Path	Purpose
`GET`	`/api/v1/subaccounts/{id}/notification-email`	Get the from-name / from-address override, its verification state, and the effective sender
`PUT`	`/api/v1/subaccounts/{id}/notification-email`	Set or clear the notification from-address for the subaccount

Notification emails a subaccount sends can go out under its own sender identity. PUT /api/v1/subaccounts/{id}/notification-email accepts from_name and from_address; the override is saved immediately but only becomes the effective sender once its sending domain passes DKIM/SPF. Until then — or when you clear the override by sending an empty from_address — resolution falls back to the parent’s sender, then the platform default. The GET response returns the stored override, its verified flag, and the effective sender actually in use. This endpoint shares branding’s auth model: a parent admin manages any child’s config, and a subaccount’s own admin/owner manages its own when {id} is the caller’s organization.

curl -X PUT "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9/notification-email" \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "from_name": "Rahal Hub", "from_address": "alerts@rahal-hub.example" }'

Check the stored override and which sender is actually in effect:

curl "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9/notification-email" \
  -H "X-API-Key: $ORBIT_API_KEY"

{
  "data": {
    "from_name": "Rahal Hub",
    "from_address": "alerts@rahal-hub.example",
    "verified": false,
    "effective": {
      "from_address": "notifications@orbit.devotel.io",
      "from_name": "Orbit notifications",
      "source": "platform",
      "resolved_from_organization_id": null
    }
  },
  "meta": {
    "request_id": "req_notifemail_001",
    "timestamp": "2026-08-25T10:03:00Z"
  }
}

The override is stored but verified: false until the sending domain passes DKIM/SPF on the Email → Senders surface — while it is unverified the effective sender keeps resolving to the parent or the platform default, so no mail goes out under an unproven identity.

Pricing overrides

Method	Path	Purpose
`GET`	`/api/v1/subaccounts/{id}/pricing`	Get the subaccount’s margin, spend cap, and current-period spend
`PUT`	`/api/v1/subaccounts/{id}/pricing`	Set the subaccount’s reseller margin and monthly spend cap
`GET`	`/api/v1/subaccounts/{id}/mccmnc-overrides`	Per-MCCMNC pricing overrides
`POST`	`/api/v1/subaccounts/{id}/mccmnc-overrides`	Add an override
`DELETE`	`/api/v1/subaccounts/{id}/mccmnc-overrides/{overrideId}`	Remove an override

Subaccount pricing is a flat reseller margin: a single markup percent (reseller_margin_pct, 0–100) applied over Orbit wholesale rates, plus an optional monthly spend cap (monthly_spend_cap_cents). It is not priced per channel. When you need finer control for specific mobile destinations, layer per-MCCMNC rate overrides on top. PUT /api/v1/subaccounts/{id}/pricing replaces the margin and/or cap — a null monthly_spend_cap_cents clears the ceiling back to uncapped:

curl -X PUT "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9/pricing" \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "reseller_margin_pct": 25,
    "monthly_spend_cap_cents": 5000000
  }'

{
  "data": {
    "subaccount_id": "org_sub_rahal_00x9",
    "reseller_margin_pct": 25,
    "monthly_spend_cap_cents": 5000000,
    "current_period_spend_cents": 118492
  },
  "meta": {
    "request_id": "req_pricing_001",
    "timestamp": "2026-08-25T10:04:00Z"
  }
}

Read the same configuration back with GET /api/v1/subaccounts/{id}/pricing — the response also carries the current-period spend the cap is evaluated against, so the spend-cap progress bar and the margin deck are one call.

import { Orbit } from "@devotel-orbit/node";
const orbit = new Orbit({ apiKey: process.env.ORBIT_API_KEY! });
const pricing = await orbit.subaccounts.getPricing("org_sub_rahal_00x9");

curl "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9/pricing" \
  -H "X-API-Key: $ORBIT_API_KEY"

{
  "data": {
    "subaccount_id": "org_sub_rahal_00x9",
    "reseller_margin_pct": 25,
    "monthly_spend_cap_cents": 5000000,
    "current_period_spend_cents": 118492
  },
  "meta": {
    "request_id": "req_pricing_get_001",
    "timestamp": "2026-08-25T10:05:00Z"
  }
}

Per-MCCMNC overrides (PATCH-style upsert)

Layer a per-operator rate on top when the flat margin isn’t fine enough for a given destination. POST upserts the override and returns the written row:

curl -X POST "https://api.orbit.devotel.io/api/v1/subaccounts/org_sub_rahal_00x9/mccmnc-overrides" \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "mccmnc": "52503", "rate_per_unit": 0.018, "currency": "USD" }'

{
  "data": {
    "id": "mccmncOverride_01j72k",
    "mccmnc": "52503",
    "operator_name": "SingTel Singapore",
    "country": "Singapore",
    "rate_per_unit": 0.018,
    "currency": "USD",
    "created_at": "2026-08-25T10:04:00Z"
  },
  "meta": {
    "request_id": "req_mccmnc_001",
    "timestamp": "2026-08-25T10:04:00Z"
  }
}

GET /api/v1/subaccounts/{id}/mccmnc-overrides returns the same rows cursor-paginated; DELETE .../mccmnc-overrides/{overrideId} removes one and returns 204 No Content.

API Reference

All Endpoints

Subaccounts API: manage child orgs and credit transfers

Subaccounts API

Using the SDKs

Lifecycle

Single-call provisioning

Wizard vs single call

List subaccounts

Get a single subaccount

Update a subaccount

Lifecycle transitions

Usage & credits

Get usage

Transfer credits

API keys

List a subaccount’s API keys

Branding & custom domains

Update branding

Custom domains & DNS verification

White-label notification email

Pricing overrides

Per-MCCMNC overrides (PATCH-style upsert)

​Subaccounts API

​Using the SDKs

​Lifecycle

​Single-call provisioning

​Wizard vs single call

​List subaccounts

​Get a single subaccount

​Update a subaccount

​Lifecycle transitions

​Usage & credits

​Get usage

​Transfer credits

​API keys

​List a subaccount’s API keys

​Branding & custom domains

​Update branding

​Custom domains & DNS verification

​White-label notification email

​Pricing overrides

​Per-MCCMNC overrides (PATCH-style upsert)

Subaccounts API

Using the SDKs

Lifecycle

Single-call provisioning

Wizard vs single call

List subaccounts

Get a single subaccount

Update a subaccount

Lifecycle transitions

Usage & credits

Get usage

Transfer credits

API keys

List a subaccount’s API keys

Branding & custom domains

Update branding

Custom domains & DNS verification

White-label notification email

Pricing overrides

Per-MCCMNC overrides (PATCH-style upsert)