Treasure Data · Authentication Profile
Treasure Data Authentication
Authentication
Treasure Data secures its APIs with apiKey, http, and openIdConnect across 8 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the authorization_code and refresh_token flow(s).
Customer Data PlatformCDPBig DataData WarehouseHivePrestoEnterpriseArtificial IntelligenceMarketingAnalytics
Methods: apiKey, http, openIdConnect
Schemes: 8
OAuth flows: authorization_code, refresh_token
API key in: header
Security Schemes
ApiKeyAuth http
scheme: TD1
TdApikeyAuth apiKey
· in: header (Authorization)
apiKey apiKey
· in: header (Authorization)
td1 http
scheme: bearer
wp13n apiKey
· in: header (WP13n-Token)
XTDWriteKey apiKey
· in: header (X-TD-Write-Key)
TD1Authorization apiKey
· in: header (Authorization)
TDAuth apiKey
· in: header (Authorization)
Source
Authentication Profile
generated: '2026-08-13'
method: searched
source: openapi/treasure-data-td-api-v3-openapi.yml, openapi/treasure-data-cdp-api-openapi.yml,
openapi/treasure-data-llm-api-openapi.yml, openapi/treasure-data-workflow-api-openapi.yml,
openapi/treasure-data-dwh-integration-api-openapi.yml, openapi/treasure-data-personalization-api-openapi.yml,
openapi/treasure-data-postback-api-v2-openapi.yml, openapi/treasure-data-postback-api-openapi.yml,
well-known/treasure-data-openid-configuration.json
docs: https://docs.treasure.ai/tools/cli-and-sdks/configuring-authentication-for-td-using-the-td-toolbelt
summary:
types:
- apiKey
- http
- openIdConnect
api_key_in:
- header
oauth2_flows:
- authorization_code
- refresh_token
primary_scheme: >-
Static TD API key sent as `Authorization: TD1 <account>/<40-hex>`. Every REST API in the estate uses
this one credential; the only variations are how the spec models it (apiKey-in-header vs http scheme
TD1) and the two write-key variants on the ingestion endpoints.
schemes:
- name: ApiKeyAuth
type: http
scheme: TD1
description: >-
Treasure Data API key. The header value is the literal `TD1` followed by a space and the key, which is
an account-number prefix, a slash, and a 40-character hexadecimal string.
sources:
- openapi/treasure-data-td-api-v3-openapi.yml
- openapi/treasure-data-llm-api-openapi.yml
- openapi/treasure-data-workflow-api-openapi.yml
- name: TdApikeyAuth
type: apiKey
in: header
parameter: Authorization
description: Same TD1 API key, modelled as an apiKey header scheme by the CDP API spec.
sources:
- openapi/treasure-data-cdp-api-openapi.yml
- name: apiKey
type: apiKey
in: header
parameter: Authorization
description: Same TD1 API key, modelled as an apiKey header scheme by the DWH Integration API spec.
sources:
- openapi/treasure-data-dwh-integration-api-openapi.yml
- name: td1
type: http
scheme: bearer
bearerFormat: TD1
description: |-
The API token is accepted as a `TD1` token. The TD API token
is an account number prefix, slash, and 40-character
hexadecimal string.
sources:
- openapi/treasure-data-personalization-api-openapi.yml
- name: wp13n
type: apiKey
in: header
parameter: WP13n-Token
description: >-
Web personalization routing token — account number, index number and a 32-character hexadecimal
string joined with slashes. Routes the request to the correct real-time engine.
sources:
- openapi/treasure-data-personalization-api-openapi.yml
- name: XTDWriteKey
type: apiKey
in: header
parameter: X-TD-Write-Key
description: Write-only ingestion key for the Postback API v2 event endpoint.
sources:
- openapi/treasure-data-postback-api-v2-openapi.yml
- name: TD1Authorization
type: apiKey
in: header
parameter: Authorization
description: Full TD1 API key accepted as an alternative to the write key on Postback API v2.
sources:
- openapi/treasure-data-postback-api-v2-openapi.yml
- name: TDAuth
type: apiKey
in: header
parameter: Authorization
description: >-
TD1 API key as modelled by the API-Evangelist-derived TD API split specs harvested before the
provider's own OpenAPI descriptions were located.
sources:
- openapi/treasure-data-bulk-import-api-openapi.yml
- openapi/treasure-data-bulk-loads-api-openapi.yml
- openapi/treasure-data-connectors-api-openapi.yml
- openapi/treasure-data-databases-api-openapi.yml
- openapi/treasure-data-jobs-api-openapi.yml
- openapi/treasure-data-sso-api-openapi.yml
- openapi/treasure-data-system-api-openapi.yml
- openapi/treasure-data-tables-api-openapi.yml
- openapi/treasure-data-users-api-openapi.yml
openid_connect:
discovery: https://api.treasuredata.com/.well-known/openid-configuration
file: well-known/treasure-data-openid-configuration.json
issuer: https://console.us01.treasuredata.com
authorization_endpoint: https://console.us01.treasuredata.com/oauth/authorize
token_endpoint: https://console.us01.treasuredata.com/oauth/token
revocation_endpoint: https://console.us01.treasuredata.com/oauth/revoke
introspection_endpoint: https://console.us01.treasuredata.com/oauth/introspect
userinfo_endpoint: https://console.us01.treasuredata.com/oauth/userinfo
jwks_uri: https://console.us01.treasuredata.com/oauth/discovery/keys
grant_types: [authorization_code, refresh_token]
response_types: [code]
pkce: [plain, S256]
token_endpoint_auth_methods: [client_secret_basic, client_secret_post]
id_token_signing_alg: [RS256]
claims: [iss, sub, aud, exp, iat, email, email_verified, td_account_id, administrator]
note: >-
Treasure Data runs an OAuth 2.0 / OpenID Connect authorization server on the console host and
advertises it from api.treasuredata.com. None of the eight published OpenAPI descriptions declares an
oauth2 securityScheme, so OAuth is not (yet) the documented path for calling the REST APIs — it backs
console sign-in and third-party app authorization. API calls use the static TD1 key.
sso:
supported: true
docs: https://docs.treasure.ai/apis/td-api/identity-federation
note: >-
SAML identity federation with per-user SSO enforcement is managed through /account/sso_setting and
the /user/*_sso endpoints. Multiple IdPs have been supported since the April 2023 release.
notes:
- >-
One credential, many spec shapes. The same TD1 key authenticates the TD API, CDP API, LLM API,
Workflow API and DWH Integration API; each spec models it differently, which is a real interoperability
friction for generated clients.
- >-
postback-api (v1) declares no securityScheme at all — the write key travels in the path/payload. v2
fixed this with the X-TD-Write-Key header.