Automating user management using Striim APIs
This topic describes how to use the Striim Cloud REST APIs to manage users, roles, and service access without signing in to the console for each operation.
Automating these tasks lets you onboard users consistently, grant and remove service access as part of an existing workflow, and clean up accounts when people or automations no longer need access. You can list users and services, invite users, change roles, federate users to services or remove them, check federation status, delete users, and create and manage service accounts.
This topic is intended for Striim Cloud account administrators and for teams that automate user onboarding, service access, and account cleanup.
Before you begin
You need the following:
Your Striim Cloud account short name, which forms part of the account-specific API base URL.
A valid bearer token that has not expired or been revoked.
Administrator access for account-level operations such as inviting users, changing roles, deleting users, and managing service access for other users.
A secure location in which to store tokens, such as a secrets manager or vault.
Important
Do not hard-code tokens in automation scripts, configuration files, or source code repositories.
Authentication
Every request must include a valid token in the Authorization header. The APIs use token-based authentication over TLS.
Authorization: Bearer <your-token>
Replace <your-token> with your personal access token (PAT) or service account token. For example:
curl -X GET "https://{your-account}.striim.cloud/api/v1/users" \
-H "Authorization: Bearer <your-token>"The token you use determines which operations you can perform.
Token type | When to use it | Notes |
|---|---|---|
Administrator PAT | An administrator is running the API manually or from a personal script. | The token has the same permissions as the administrator who created it. |
Service account token | Shared automation, CI/CD pipelines, scheduled jobs, or enterprise onboarding workflows. | This is the recommended option for production automation. |
Non-administrator user PAT | APIs that allow users to perform actions for themselves. | A user can use only their own token, and only for supported self-service actions. |
Base URL
Send requests to your account-specific subdomain, which depends on the cloud provider that hosts your account. Replace {your-account} with your Striim Cloud account short name.
Cloud provider | Production base URL |
|---|---|
Google Cloud |
|
Microsoft Azure |
|
AWS |
|
The examples in this topic use BASE_URL and TOKEN variables. Set them once and reuse them in your scripts.
export BASE_URL="https://{your-account}.striim.cloud/api/v1"
export TOKEN="<your-token>"Key concepts
Three concepts determine the outcome of most user management requests: the user's status, the user's role, and whether the user is federated to a service.
User status
A user's status determines whether the user can sign in and whether federation can complete. Use the list users API to check the current status.
Status | Meaning |
|---|---|
active | The user has activated the account and can sign in. |
pending | The user has been invited but has not completed activation. |
expired | The user's invitation has expired. Re-invite the user to send a new invitation. |
Roles
Roles control what a user can do in the Striim Cloud control plane. The API accepts role names case-insensitively; the examples in this topic use the canonical values.
Role name | Description |
|---|---|
Admin | Full administrative access for the account. |
ServiceAdmin | Service-level administration access. |
Developer | Development access. Developers can be federated to services. |
Viewer | Read-only access. Viewers cannot be federated to services. |
Note
When a user signs in through SAML SSO for the first time, Striim Cloud creates the user in the control plane with the Viewer role. Change the role to Developer, ServiceAdmin, or Admin before you federate the user to a service.
Service federation
Federation grants a control plane user access to a Striim Cloud service. When you federate a user to a running service, Striim Cloud adds the user to that service. Federation can also remain pending.
Federation state | When it occurs | What happens next |
|---|---|---|
active | The user is activated and the service is running. | The user is available in the service. |
pending, user not activated | An administrator requested federation before the user accepted the invitation. | After the user activates the account, Striim Cloud federates the user to the requested running services. |
pending, service stopped | The service to which the user is federated is stopped or inactive. | After the service starts, Striim Cloud completes federation through a background job. Completion may take a short time. |
Important
Changing a user's control plane role does not change the role already applied inside a service. To apply the new role in a service, remove the user's service access and then federate the user again.
Recommended automation workflow
Use the following sequence when you automate onboarding for a new user. Checking state before each change reduces conflicts and unnecessary retries.
List users to check whether the user already exists and whether the user is active, pending, or expired.
Invite the user if the user does not exist, or re-send the invitation if the user is pending or expired.
Set the correct role if the user must be a Developer, ServiceAdmin, or Admin.
List services to find the services that the user should access.
Federate the user to one or more services. If the user has not activated the account or the service is stopped, federation remains pending.
Check federation status to confirm whether the user is active in the service or pending for a known reason.
Tip
For repeatable onboarding, record the user email, intended role, service list, and operation result in your automation logs. Doing so makes it easier to retry only the failed or pending steps.
API quick reference
The following table summarizes the user management endpoints and the token each one requires.
Action | Method | Endpoint | Required token |
|---|---|---|---|
List users | GET |
| Any valid PAT or service account token. |
Invite or re-invite a user | POST |
| Administrator PAT or service account token with admin access. |
Change a user's role | PUT |
| Administrator PAT or service account token with admin access. |
List services | GET |
| Any valid PAT or service account token. |
Federate a user to services | POST |
| Administrator PAT or service account token with admin access. Supported users may also use their own PAT for self-federation. |
Remove a user from services | POST |
| Administrator PAT or service account token with admin access. Supported users may also use their own PAT for self-removal. |
Check service federation | GET |
| Any valid PAT or service account token. |
Delete a user | DELETE |
| Administrator PAT or service account token with admin access. |
Create a service account | POST |
| Administrator PAT or service account token with admin access. |
Update a service account role | PUT |
| Administrator PAT or service account token with admin access. |
Federate a service account to services | POST |
| Administrator PAT or service account token with admin access. |
Remove a service account from services | DELETE |
| Administrator PAT or service account token with admin access. |
Managing users
These endpoints list, invite, update, and delete the users in your account.
List users
Returns the users in the account. Use the query parameters to filter by role, state, or name.
Query parameter | Description | Example |
|---|---|---|
| Filter by role name. |
|
| Filter by user state. |
|
| Filter by user name or email text. |
|
| Page number. The default is 0. |
|
| Page size. |
|
curl -X GET "$BASE_URL/users?role=Developer&state=active&page=0&size=20" \ -H "Authorization: Bearer $TOKEN"
The response lists each user with an ID, email address, and status.
{
"users": [
{ "user-id": 123, "email": "user@example.com", "status": "active" },
{ "user-id": 456, "email": "pending@example.com", "status": "pending" }
]
}Invite or re-invite a user
Invites a user to join a Striim Cloud account. If the user is already pending, the API re-sends the invitation.
When SSO is configured, this API is available only if invitation-based sign-in, also known as basic authentication, is enabled for the account.
Field | Required | Description |
|---|---|---|
| Yes | Email address of the user to invite. |
| No | Role to assign to the user. Valid values are |
curl -X POST "$BASE_URL/user" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"email": "newuser@example.com",
"role-name": "Developer"
}'{
"message": "Successfully invited new user newuser@example.com"
}Note
Use the same endpoint to re-invite a pending or expired user. If the user already exists and is not pending, the API returns a conflict response.
Change a user's role
Updates a user's control plane role. Identify the user by either user-id or email, but not both.
Field | Required | Description |
|---|---|---|
| One of | Numeric user ID. |
| One of | User email address. |
| Yes | New role to assign. |
curl -X PUT "$BASE_URL/user/role" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"email": "user@example.com",
"role-name": "Admin"
}'{
"user-id": 456,
"role-name": "Admin",
"message": "user role updated successfully"
}Important
An administrator cannot change their own role through this API. A role change does not update an existing service federation. Remove the user from the service and federate the user again to apply the updated service-level role.
Delete a user
Removes a user from the Striim Cloud account, along with the user's active service federations and pending federation requests.
curl -X DELETE "$BASE_URL/user/456" \ -H "Authorization: Bearer $TOKEN"
A successful request returns 204 No Content with no response body.
Important
An administrator cannot delete their own user account through this API. If a user was created by SSO and signs in again after deletion, Striim Cloud creates the control plane user again with the default SSO role.
Revoke a user's personal access token
Revoke a user's PAT when the token is no longer required or may have been exposed.
curl -X DELETE "$BASE_URL/user-token?email=user@example.com" \ -H "Authorization: Bearer $TOKEN"
Note
Revoking a PAT invalidates the token immediately. Update any scripts or tools that use the token to use a different valid token.
For more information about token management, see Managing API tokens in Striim Cloud.
Managing service access
These endpoints list the services in your account and control which users can reach them.
List services
Returns the services in the account. Use this endpoint before federating users, to determine the target service names or IDs.
Query parameter | Description | Example |
|---|---|---|
| Filter by service state. |
|
| Filter by service name. |
|
| Page number. The default is 0. |
|
| Page size. The default is 20 and the maximum is 100. |
|
curl -X GET "$BASE_URL/services?state=running&size=50" \ -H "Authorization: Bearer $TOKEN"
{
"services": [
{ "id": 400, "name": "my-pipeline", "state": "running" },
{ "id": 401, "name": "backup-pipeline", "state": "stopped" }
]
}Federate a user to services
Federates a user to one or more services. Administrators and service account tokens with admin access can federate any user in the account. A user PAT can be used only for supported self-federation actions, and the user must have a role that can be federated.
Field | Required | Description |
|---|---|---|
| One of | Numeric user ID. |
| One of | User email address. |
| No | Array of service names. If omitted, all services in the account are considered. |
curl -X POST "$BASE_URL/services/user/federate" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"email": "user@example.com",
"services": ["serv1", "serv2", "serv3"]
}'Note
If the user is not activated or the target service is stopped, the federation request remains pending. Use the federation status API to check the reason.
Remove a user from services
Removes a user's service federation, which removes the user's access to the specified services.
Pending federation is handled in the same way as active federation, except that a user who has not activated the account cannot be removed from a federation that has not yet been created.
curl -X POST "$BASE_URL/services/user/revoke" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"user-id": 123,
"services": ["serv1", "serv2"]
}'Check federation status
Returns the active and pending users for a service. Use this endpoint after federating or removing a user to verify the result and identify the reason for any pending federation.
Parameter | Required | Description |
|---|---|---|
| Yes | Path parameter. Numeric service ID. |
| No | Query parameter. Filters federation status by user ID. |
curl -X GET "$BASE_URL/services/400/users?user-id=123" \ -H "Authorization: Bearer $TOKEN"
{
"id": 400,
"name": "my-pipeline",
"federated-users": [
{
"user-id": 123,
"username": "striim_user_123",
"is-admin": false,
"state": "done",
"created-at": "2026-06-23T10:30:00Z"
}
],
"pending-users": [
{
"user-id": 456,
"email": "newuser@example.com",
"reason": "User not activated yet",
"created-at": "2026-06-23T10:35:00Z"
}
]
}Pending reasons include User not activated yet and Service in stopped state. When the user activates the account or the service starts, Striim Cloud completes the pending federation automatically.
Managing service accounts
Service accounts provide tokens for shared automation, so that pipelines and scheduled jobs do not depend on an individual user's credentials.
Create a service account
Creates a service account token. You can optionally set the token expiry, administrator scope, and the services to which the service account is federated.
Field | Required | Description |
|---|---|---|
| Yes | Unique service account name, from 3 to 30 characters. |
| No | Description of the token's purpose. The maximum length is 255 characters. |
| No | Expiration timestamp in ISO 8601 format. If omitted, the account default is used. |
| No | Boolean value that controls admin scope. The default is |
| No | Array of service names. If omitted, all services in the account are considered. |
curl -X POST "$BASE_URL/service-account" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "ci-pipeline",
"description": "Token for CI/CD automation",
"expires-at": "2027-02-09T00:00:00Z",
"is-admin": true,
"services": ["serv1", "serv2"]
}'{
"token-id": 12345,
"name": "ci-pipeline",
"token": "9AbCdEfG3h4I.jKlMn-OpQrStUvWx",
"expires-at": "2027-02-09T00:00:00Z"
}Important
The full token value is displayed only once. Copy and store it securely before you leave the response or page. If the value is lost, rotate or recreate the token.
Change a service account's admin scope
Changes whether a service account has administrator scope. Identify the service account by name in the query string and provide the new is-admin value in the request body.
Field | Required | Description |
|---|---|---|
| Yes | Query parameter. Name of the service account to update. |
| Yes | Boolean value. Use |
curl -X PUT "$BASE_URL/service-account/role?name=ci-pipeline" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"is-admin": true
}'{
"is-admin": true
}Note
A service account role change does not update the role inside services to which the service account is already federated. Remove the service account from the affected services and federate it again to apply the updated role.
Federate a service account to services
Federates a service account to one or more services. Use this API when the automation needs access to additional services in the data plane.
Field | Required | Description |
|---|---|---|
| Yes | Name of the service account to federate. |
| No | Array of service names. If omitted, all services in the account are considered. |
curl -X POST "$BASE_URL/services/service-account/federate" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "service-account-prd",
"services": ["serv1", "serv2", "serv3"]
}'{
"name": "service-account-prd",
"service-ids": [15260, 14662]
}Tip
Specify service names to limit the service account to the services that the automation requires. This is preferable to federating the service account to every service by default.
Remove a service account from services
Removes a service account from one or more services. Use this API when automation no longer needs access to a service, or before you re-federate the service account after a role change.
Field | Required | Description |
|---|---|---|
| Yes | Name of the service account to remove. |
| No | Array of service names. If omitted, all services in the account are considered. |
curl -X DELETE "$BASE_URL/services/service-account/revoke" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "service-account-prd",
"services": ["serv1", "serv2"]
}'{
"name": "service-account-prd",
"service-ids": [15260, 14662]
}Rate limits
Striim Cloud applies rate limits by IP address, by token, and, for selected administrative operations, by account. Implement retry logic with exponential backoff in automated workflows.
Operation | Method | IP limit | Token limit | Account limit |
|---|---|---|---|---|
List users | GET | 100 requests/min | 10 requests/sec | Not applicable |
Invite or delete a user | POST, DELETE | 100 requests/min | 5 requests/sec | 30 requests/min |
Update a role | PUT | 100 requests/min | 5 requests/sec | 30 requests/min |
List services | GET | 100 requests/min | 10 requests/sec | Not applicable |
Federate or remove a user from a service | POST | 100 requests/min | 5 requests/sec | 20 requests/min |
Federation status | GET | 100 requests/min | 10 requests/sec | Not applicable |
Service account federation or removal | POST, DELETE | 100 requests/min | 5 requests/sec | 20 requests/min |
Audit logging and visibility
Striim Cloud records user management operations performed through the API in account-level audit logs. Audit entries identify the operation, the actor, the target user, the target service where applicable, and the result. Use audit logs to validate automation, investigate changes, and support compliance reviews.
The service also emits standard HTTP and rate-limit metrics for the user management APIs. These metrics help administrators monitor API usage patterns and detect abnormal request volume.
Errors and troubleshooting
The API returns standard HTTP responses. Use the status code and message to correct the request or to retry safely.
Status code | What it usually means | What to check |
|---|---|---|
400 Bad Request | The payload or query parameter is invalid. | Verify the required fields, the |
401 Unauthorized | The token is missing, invalid, expired, revoked, or rotated. | Check the |
403 Forbidden | The token does not have permission for the operation, or the target resource is outside the account. | Use an administrator PAT or an admin service account token for account-level actions. |
404 Not Found | The user or service was not found. | Confirm the user ID, email address, service ID, or service name. |
409 Conflict | The operation conflicts with the current user state. | For example, the email address already exists and the user is not pending. |
429 Too Many Requests | A rate limit was exceeded. | Wait and retry with exponential backoff. |
Common issues
The following situations account for most failed or incomplete automation runs.
The user cannot be federated: confirm that the user is not a Viewer. Change the user's role to Developer, ServiceAdmin, or Admin before federation.
Federation remains pending: check whether the user has activated the account and whether the target service is running.
A role change is not reflected in a service: remove the user's service federation and federate the user again.
A re-invitation fails: confirm that the existing user is pending or expired. Active users cannot be re-invited through the invitation flow.
An SSO user returns after deletion: if the user signs in again through SSO, Striim Cloud creates the user again with the default SSO role.
Example: onboarding a new developer
The following example invites a user, assigns the Developer role, federates the user to two services, and checks the resulting federation status.
# 1. Invite the user
curl -X POST "$BASE_URL/user" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{ "email": "developer@example.com", "role-name": "Developer" }'
# 2. Confirm or update the role
curl -X PUT "$BASE_URL/user/role" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{ "email": "developer@example.com", "role-name": "Developer" }'
# 3. Federate the user to selected services
curl -X POST "$BASE_URL/services/user/federate" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"email": "developer@example.com",
"services": ["orders-pipeline", "inventory-pipeline"]
}'
# 4. Check service federation status
curl -X GET "$BASE_URL/services/400/users" \
-H "Authorization: Bearer $TOKEN"Best practices
The following practices keep automated user management secure and predictable.
Use service account tokens for shared automation, and store them in a secrets manager.
Create service accounts with the narrowest service scope that the automation requires.
Use service account names that identify the automation's owner and purpose.
Use the least privileged role that supports the workflow.
Do not embed personal access tokens in shared scripts, CI/CD jobs, or source control.
Validate user and service state before making changes, to reduce conflicts and unnecessary retries.
Treat pending federation as a normal state, and re-check the status after the user activates or the service starts.
Use exponential backoff for 429 responses, and avoid tight retry loops.
Capture automation logs with request IDs, target email addresses, roles, services, timestamps, and status codes.
Rotate automation tokens regularly, and update dependent jobs immediately after rotation.