This feature is available on Postman Enterprise plans. For more information, see the pricing page.
System service accounts give your team a dedicated, non-human identity for automation, integrations, and system-to-system interactions. Instead of tying CI/CD pipelines or backend services to a person’s credentials, you can create a service account that represents the system itself with its own access controls, credentials, and audit trail.
A service account is a non-human identity you create, for example, admin@company.com. A system service account is an internal automation identity Postman provides, for example, postman-ci-service-account. To learn more about user-created service accounts, see Assign the Admin user.
You must be an Admin or Super Admin to create and manage service accounts.
To create a system service account, do the following:
Click your profile and select your team or organization.
Click Service Accounts in the left sidebar.
Click Create Service Account.
Fill in the fields below, then click Create Service Account.
You can update the account’s name, description, and access assignments at any time after creation.
A descriptive name for the system or integration this account represents.
Additional context about the account’s purpose.
The role within the organization that this service account will have.
After creating the system service account, assign it to the teams and workspaces it needs to access, and then set up and generate API keys for authentication.
To assign the service account to teams and workspaces, do the following:
Next, you can learn more about workspace roles and what each one allows.
System service accounts use the same role-based access control (RBAC) as team members. The role you assign determines what the account can see and do across your organization, teams, and workspaces.
The following table summarizes the available roles and capabilities for system service accounts at each scope. For detailed information on what each role can do, see Roles and permissions.
Each system service account uses a two-step credential model:
Token expiration isn’t configurable. You can configure API key expiration and rotate API keys. Admins and Super Admins can view the last-used timestamp for each key.
The short-lived token is similar to a token generated when a user authenticates and enables the integration to perform Postman actions on their behalf.
To generate an API key for a system service account, do the following:
The API key is only displayed once. You won’t be able to view it again after dismissing the dialog.
Use the API key to obtain a short-lived session token for your automation scripts and integrations.
To obtain a short-lived session token, do the following:
x-api-key HTTP header.Admins and Super Admins can view all system service accounts across the team, including their assigned permissions, active credentials, and last activity.
As an Admin, for each service account, you can do the following:
To rotate a service account’s credentials without interrupting your systems, do the following:
All system service account actions are captured in your team’s audit logs, giving Admins a clear record of what was created, changed, or accessed—and when. To view audit logs, see Audit logs.
The audit log keeps the following service account events:
System service accounts are designed to limit exposure at every stage of the credential lifecycle. Tokens are short-lived by default, so a compromised token has a narrow window of usefulness. When you need to rotate credentials, you can hold multiple API keys simultaneously, update your systems with the new key, and only then revoke the previous one. There’s no forced downtime.