> ## Documentation Index
> Fetch the complete documentation index at: https://docs.allgoodhq.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Allowed origins
> The list of websites allGood will accept form submissions and tracking events from.
The allowed origins list names the websites that may capture into your account. It's one list for the whole account, and it governs both form submissions and tracking events.
It is also the single most common cause of "why is nothing being captured?", so it's worth ten careful minutes.
**Where:** Settings → Web Edge, the **Allowed origins** card.
Just adding origins for a marketer, not building against them? See [Set up Web Edge Sessions for your site](/mk/settings/web-edge/sessions-setup) for the settings-only walkthrough.
## What an origin looks like
An origin is **scheme + host + optional port**, and nothing else.
| Example | Valid? | Why |
| ------------------------------- | ------ | --------------------------------------------------- |
| `https://www.brand.com` | Yes | |
| `http://localhost:3000` | Yes | A port is fine |
| `https://brand.com` | Yes | But it is a *different* origin from `www.brand.com` |
| `https://www.brand.com/` | No | Trailing slash |
| `https://www.brand.com/landing` | No | Paths aren't part of an origin |
| `https://*.brand.com` | No | No wildcards, ever |
| `www.brand.com` | No | The scheme is required |
Matching is exact. There is no subdomain inheritance: `https://www.brand.com` does not cover `https://blog.brand.com`, `https://shop.brand.com`, or the bare `https://brand.com`. Add every one you actually publish from.
Coming from Marketo, this is stricter than the Forms 2.0 domain whitelist. It's a real browser-level check enforced at the network edge, not a soft one.
## A typical list
```
https://www.brand.com production site
https://brand.com the apex, if it serves pages rather than redirecting
https://blog.brand.com if the blog is a separate host
https://staging.brand.com staging, while you're testing
http://localhost:3000 local development — remove before go-live
```
## Adding one
Type the origin into **Add an origin** and click **Add**. A **Save** button appears in the card header; nothing is in force until you save *and* the status chip reads **Live at the edge**.
Between saving and the chip turning green, the old list is still the one being enforced. This is the explanation for almost every "I added the origin and it still doesn't work" report — wait for the chip. See [Saved vs live](/mk/developer/web-edge/edge-sync).
Every save is recorded in the change history at the bottom of the screen, with who changed what and when.
## What happens when an origin is missing
The browser's own permission check is refused outright, with no explanation attached. From the page, that looks like a network error rather than a readable rejection — there's no message in the response saying what went wrong.
Because that's so opaque, the allGood script does two things instead:
1. On load it asks allGood whether the page's origin is authorised, using an endpoint that deliberately answers every origin so the answer is always readable.
2. If it isn't, it writes a warning to the browser console naming the exact origin and what to do about it.
**So check the browser console first.** That message is the definitive answer.
## The same-origin exception
A page allGood itself serves — a landing page on `mk.brand.com` — posts back to `mk.brand.com`. That's the same origin, and it's always accepted whether or not you've listed it.
This is why an account with an empty list appears to work perfectly for hosted landing pages, right up until someone puts a form on the real marketing site.
## Bot-check coverage
If [bot protection](/mk/developer/web-edge/bot-protection) is on, each origin also shows whether the bot-check widget covers that hostname.
| Chip | Means |
| ------------------------- | --------------------------------------------------------------------------------------------- |
| **bot check covered** | The widget issues tokens on this hostname |
| **bot check not covered** | It doesn't — and a form here that requires a bot check will have **every submission refused** |
Coverage is read live from the widget rather than stored, so it can't be out of date. The fix for an uncovered hostname is to press **Sync** on this screen.
## Where the list is stored
The card sits on the Web Edge screen because both forms and tracking depend on it, but the values are stored with your form processing settings. That's why the change history for origins appears on the [Form processing](/mk/developer/web-edge/form-processing) screen, and why the script's console warning mentions that screen. Both are editing one list.
There is no separate permission for these settings today — any user of the account can edit the origin list. Treat it as an admin screen by convention.
## Next
→ [Bot protection](/mk/developer/web-edge/bot-protection)