Skip to main content

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

https://{your-account}.striim.cloud/api/v1

Microsoft Azure

https://{your-account}.us-striim.cloud/api/v1

AWS

https://{your-account}.us2-striim.cloud/api/v1

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.

  1. List users to check whether the user already exists and whether the user is active, pending, or expired.

  2. Invite the user if the user does not exist, or re-send the invitation if the user is pending or expired.

  3. Set the correct role if the user must be a Developer, ServiceAdmin, or Admin.

  4. List services to find the services that the user should access.

  5. Federate the user to one or more services. If the user has not activated the account or the service is stopped, federation remains pending.

  6. 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

/users

Any valid PAT or service account token.

Invite or re-invite a user

POST

/user

Administrator PAT or service account token with admin access.

Change a user's role

PUT

/user/role

Administrator PAT or service account token with admin access.

List services

GET

/services

Any valid PAT or service account token.

Federate a user to services

POST

/services/user/federate

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

/services/user/revoke

Administrator PAT or service account token with admin access. Supported users may also use their own PAT for self-removal.

Check service federation

GET

/services/{service-id}/users

Any valid PAT or service account token.

Delete a user

DELETE

/user/{userID}

Administrator PAT or service account token with admin access.

Create a service account

POST

/service-account

Administrator PAT or service account token with admin access.

Update a service account role

PUT

/service-account/role?name={name}

Administrator PAT or service account token with admin access.

Federate a service account to services

POST

/services/service-account/federate

Administrator PAT or service account token with admin access.

Remove a service account from services

DELETE

/services/service-account/revoke

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

role

Filter by role name.

role=Developer

state

Filter by user state.

state=active

name

Filter by user name or email text.

name=alice

page

Page number. The default is 0.

page=0

size

Page size.

size=20

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

email

Yes

Email address of the user to invite.

role-name

No

Role to assign to the user. Valid values are Admin, ServiceAdmin, Developer, and Viewer. If omitted, the role defaults to Developer.

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

user-id

One of user-id or email.

Numeric user ID.

email

One of user-id or email.

User email address.

role-name

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

state

Filter by service state.

state=running

name

Filter by service name.

name=my-pipeline

page

Page number. The default is 0.

page=0

size

Page size. The default is 20 and the maximum is 100.

size=50

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

user-id

One of user-id or email.

Numeric user ID.

email

One of user-id or email.

User email address.

services

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

service-id

Yes

Path parameter. Numeric service ID.

user-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

name

Yes

Unique service account name, from 3 to 30 characters.

description

No

Description of the token's purpose. The maximum length is 255 characters.

expires-at

No

Expiration timestamp in ISO 8601 format. If omitted, the account default is used.

is-admin

No

Boolean value that controls admin scope. The default is false.

services

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

name

Yes

Query parameter. Name of the service account to update.

is-admin

Yes

Boolean value. Use true to grant admin scope or false to remove it.

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

name

Yes

Name of the service account to federate.

services

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

name

Yes

Name of the service account to remove.

services

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 role-name value, and that exactly one of user-id or email was provided.

401 Unauthorized

The token is missing, invalid, expired, revoked, or rotated.

Check the Authorization header and the token lifecycle.

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.