Service tokens

Service tokens provide machine-to-machine authentication for specific Posit Connect capabilities. Unlike user API keys, service tokens are not tied to a user account. This makes them suitable for automated systems that must remain functional regardless of user lifecycle changes. Service tokens do not consume a license seat.

When to use service tokens

Use service tokens when the credential should survive user deactivation, role changes, or account deletion and:

You need to authenticate System for Cross-domain Identity Management (SCIM) identity provisioning (identity:manage scope)
You need to authenticate nameservice read access (nameservice:read scope)
You need to authenticate Chronicle usage data collection (content:search, groups:read, users:read, instrumentation:read, tags:read, feature-usage:read, server-settings:read scopes)

Use administrator API keys when:

You need full administrator access for a one-time or interactive task
The calling system already authenticates as a specific user

Available scopes

Service tokens are scoped to specific capabilities and cannot be used for general Connect API access. Service tokens support the following scopes:

Scope	Description
`identity:manage`	Manage users and groups via SCIM
`nameservice:read`	Read user and group information for the nameservice
`content:search`	Search content items
`groups:read`	List groups and group members
`users:read`	List users
`instrumentation:read`	Read content visit and Shiny usage data
`tags:read`	List tags
`feature-usage:read`	Read feature usage data
`server-settings:read`	Read server settings and runtime installations

Creating a service token

Create a service token using the Connect API. You need an administrator API key to create service tokens.

Terminal

curl -X POST https://connect.example.com/__api__/v1/system/service-tokens \
  -H "Authorization: Key ADMIN-API-KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "SCIM Provisioning", "scopes": ["identity:manage"]}'

See the create service token API reference for request and response details.

Warning

The key value is only returned once at creation time. Store it securely before closing the response. If lost, delete the token and create a new one.

Setting an expiry

By default, a service token never expires. To create a token that expires automatically, include an optional expires_at timestamp in RFC 3339 format. The value must be in the future.

Terminal

curl -X POST https://connect.example.com/__api__/v1/system/service-tokens \
  -H "Authorization: Key ADMIN-API-KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "SCIM Provisioning", "scopes": ["identity:manage"], "expires_at": "2026-12-31T00:00:00Z"}'

Once the expiry passes, the token can no longer be used to authenticate.

Using a service token

Include the token in the Authorization header as a bearer token:

Terminal

curl -H "Authorization: Bearer SERVICE-TOKEN" \
  https://connect.example.com/scim/v2/Users

Listing service tokens

Use the list service tokens endpoint to view existing tokens.

Terminal

curl -X GET https://connect.example.com/__api__/v1/system/service-tokens \
  -H "Authorization: Key ADMIN-API-KEY"

Deleting service tokens

Use the delete service tokens endpoint to delete existing tokens.

Terminal

curl -X DELETE https://connect.example.com/__api__/v1/system/service-tokens/TOKEN-GUID \
  -H "Authorization: Key ADMIN-API-KEY"

Deleting a token immediately revokes access.

Rotating a service token

To rotate a service token:

Create a new token with the same scope.
Update the consuming system with the new token value.
Delete the old token.

Update your consuming system before deleting the old token to avoid service interruptions.

Audit log behavior

Operations authenticated with a service token are attributed to the service token itself in audit logs, not to any user account.