Authentication

Authenticating with the Trigger.dev management API

There are two methods of authenticating with the management API: using a secret key associated with a specific environment in a project (secretKey), or using a personal access token (personalAccessToken). Both methods should only be used in a backend server, as they provide full access to the project.

There is a separate authentication strategy when making requests from your frontend application. See the Realtime guide for more information. This guide is for backend usage only.

Certain API functions work with both authentication methods, but require different arguments depending on the method used. For example, the runs.list function can be called using either a secretKey or a personalAccessToken, but the projectRef argument is required when using a personalAccessToken:

import { configure, runs } from "@trigger.dev/sdk";

// Using secretKey authentication
configure({
  secretKey: process.env["TRIGGER_SECRET_KEY"], // starts with tr_dev_, tr_prod_, or tr_preview_
});

function secretKeyExample() {
  return runs.list({
    limit: 10,
    status: ["COMPLETED"],
  });
}

// Using personalAccessToken authentication
configure({
  secretKey: process.env["TRIGGER_ACCESS_TOKEN"], // starts with tr_pat_
});

function personalAccessTokenExample() {
  // Notice the projectRef argument is required when using a personalAccessToken
  return runs.list("prof_1234", {
    limit: 10,
    status: ["COMPLETED"],
    projectRef: "tr_proj_1234567890",
  });
}

View endpoint support

Consult the following table to see which endpoints support each authentication method.

Endpoint	Secret key	Personal Access Token
task.trigger	✅
task.batchTrigger	✅
runs.list	✅	✅
runs.retrieve	✅
runs.cancel	✅
runs.replay	✅
envvars.list	✅	✅
envvars.retrieve	✅	✅
envvars.upload	✅	✅
envvars.create	✅	✅
envvars.update	✅	✅
envvars.del	✅	✅
schedules.list	✅
schedules.create	✅
schedules.retrieve	✅
schedules.update	✅
schedules.activate	✅
schedules.deactivate	✅
schedules.del	✅

Secret key

Secret key authentication scopes the API access to a specific environment in a project, and works with certain endpoints. You can read our API Keys guide for more information.

Personal Access Token (PAT)

A PAT is a token associated with a specific user, and gives access to all the orgs, projects, and environments that the user has access to. You can identify a PAT by the tr_pat_ prefix. Because a PAT does not scope access to a specific environment, you must provide the projectRef argument when using a PAT (and sometimes the environment as well).

For example, when uploading environment variables using a PAT, you must provide the projectRef and environment arguments:

import { configure, envvars } from "@trigger.dev/sdk";

configure({
  secretKey: process.env["TRIGGER_ACCESS_TOKEN"], // starts with tr_pat_
});

await envvars.upload("proj_1234", "dev", {
  variables: {
    MY_ENV_VAR: "MY_ENV_VAR_VALUE",
  },
  override: true,
});

Preview branch targeting

When working with preview branches, you may need to target a specific branch when making API calls. This is particularly useful for managing environment variables or other resources that are scoped to individual preview branches.

SDK

To target a specific preview branch, include the previewBranch option in your SDK configuration:

import { configure, envvars } from "@trigger.dev/sdk";

configure({
  secretKey: process.env["TRIGGER_ACCESS_TOKEN"], // starts with tr_pat_
  previewBranch: "feature-xyz",
});

await envvars.update("proj_1234", "preview", "DATABASE_URL", {
  value: "your_preview_database_url",
});

cURL

To target a specific preview branch, include the x-trigger-branch header in your API requests with the branch name as the value:

curl --request PUT \
  --url https://api.trigger.dev/api/v1/projects/{projectRef}/envvars/preview/DATABASE_URL \
  --header 'Authorization: Bearer <token>' \
  --header 'x-trigger-branch: feature-xyz' \
  --header 'Content-Type: application/json' \
  --data '{
    "value": "your_preview_database_url"
  }'

This will set the DATABASE_URL environment variable specifically for the feature-xyz preview branch.

The x-trigger-branch header is only relevant when working with the preview environment ({env} parameter set to preview). It has no effect when working with dev, staging, or prod environments.

SDK usage with preview branches

When using the SDK to manage preview branch environment variables, the branch targeting is handled automatically when you’re running in a preview environment with the TRIGGER_PREVIEW_BRANCH environment variable set. However, you can also specify the branch explicitly:

import { configure, envvars } from "@trigger.dev/sdk";

configure({
  secretKey: process.env["TRIGGER_ACCESS_TOKEN"], // starts with tr_pat_
  previewBranch: "feature-xyz", // Optional: specify the branch
});

await envvars.update("proj_1234", "preview", "DATABASE_URL", {
  value: "your_preview_database_url",
});

Talking to multiple projects, environments, or branches

A long-running process often needs to talk to more than one Trigger.dev target. There are two patterns:

• new TriggerClient({...}) — an explicit instance that owns its own auth, baseURL, and preview branch. Use this when the targets are long-lived (a dashboard that watches prod + preview, a worker that triggers across multiple projects, etc.). Each instance is fully isolated and concurrent calls don’t interfere. See Multiple SDK clients for details.
• auth.withAuth(config, fn) — runs a single callback under a temporary config override, then restores. Use this for short, sequential overrides (e.g. one batch under a different token) where keeping a dedicated client around is overkill.

import { auth, runs } from "@trigger.dev/sdk";

const projectBRuns = await auth.withAuth(
  { accessToken: process.env.TRIGGER_SECRET_KEY_PROJECT_B },
  async () => {
    return runs.list({ limit: 10 });
  },
);

Any SDK call inside the callback uses the overridden config. Calls outside the callback continue to use whatever was set by configure (or picked up from TRIGGER_SECRET_KEY).

The override is scoped via AsyncLocalStorage, so concurrent auth.withAuth calls (including overlapping calls inside Promise.all with different tokens) do not interfere. Nested calls compose — an inner auth.withAuth({ accessToken }) inside an outer auth.withAuth({ baseURL }) runs with both fields applied.