Starlink managed accounts arrange many Starlink accounts as a tree. A manager account sits at the top, managed accounts sit beneath it, and the tree can run several levels deep. A service account created in the manager account can act in any account below it, so one secret reaches the whole hierarchy. Starlink describes the feature as “designed for customers who control multiple accounts for a single organization”, naming multinational corporations, resellers and providers (about managed accounts).
What are the parts of a managed account tree?
Starlink uses two terms:
- Manager account: an account that has children.
- Managed account: a child of a manager account.
A managed account can have children of its own, so the tree takes whatever shape the organisation needs. Starlink performs the initial set-up through your account manager. After that, customers can create accounts beneath their own through self-service.
How does one credential reach every account?
When a service account in the manager account requests a bearer token, it can include an optional account_number. Starlink returns a token “with identical roles scoped to said account number”. The integration then calls any v2 endpoint as if it were a service account on that managed account.
The practical effect is one client secret for the whole tree, with a short-lived token per account. Starlink adds a caution: never parse the contents of its tokens. To identify the account a token belongs to, call the account endpoint with it.
How do permissions work in the tree?
Users inherit roles from their ancestors. A role assigned at one node applies to that node and every node beneath it. A user’s effective permissions at any account are the union of every assignment made at that account or above it.
That matches how most organisations already work: head office sees everything, a regional office sees its region, a site sees itself.
How do provider and customer accounts differ?
Starlink’s provider model is a related structure (creating accounts):
- A provider account exists once per country, for creating customer accounts and for consolidated billing. Starlink says no customer service lines should be created on it.
- A customer account is created by the provider through the API and linked to the provider account at creation.
- The customer receives a notification and approves the provider’s management of the account: the letter of authorisation. Until the customer accepts it, the provider cannot create service lines on that account (service activation).
What should a platform do with the tree?
A management platform built for managed accounts should:
- Show the tree as it is, with each account’s status, including any waiting for a letter of authorisation.
- Reach every account through the manager account’s one credential.
- Keep each account’s data under that account, so a view of one customer never shows another’s.
- Respect inherited permissions, so a user sees only the part of the tree their role covers.
How does Nexus Telemetry Enterprise approach this?
Nexus Telemetry Enterprise reads the managed account tree through the manager account’s service account and shows every account in it, with each one’s status, service lines, terminals and usage. A provider account shows its customer accounts beneath it, including those waiting for the customer’s letter of authorisation.
Where do you start?
If your accounts belong to one organisation and you manage them separately today, ask your Starlink account manager about managed accounts. If you are a provider, your provider account and its customer accounts already form the structure. The complete guide covers what to demand from the platform that runs it.