Allowed origins

By default, a brand-new honeycomb accepts widget reports from any origin (Access-Control-Allow-Origin: * on the public POST /api/v1/bugs endpoint). This is the right default for a widget designed to drop into anyone's frontend without configuration.

If you want to lock down ingest to a specific list of sites, set the Allowed origins in /{hive}/honeycombs/{id}/settings.

How it works

When the list is empty, any origin is accepted (the default).

When the list has entries:

• The browser's preflight OPTIONS request must come from one of the listed origins.
• A request from a non-listed origin gets a CORS rejection — the browser blocks the actual POST and the widget shows a generic error.

Origins are matched exactly including scheme + host + port: https://example.com does not match https://www.example.com or http://example.com. List each variant you serve from.

Format

One origin per line, no path:

https://example.com
https://www.example.com
https://staging.example.com

Trailing slashes are stripped. Wildcards aren't supported — there's no *.example.com.

When to use it

• Public site that should only accept reports from itself. Lock to your domain so a leaked key on someone else's site can't accidentally pollute your inbox.
• Multi-tenant SaaS where each customer embeds the widget on their own subdomain. Add each subdomain as you onboard them.

When NOT to use it

• Development. Your localhost:3000 would need to be in the list, and you'd forget to remove it before going live. Either keep it permissive in dev or mint a separate honeycomb for dev with *.
• A widget meant to be embedded in third-party sites you don't control. That's the default contract — leave the list empty.

Doesn't this conflict with the publishable key model?

It complements it. The API key (sk_…) is publishable and can't be hidden. Allowed origins is a soft layer: a script running in your browser can't trivially fake an origin, so a leaked key is less useful when origins are locked. It's not a substitute for revoking a leaked key — just a low-friction first defense.

A determined attacker running their own fetch from a server-side script will still be able to POST (no CORS in server-to-server). The 60/min rate limit + the per-honeycomb 100/month free cap are what stop that.