Sites
A site is one website your organization runs. Each site has one domain, and no two of your sites share a domain. Every event and every decision is for one site, and a product’s coverage names the sites it covers, so nothing else in EdgeKit works until your organization has a site.
Your organization’s first site is created when EdgeKit sets up your organization. The console has no action that adds a site.
The site id
Section titled “The site id”Every site has an id such as site_daily_example. It is made from the site’s name when the site is created: site_,
then the name in lower case with every run of other characters replaced by _ and any _ at either end dropped.
The id never changes afterwards, even if you rename the site or move it to another domain, so code and data written
against it keep working.
To find a site’s id, open the site from Delivery › Delivery › Sites. The id is the last part of the
page address, for example /delivery/sites/site_daily_example.
How a request selects a site
Section titled “How a request selects a site”Requests to the client API and decide name their site with the x-edgekit-site-id header. The header selects a
site; it does not authenticate the caller. It can only select one of your own organization’s sites, because each
organization’s sites live in that organization’s own database.
A site resolves only when its status is active and it is in your newest deployment. A request for a site that is
unknown, disabled or not yet deployed gets 404 not_found with the message Unknown site.. A request with no header
gets 400 bad_request. See Select a site on a request.
Events are different: the collector never refuses an event because of its site. Each event is filed under the site
id the tracker sent, or under _unresolved when it sent none.
What a site controls
Section titled “What a site controls”| Setting | What it changes at runtime |
|---|---|
| Status | active serves requests. Anything else answers as an unknown site. |
| Domain | The hostname the site serves on. |
| Allowed origins | The browser origins that may call EdgeKit for this site. Empty refuses every browser request that needs an allowed origin. |
| Redirect origins | The origins an absolute redirect target, such as a magic-link callback, may point at. |
| API keys | Server-to-server credentials, each pinned to this one site. |
Every setting is described in Site settings.
The Sites screen
Section titled “The Sites screen”Delivery › Delivery › Sites shows one row per site, with its saved settings, which reach requests after the next deploy:
- Site: the name, which opens the site, and its domain below it.
- Status:
active, ordisabledfor a site that answers as unknown. - Origins: how many browser origins the site allows, or denies all when it allows none. A site that is active but denies all origins refuses every browser request that needs an allowed origin, so this is the first column to check when a site answers nothing.
- Products: how many products cover the site. A site that no product covers is a site nobody can buy access to.
Filter by status, origins or products, search by name or domain, and sort by site name or product count.
Who can change a site
Section titled “Who can change a site”Anyone in your organization can view sites. Changing a site’s settings or API keys, or the transactional mail settings shown on each site’s screen under Delivery › Delivery › Sites, needs the site write permission, which the Owner and Admin roles hold.