Ingest tokens authenticate clients that send data to Observe by Snowflake. Standalone ingest tokens do not bind requests to a destination dataset. Ingest Routing determines the destination.

Choose the right credential

A token name identifies a client or team for administration; it does not restrict ingestion to datasets bearing that name. Separate tokens let you monitor and revoke clients independently. Do not treat token names, package headers, or routing predicates as access-control boundaries.

Prerequisites

Open Data & integrations > Ingest tokens. Some navigation layouts place it under Manage account > Ingest tokens.

The page must be enabled for your account. The navigation entry requires workspace administration access, and creation and editing require the datastream:create permission. If the page or controls are unavailable, ask your administrator to check feature availability and permissions.

Create the destination and configure routing before sending data. See Source Datasets and Ingest Routing.

Create a token

1. Open Ingest tokens and select Create ingest token.
2. Enter a descriptive Name, such as production-checkout-collector, and optionally a Description identifying its owner and purpose.
3. Select Create.
4. Copy the complete credential into your secret manager. Observe by Snowflake shows it only once.
5. Confirm that you stored the credential and select Continue.

New tokens start enabled. You can also create a token during an integration or source dataset setup flow.

The credential has the form <token-id>:<secret>. Use the entire value, including the colon, for ingestion. The ID shown in the token list is not sufficient to authenticate. If you lose the credential, create a replacement; you cannot retrieve it again.

Authenticate ingestion

Load the complete credential from your secret manager into OBSERVE_TOKEN. Copy the collection URL from your account's setup instructions; retain its region-specific hostname.

Send this header to the collection endpoint:

Authorization: Bearer <token-id>:<secret>

Unlike management API authentication, this header does not include a separate customer ID. The collection hostname identifies your account. The endpoint and routing configuration determine the destination.

Prefer the authorization header over credentials in URLs or query parameters, which can leak through logs. Do not commit credentials or include them in screenshots, support messages, shell tracing, or agent transcripts.

Monitor and manage tokens

The token list shows ID, Name, Description, State, creator details, Last received, Bytes/hour, and Observations/hour. Use these fields to identify active clients and check activity after credential changes.

• Edit changes a token's name or description, not its credential or destination routing.
• Disable in the State control prevents further ingestion using that token. It affects every client sharing the credential, not stored data.
• Enable allows clients with that credential to authenticate again.
• Delete removes the token. Clients must use another credential; deleting a token does not delete its destination datasets.

Token activity does not prove that data reached the intended dataset. Verify a recognizable sample in that dataset as well.

Rotate without interrupting ingestion

1. Create a replacement token and store its credential securely.
2. Preserve the client's endpoint, package header, and routing behavior. For an associated token, follow the migration guidance below.
3. Update one client to use the replacement, then verify a sample in the intended dataset.
4. Update every remaining client sharing the old credential and verify continued ingestion.
5. Disable the old token. Check client errors and destination activity before proceeding.
6. Delete the old token once you confirm that no client needs it.

If ingestion fails during a planned rotation, restore the previous client configuration and re-enable the old token while investigating. Do not re-enable a credential suspected of compromise; issue a new credential instead.

Do not apply management API token expiration settings to ingest tokens. The ingest token create/update interfaces do not expose an expiration setting. Use deliberate rotation and revocation rather than relying on an assumed expiry date.

Migrate an associated token

Replacing an associated token with a standalone token changes routing behavior, not just authentication. First configure a matching package destination or content route. Send test data using the replacement and verify its destination before updating production clients.

Omitting X-Observe-Target-Package does not remove an existing token association. See the routing decision guide.

Manage tokens through the API

Use a management API token on the Observe by Snowflake application host, not the collection host. The API caller needs appropriate resource access; mutations require datastream:create. Availability and account quotas also apply.

{id} is the stable string token ID returned as id, not a numeric object ID. The create response's secret contains the complete <token-id>:<secret> credential. Store it as returned; do not prepend id again.

The create request accepts an optional unique name and optional description:

{"name":"production-checkout-collector","description":"Checkout production telemetry"}

Names must be unique within the account and at most 127 bytes. Descriptions can contain up to 255 bytes. A create request does not configure destination associations or routes.

For example, with OBSERVE_API_URL set to the account's HTTPS application origin without a trailing slash:

curl --fail-with-body --silent --show-error \
  "${OBSERVE_API_URL:?}/v1/ingest/tokens?expand=true&limit=100&offset=0" \
  -H "Authorization: Bearer ${OBSERVE_CUSTOMER_ID:?} ${OBSERVE_API_TOKEN:?}"

expand=true adds usage statistics to list and inspect responses when available. Unused tokens may have no stats field; that alone is not an error.

To disable a token, send {"disabled":true} with PATCH; use false to enable it. The same endpoint accepts name and description updates. Handle a name conflict by inspecting the existing resource before retrying creation. If a create response is lost, listing tokens can recover the ID but not the credential. Replace the token rather than assuming creation failed.

Automation should store create responses directly in a protected secret-handling workflow, not print them in build logs. Keep API credentials separate from the ingest credential supplied to collectors.