Summary and recommendation
Telnyx user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Telnyx user management lives entirely in the Mission Control Portal under Account Settings → Users & Roles.
The permission model is a fixed three-tier hierarchy Owner, Admin, and Member
applied at the account level, meaning every app or product area your team accesses inherits the same coarse role boundaries with no custom roles or per-resource granularity documented.
User seats carry no per-seat cost;
all Telnyx billing is usage-based (voice minutes, SMS, phone numbers).
Quick facts
| Admin console path | Mission Control Portal → Account Settings → Users & Roles |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Owner | Full account access including billing, API keys, number management, sub-accounts, and user administration. Cannot be removed by other roles. | Cannot transfer ownership through the UI without contacting Telnyx support. | Only one Owner per account. Owner role cannot be assigned to additional users. | ||
| Admin | Can invite and remove users, manage phone numbers, configure products, and access most account settings. Cannot manage billing or change the Owner. | Cannot access or modify billing information or remove the Owner. | |||
| Member | Read and limited write access to assigned product areas. Scope depends on what the Admin or Owner grants at invitation. | Cannot invite other users, access billing, or manage account-level settings. | Permission granularity for Members is limited; Telnyx does not document fine-grained per-resource permission assignment for this role. |
Permission model
- Model type: role-based
- Description: Telnyx uses a fixed three-tier role model (Owner, Admin, Member) applied at the account level. There is no documented support for custom roles or per-resource permission sets beyond the predefined roles.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Account-level roles only; no documented per-product or per-resource granularity for individual users.
How to add users
- Log in to the Mission Control Portal at portal.telnyx.com.
- Navigate to Account Settings → Users & Roles.
- Click 'Invite User'.
- Enter the invitee's email address.
- Select the role to assign (Admin or Member).
- Click 'Send Invitation'.
- Invitee receives an email and must accept the invitation to gain access.
Required fields: Email address, Role selection (Admin or Member)
Watch out for:
- Invitations expire if not accepted within a set period; the exact expiry window is not documented in official help articles.
- The inviting user must hold the Owner or Admin role to send invitations.
- Users must create or already have a Telnyx account tied to the invited email address.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise (SAML SSO with Azure AD is documented; SCIM automated provisioning is not documented as available) |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Telnyx support documentation describes removing users from an account via the Users & Roles section of Mission Control Portal. The action revokes the user's access to the account. Whether this constitutes a hard delete of the user record or a deactivation/revocation of membership is not explicitly distinguished in official documentation.
- Log in to the Mission Control Portal.
- Navigate to Account Settings → Users & Roles.
- Locate the user to remove.
- Select the option to remove or revoke the user's access.
- Confirm the action.
| Data impact | Behavior |
|---|---|
| Owned records | Not explicitly documented. Phone numbers, configurations, and resources remain associated with the account, not the individual user. |
| Shared content | Not explicitly documented. |
| Integrations | API keys are tied to the account, not individual users, so integrations using account-level API keys are not affected by user removal. |
| License freed | Telnyx uses usage-based pricing with no per-seat license fees documented; removing a user does not free a paid seat. |
Watch out for:
- The Owner cannot be removed by other users; only Telnyx support can facilitate ownership changes.
- Official documentation does not describe a reversible 'deactivate' state distinct from removal; re-inviting the user would be required to restore access.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Account user seat | Access to Mission Control Portal and account resources per assigned role. | No documented per-seat fee; Telnyx pricing is usage-based (pay-as-you-go for voice, SMS, and SIP trunking). |
- Where to check usage: Mission Control Portal → Account Settings → Users & Roles (view current users and roles)
- How to identify unused seats: No documented automated tool for identifying inactive users. Admins must manually review the Users & Roles list.
- Billing notes: Telnyx does not charge per user seat. Costs are based on usage (minutes, messages, phone numbers). Adding or removing users has no direct billing impact.
The cost of manual management
Because Telnyx has no native SCIM support, provisioning and deprovisioning must be handled manually through the portal for every user. Admins must individually invite each person by email, wait for invitation acceptance, and later locate and remove users one at a time from the Users & Roles list.
There is no automated tool to surface inactive accounts - identifying stale access means manually cross-referencing the portal roster against your HR or directory system.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Every app your team uses alongside Telnyx that relies on IdP-driven provisioning will require a separate manual step, because Telnyx supports SAML SSO with Azure AD only for authentication - not for automated user lifecycle management. The Owner role is a single, non-transferable seat that cannot be reassigned through the UI;
ownership changes require contacting Telnyx support directly. Teams using Okta or Google Workspace as their IdP will find no native provisioning path documented.
Bottom line
Telnyx's user management is functional for small teams comfortable with a fixed role model and manual workflows, but it creates real operational overhead at scale.
No SCIM, no custom roles, no last-login visibility, and a single non-transferable Owner seat are the four constraints most likely to matter as your team grows.
If your organization runs IdP-driven provisioning, plan to bridge that gap with a dedicated integration layer or accept fully manual lifecycle management.
Automate Telnyx workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
