Metrc API Keys: How Authentication Works

The two keys behind a Metrc API request

Metrc’s official API is designed for third-party software integrators. Each request carries two credentials that answer two different questions: which software is calling, and which Metrc user it is acting for.

The vendor (integrator) API key

The vendor key, sometimes called the software or integrator key, identifies the application making the request. Metrc issues it to a software company that has gone through its integrator onboarding, and access is generally arranged state by state. In-house development teams often discover this requirement only after they have started planning an integration.

The user API key

The user key identifies the person the software acts for. A licensed Metrc user generates it from inside their Metrc account, and requests made with it are limited to the facilities and permissions that user already has. If that user’s access changes, or they leave the company, the key has to be replaced.

How the keys travel with each request

Both keys are sent with every request, typically as HTTP Basic authentication: the vendor key in the username position and the user key in the password position. Each Metrc state also runs its own API host, so a multi-state integration maintains separate configuration for every state it touches.

Where the key model creates friction

None of this is unusual for a regulated system, but it adds overhead before an in-house team ships anything useful:

• Access depends on approval. Without a vendor key there is no Metrc API access, no matter how many licenses the company holds.
• Keys multiply. Every state and every user who needs automated access adds credentials to issue, store, and rotate.
• Behavior varies by state. Metrc behaves differently in each state it operates in, so an integration built for one state may need changes before it works in another.

Authenticating to the T3 API

The T3 API takes a different approach. It does not use Metrc API keys and is not built on Metrc’s third-party API. Instead, the developer-friendly T3 API reaches the same data you can already see on metrc.com using your own Metrc login, and it accepts two authentication formats. Every endpoint that requires authentication accepts either one.

Option 1: A single T3 secret key

Generate a secret key once by sending your Metrc username, password, and hostname (the site you log in to, such as ca.metrc.com) to POST /v2/auth/secretkey, or use the secret key generation tool. Colorado users also supply their Metrc email, and Michigan users supply their one-time password seed. After that, every request carries the key:

curl "https://api.trackandtrace.tools/v2/packages/active?licenseNumber=LIC-000123" \
  -H "X-T3-API-Key: $T3_API_KEY"

The X-T3-API-Key header is the preferred form. The same key can be passed as a secretKey query parameter, which is what makes spreadsheet formulas possible, but query strings tend to end up in logs and browser history. When both are present, the header wins.

Option 2: Credential authentication with a bearer token

For interactive work, exchange your Metrc credentials at POST /v2/auth/credentials for a short-lived JWT, then send it as Authorization: Bearer <jwt>. Your credentials are used once to log in to Metrc and are not stored. When the token expires, you authenticate again.

import requests

auth = requests.post(
    "https://api.trackandtrace.tools/v2/auth/credentials",
    json={
        "hostname": "ca.metrc.com",
        "username": "your-metrc-username",
        "password": "your-metrc-password",
    },
    timeout=60,
)
auth.raise_for_status()
token = auth.json()["accessToken"]

licenses = requests.get(
    "https://api.trackandtrace.tools/v2/licenses",
    headers={"Authorization": f"Bearer {token}"},
    timeout=60,
)
print(licenses.json())  # [{"licenseName": "...", "licenseNumber": "..."}]

Choosing between them

Keeping a secret key healthy

• Regenerate after credential changes. A secret key embeds a snapshot of the credentials used to create it. If your Metrc password, username, Colorado email, or Michigan OTP seed changes, the key stops working and must be replaced.
• Audit and revoke. GET /v2/auth/secretkey lists your active keys along with their lastUsedAt activity, and DELETE /v2/auth/secretkey/{id} revokes one immediately, with no grace period.
• Treat it like a password. Keep it in an environment variable or secrets manager, never in source control or a shared spreadsheet.
• Stay inside rate limits. The default limit is 600 requests per minute per user, and some routes are lower. A key shares one rate-limit bucket whether you send it as a header or a query parameter.

Metrc API keys vs. the T3 API at a glance

Next steps

With a secret key in hand, the fastest way to see results is to make a real request. The Python guide walks through fetching and paginating active packages, and the documentation map shows what else you can reach. For a broader look at what teams build, see the T3 API feature overview, or read the full authentication reference on the T3 wiki.