docs: document additional environment API keys - #4406
Conversation
|
WalkthroughUpdates API key documentation with root and additional keys, environment scoping, SDK and self-hosted configuration, key creation, access presets, expiration, revocation, public tokens, branch targeting, root-key regeneration, and security guidance. Clarifies that numeric public-token expiration values use Unix timestamps in seconds and cannot exceed 30 days. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
11216bf to
94e2d96
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
| ## Target Preview and Development branches | ||
|
|
||
| Preview and named Development branches use their parent environment's keys. Select the branch by setting `TRIGGER_PREVIEW_BRANCH` alongside the environment key: | ||
|
|
||
| ```bash .env | ||
| TRIGGER_SECRET_KEY="tr_preview_sk_…" | ||
| TRIGGER_PREVIEW_BRANCH="feature/new-checkout" | ||
| ``` | ||
|
|
||
| The SDK sends the branch automatically. When calling the API directly, send the same value in the `x-trigger-branch` header. |
There was a problem hiding this comment.
🔍 previewBranch configure option no longer documented
The old page documented previewBranch as a configure() option; the rewrite only documents the TRIGGER_PREVIEW_BRANCH env var. The SDK still supports the in-code option (packages/core/src/v3/apiClientManager/index.ts:76-84 reads config?.previewBranch first), so readers who configure the SDK programmatically now have no documented way to target a branch.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 0845cbfc-7987-415d-ac43-868b830d942e
📒 Files selected for processing (2)
docs/apikeys.mdxdocs/realtime/auth.mdx
🚧 Files skipped from review as they are similar to previous changes (1)
- docs/realtime/auth.mdx
📜 Review details
🧰 Additional context used
📓 Path-based instructions (1)
docs/**/*.mdx
📄 CodeRabbit inference engine (docs/CLAUDE.md)
docs/**/*.mdx: MDX documentation pages must include frontmatter with title (required), description (required), and sidebarTitle (optional) in YAML format
Use Mintlify components for structured content: , , , , , , /, /
Always import from@trigger.dev/sdkin code examples (never from@trigger.dev/sdk/v3)
Code examples must be complete and runnable where possible
Use language tags in code fences:typescript,bash,jsonDocumentation in
docs/uses MDX conventions defined by the documentation guidance.
Files:
docs/apikeys.mdx
🧠 Learnings (2)
📚 Learning: 2026-03-10T12:44:14.176Z
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3200
File: docs/config/config-file.mdx:353-368
Timestamp: 2026-03-10T12:44:14.176Z
Learning: In the trigger.dev repo, docs PRs are often companions to implementation PRs. When reviewing docs PRs (MDX files under docs/), check the PR description for any companion/related PR references and verify that the documented features exist in those companion PRs before flagging missing implementations. This ensures docs stay in sync with code changes across related PRs.
Applied to files:
docs/apikeys.mdx
📚 Learning: 2026-04-30T20:30:29.458Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3226
File: docs/ai-chat/quick-start.mdx:13-13
Timestamp: 2026-04-30T20:30:29.458Z
Learning: In this repo’s documentation MDX files (`docs/**/*.mdx`), use `ts` and `tsx` (not `typescript`) as the code-fence language tags for TypeScript/TSX snippets. Do not flag `ts`/`tsx` code-fence language tags as incorrect in any docs MDX file, since this is the site-wide Mintlify-compatible convention.
Applied to files:
docs/apikeys.mdx
🪛 LanguageTool
docs/apikeys.mdx
[style] ~119-~119: Consider a more concise word here.
Context: ...uth) using auth.createPublicToken(). In order to do so with the newer non-root keys, you...
(IN_ORDER_TO_PREMIUM)
🔇 Additional comments (2)
docs/apikeys.mdx (2)
106-114: LGTM!
120-128: LGTM!
|
|
||
| ## Create public access tokens | ||
|
|
||
| API keys can be used create scoped [Public Access Tokens](/realtime/auth) using `auth.createPublicToken()`. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Correct the sentence grammar.
Add to before create. The current sentence is incomplete.
Proposed fix
-API keys can be used create scoped [Public Access Tokens](/realtime/auth) using `auth.createPublicToken()`.
+API keys can be used to create scoped [Public Access Tokens](/realtime/auth) using `auth.createPublicToken()`.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| API keys can be used create scoped [Public Access Tokens](/realtime/auth) using `auth.createPublicToken()`. | |
| API keys can be used to create scoped [Public Access Tokens](/realtime/auth) using `auth.createPublicToken()`. |
Summary
Expands the API key guide to cover root and additional environment keys. It explains how to configure the SDK, create keys with limited access, manage expiration and revocation, rotate the root key, and use keys with public tokens and branch environments.
Design
The guide describes access presets at the product level without exposing authorization internals. It also documents copy-once secrets, immutable access policies, task-selection limits, public-token lifetimes, streamed-batch behavior, and the supported self-hosted configuration.