CORS & Key Types

HempData issues two keys per account, and the CORS policy follows the key types. If a fetch from your web app fails with an opaque CORS error, this page is why.

The two key types

Key	Prefix	Where it lives	What it's for
Secret key	`hda_live_sk_...`	Server-side only — env var, never shipped to a browser	All API calls: compliance, regulations, states, answer, webhooks
Publishable key	`hda_live_pk_...`	Client-side is fine	The embeddable widget (`POST /v1/widget/check`)

A secret key in browser JavaScript is a leaked key. Rotate it from the dashboard if that happens.

What browsers may call cross-origin

Only the surfaces designed to be embedded on third-party sites return Access-Control-Allow-Origin for arbitrary origins:

POST /v1/widget/check — the publishable-key widget check
GET /v1/verified/{brand_id} (and its badge.svg) — the public verified badge

Everything else — every secret-key endpoint — is server-side only: no Access-Control-Allow-Origin is returned for third-party origins, so a browser call from your domain will fail even with a valid key. That is intentional, not an outage. Call the API from your backend and pass results to your frontend.

Calling pattern

browser ──(your session)──▶ your server ──(Authorization: Bearer hda_live_sk_...)──▶ api.hempdata.io

For client-side compliance badges, use the widget with your publishable key instead of calling the API directly — see the embed guide.

Need a first-party exception?

hempdata.io properties and local development (localhost, preview deploys) are already allowed. If you believe your integration genuinely needs another origin allowed, email [email protected] with the origin and the use case.