Create access tokens
Reference information for planning, creating, validating, protecting, and managing Splunk Observability Cloud organization access tokens.
Prerequisites
Create purpose-specific organization access tokens for telemetry ingestion and any API operations required by the migration wave.
Do not use one token for unrelated environments or purposes.
Confirm that:
- Network connectivity validation is complete.
- You are an organization administrator with permission to create organization access tokens.
- Token owners, naming conventions, expiration requirements, and storage requirements are defined.
- You know which applications, Collectors, and migration operations require tokens.
Determine which tokens you need
Create only the token types required by the migration wave:
| Token scope | Use | Role assignment |
|---|---|---|
|
Ingest |
Send traces and metrics from supported agents and Collectors. Also use this token to send the Phase 2 test metric. |
Ingest tokens do not have a role. |
|
API |
Authenticate approved Migration Tool or automation operations against Splunk Observability Cloud APIs. |
For a Migration Tool API token, assign the admin role. This provides the mandatory admin permission. For other API consumers, assign the least-privileged role that supports the required API operations. |
|
RUM |
Send browser or mobile telemetry to Splunk Real User Monitoring. |
RUM tokens do not have a role. Do not create one for an APM-only migration unless RUM is explicitly in scope. |
For an APM migration, use the table to identify the required tokens:
| Migration activity | Required token | Guidance |
|---|---|---|
|
Send the Phase 2 test metric |
Ingest token |
Required to validate telemetry ingestion. |
|
Send traces and metrics from combined agents or Collectors |
Ingest token |
Required for each approved group of telemetry senders. Ingest tokens do not have an assigned role. |
|
Configure a Migration Tool destination connection and migrate configuration artifacts |
API token |
Assign the admin role. This role is mandatory for Migration Tool destination connections and required migration operations. |
|
Migrate only APM telemetry without configuration artifacts |
No API token required |
An API token is not required for telemetry ingestion. |
|
Send browser or mobile RUM data |
RUM token |
Create only when RUM is included in a separate migration scope. RUM tokens do not have an assigned role. |
For an APM migration, create an Ingest token. Create an API token for configuring a Migration Tool destination connection and migrating configuration artifacts. Do not create a RUM token unless you separately include Real User Monitoring in scope.
Decide when to use separate tokens
Decide which applications, Collectors, environments, or migration processes can safely use the same token. Create a separate token when any of the following differ:
| Consideration | Create a separate token when |
|---|---|
|
Authorization scope |
One consumer requires Ingest access and another requires API access. |
|
Environment |
Production and non-production telemetry must remain separate. |
|
Purpose |
Agents, gateway Collectors, and migration API operations serve different purposes. |
|
Ownership |
Different application teams or administrators manage the consumers. |
|
Lifecycle |
You have different expiration, rotation, or revocation schedules. |
|
Usage management |
You need to monitor or control usage independently. |
Multiple agents or Collectors can share an Ingest token when they operate in the same environment and have the same owner, purpose, expiration, and rotation requirements. Use a separate API token for Migration Tool or other approved automation.
For example:
| Example token name | Purpose |
|---|---|
|
|
Send production APM telemetry from application agents. |
|
|
Send production telemetry from gateway Collectors. |
|
|
Send nonproduction APM telemetry from application agents. |
|
|
Perform approved Migration Tool API operations. |
Follow your organization’s token-naming convention. Use names that identify the environment, purpose, and authorization scope.
For each planned token, record its:
- Name
- Authorization scope
- Environment
- Purpose and systems or processes that use the token
- Owner
- Expiration and rotation requirements
Access-token values are credentials. Store them only in your organization’s approved secret manager. In the migration plan, record the token name, owner, expiration date, and secret-manager reference, but not the token value.
Create an organization access token
Follow Create and manage organization access tokens to create each planned token.
Use the following migration-specific guidance:
| Setting | What to specify |
|---|---|
|
Name |
Follow your organization’s naming convention and identify the environment, purpose, and scope. |
|
Authorization scope |
Select Ingest for telemetry or API for Migration Tool operations. |
|
API role |
For a Migration Tool API token, assign the admin role. For other API tokens, assign the least-privileged role required for the intended operations. |
|
Description |
Identify the migration wave, purpose, and owner. |
|
Visibility |
Limit access to the administrators, users, or teams that require the token. |
|
Expiration |
Follow your organization’s credential-lifecycle policy and configure expiration alerts. |
After creating a token, store its value in your organization’s approved secret manager. Record only its name, owner, expiration date, and secret-manager reference in the migration plan. Repeat the steps for each required token.
If you are configuring a Migration Tool destination connection, create an organization access token with the API authorization scope and the admin role. The admin role is mandatory for the destination connection and for migration operations that create webhook integrations and Business Transaction rules. See About roles in Splunk Observability Cloud.
After creating the token, add it to the destination connection and test the connection. See Configure Connections.
Validate token permissions
Before using a token, confirm its configuration in Settings > Access Tokens:
- The token is active and belongs to the destination organization.
- The authorization scope matches its purpose.
- An Ingest token has the Ingest scope.
- A Migration Tool API token has the admin role. Other API tokens have the role required for their operations.
- The token has not expired.
- Only approved users or teams can view it.
Then validate each token by performing its intended operation:
| Token | Validation |
|---|---|
|
Ingest token |
Send and verify the Phase 2 test metric. |
|
API token |
Add it to Migration Tool destination connection and run the destination connection test. |
|
RUM token |
Validate it only as part of a separately scoped RUM migration. |
See Create and manage organization access tokens and Configure Connections.
Protect and manage the tokens
Access tokens provide ongoing access to Splunk Observability Cloud within their assigned scope and role. Protect token values to prevent unauthorized use, and assign ownership and lifecycle controls so that expiration or rotation does not interrupt telemetry ingestion or migration operations:
- Give each token a documented owner.
- Grant only the required authorization scope and API role.
- Limit who can view or use the token.
- Store token values in an approved secret manager.
- Do not place token values in tickets, migration plans, reports, screenshots, email, chat, or source control.
- Record the expiration date and rotation schedule.
- Update every consumer when rotating a token.
- Revoke temporary migration tokens when you no longer require them.
Record token metadata, such as the name, purpose, owner, scope, role, consumers, and expiration date, but never record the token value in the migration plan.
Confirm readiness
Confirm that:
- [ ] Each token has one documented purpose and owner.
- [ ] You created the required ingest token.
- [ ] You created an API token only if the migration wave requires API operations.
- [ ] Each token has the correct scope.
- [ ] Migration Tool API token has the admin role; other API tokens use the least-privileged role required for their operations.
- [ ] You restricted token visibility to approved users or teams.
- [ ] You configured expiration alerts and rotation ownership.
- [ ] You stored token values in an approved secret manager.
- [ ] No token value appears in the migration documentation.
After completing these checks, continue to Send and Verify a Test Metric.