Skip to content

EdgeKit ID

EdgeKit ID signs users in to your sites and keeps one record for each person. There are no passwords: a user proves they hold an email address with a one-time code or a sign-in link, or signs in with Google. Your pages draw the sign-in screens, and EdgeKit answers the requests behind them on your own domain.

Your organization has one user per person, whichever of your sites they sign in on, and no two users share an email address. The same person signing in on two of your sites is one user with one set of grants. Browsing without signing in never creates a user: until then EdgeKit keeps anonymous state for the browser as a device. See Users for when a user is created and what the console shows about them.

Your users live in your organization’s own database and its own sign-in instance. No other organization shares either.

Your pages call EdgeKit ID on your own domain, under /edgekit/v1/id/. The same routes answer on your tenant host under /v1/id/. Both paths behave the same; a page uses the one on its own domain, so the sign-in cookie is first-party. See Mount /edgekit/ on your domain.

Every request names its site in the x-edgekit-site-id header, and a browser request must come from one of the site’s allowed origins. Two routes need no credential and answer any origin: GET /v1/id/config and GET /v1/id/traits.

The browser client’s id methods wrap these routes; see createClient. Every route is in the client API reference.

Method How the user proves who they are Creates a user for a new address
Email code Types a 6-digit code emailed to them. The code lasts 5 minutes. Yes, and can record traits
Magic link Opens a link emailed to them. The link lasts 5 minutes. Yes, with no traits
Google Signs in with their Google account, through your Google client. Yes, with no traits

EdgeKit sets which methods each site offers. Your page reads them from GET /v1/id/config, and you can see them in the Configuration section of each site’s screen in Delivery › Delivery › Sites. See Sign users in. A magic link cannot be completed today: the emailed link opens an address where EdgeKit answers 404. See Sign in with a magic link.

A successful sign-in sets a session cookie on the host the request reached. The session lasts 30 days and is extended while the user keeps coming back. Native apps get the same session as a token instead of a cookie. See Sessions and sign-out.

Each site has an id mode, which decides which authority a request is read under:

  • edgekit_only, the default: EdgeKit signs users in and holds their sessions.
  • external_only: your existing login stays the authority. EdgeKit verifies its credential on every request and never creates a session of its own. An EdgeKit session cookie is ignored at such a site.
  • dual: EdgeKit trades your login’s credential for an EdgeKit session the first time it sees it.

The id mode is how an organization moves from an existing login to EdgeKit ID without signing anyone out. See Choose who signs users in, Connect your existing login and Move users off your existing login.

A signed-in user can read and change their own name and the traits they answer, change their email address, and, as an owner or admin of a user organization, manage its members. See Let users manage their account, Ask users about themselves and Let members run their user organization.

  • Identity › Audience › Traits declares the questions you ask users. See Ask users about themselves.
  • Identity › Audience › Users lists every user. See Users.
  • Identity › Audience › Organizations lists user organizations. See User organizations.
  • Identity › Audience › Observability records sign-ins, sign-outs, new users and refusals. See Observability.

Questions are answered in the EdgeKit ID FAQ and Troubleshooting.