Every call to the Starlink Enterprise API is made with a V2 service account. Starlink defines it as “a ClientId, permission set, and secret set” (V2 service accounts). Service accounts are created in the Starlink dashboard, never through the API, and each is linked to one Starlink account.
Who can create a service account?
A user with the Admin or Service Account Management role creates and edits service accounts, from the account’s settings page in the Starlink dashboard. Users can give a service account permissions “up to the user’s individual permissions”, never more.
Starlink adds a warning worth repeating: any user who can create or update service accounts can also disable them. That permission should go to trusted users only. There is no API for managing service accounts. Starlink’s API access management page explains why: “because of the security risk inherent in such a model”.
How do permissions work?
Service accounts follow role-based access control. Each service account carries a permission set, and each endpoint requires a specific permission, at a read or edit level, listed in Starlink’s API reference. A call without the right permission returns a 403 naming the permission it needed.
The practical rule is least privilege: a read-only integration gets read permissions only, and edit permissions are added when an integration needs to make changes.
How do secrets and tokens work?
From Starlink’s authentication page:
- Creating a service account produces a client ID and a secret. A service account can hold up to 20 secrets, and an account up to 20 service accounts.
- The client ID and a secret are exchanged for a bearer token through OpenID Connect. The token is reused until a 401 response shows it has expired, then replaced.
- Secrets can carry an optional expiry, which makes rotation simple: create a new secret, move the integration to it, delete the old one.
- Service accounts calling the API do not complete multi-factor authentication.
Starlink’s instruction on custody is firm: store the secret like any other sensitive credential, encrypted, and never in client-side code or a public repository. Starlink may revoke secrets it finds exposed. For providers, Starlink requires a key management system for credentials and validates it during onboarding.
How do you revoke access?
Access stays with the account holder. In the Starlink dashboard, a user with the right role can:
- Delete a secret, which ends access for anything using it.
- Disable the service account, which ends access for all its secrets.
Starlink notes that secrets can be deleted, but a service account can only be disabled, never deleted, “to preserve traceability”.
What should you ask of any platform that holds your keys?
- Which permissions it needs, and why, with read-only as the starting point.
- How it stores secrets, and whether they are ever shown again after entry.
- That revoking access in the Starlink dashboard is enough to end it.
- A dedicated service account per integration, so revoking one never breaks another.
How does Nexus Telemetry Enterprise approach this?
Nexus Telemetry Enterprise connects each account through a service account you create for it, with read permissions to start. Access stays in your hands: deleting the secret or disabling the service account in the Starlink dashboard ends it at once.
Where do you start?
Open your account’s settings in the Starlink dashboard and check the list of existing service accounts: who created each, what it is for, and whether its secrets expire. Then create a dedicated service account for each new integration.