Users

A user is one identified person in your organization. Identity › Audience › Users lists them all. There is nothing to create on this screen: it reports the people your sites already know.

When a user row is created

Your organization has one user row per person, across every site, and each email address belongs to at most one user. EdgeKit creates the row the first time it has an email address for the person:

• they register or sign in on one of your sites;
• they buy an offer at checkout;
• they join a newsletter list with their email address;
• they sign in through your identity provider, if your sites use one;
• EdgeKit runs a one-off import of your synced billing accounts, and an account’s email address belongs to no user yet. The address starts unverified, and the user gets no grant;
• staff seat them in a user organization (see User organizations).

A sync from your billing provider creates no user. It stores the billing account and keeps whatever user the account is already linked to. A billing account no checkout linked stays without a user until EdgeKit runs that import.

Anonymous browsing never creates a user. Until someone is identified, EdgeKit keeps their anonymous state for their browser as a device.

The Users screen

One row per user, newest first:

• User: the name, or a dash when there is none, and the email address. Either opens the user’s screen.
• Status: Verified (the user confirmed their address), Unverified (registered, never confirmed), or Erased (see Erased users).
• Sites: the sites the user is attached to. A user is attached to a site when they arrive there, for example by registering, buying or joining a list on it. No site yet means they are attached to none, which is normal for someone seated in a user organization by staff.
• Organizations: the user organizations the user is a member of, each with the user’s role in it.
• Grants: how many live grants the user holds directly. A grant held by one of their user organizations is counted on that organization, not here.
• Registered: when the user row was created.

Search matches any part of the name or the email address. Filter by Status, Site, Arrived by (how the user arrived at a site; the menu lists only the values your data holds, such as Signup for a registration or a checkout, newsletter, or external_mint and external_adopt for a sign-in through your identity provider), Membership (holds a seat in a user organization, or individual) and Grants (holding a live grant, or none). Sort by registration date, name or grant count. A page shows 50 rows by default.

What a site attachment means

Attachment records where a user has been seen. It is not a boundary: the user is the same row on every site, and a grant reaches every site its product covers whether or not the user is attached there. A user who registered on one site and later reads on another stays one user.

A user’s screen

Open a user from the list. The screen has seven sections.

Section	What it shows	Can staff change it
User	First name and last name, and when the user registered	Yes, Owner and Admin
Email	The current address, and a form to correct it	Yes, Owner and Admin
Credentials	Stored sign-in credentials linked to the account, such as a social sign-in	No
Organizations	The user organizations the user belongs to, with their role in each	No, see below
Grants	The grants the user holds directly, with state, start and expiry	No
Newsletters	Where the user stands on each newsletter list	No
Profile	The profile document EdgeKit derived for the user, one per site	No

The Grants section shows the 50 most recent grants and says how many there are in total when there are more. Each grant opens its own screen; see Grants. Roles and seats are changed from the user organization’s screen; see User organizations. A profile document is replaced whole every time EdgeKit rebuilds it; see Profile. No profile document means nothing has built one for this user yet, which is not the same as an empty profile.

Credentials lists stored credentials only. A user who signs in with a code or link sent to their address has none, and that is normal. Unlinking a social sign-in is the user’s own action; staff cannot do it.

Correct a user’s name

1. Open the user from Identity › Audience › Users.
2. In User, change First name or Last name. Each takes up to 200 characters.
3. Save.

The display name is rebuilt from the first and last name. The change applies at once. The user’s traits are not editable here.

Correct a user’s email address

Use this to fix an address, not to make a change the user would make themselves.

1. Open the user from Identity › Audience › Users.
2. In Email, enter the New email.
3. Save.

What happens:

• The user is signed out everywhere: every sign-in session they hold is revoked at once. A browser that already holds their cookies can lag behind; see How quickly an ended session stops working.
• The new address is stored unverified. Nothing proves it belongs to the user, so EdgeKit does not mark it verified.
• If another user already has the address, the change is refused with That address is already in use..

An erased user has no Email section.

Erased users

Erasing a user anonymises the row in place. The user id, their site attachments and their grants stay. The name, the email address and the traits the user wrote themselves are removed, the address becomes a placeholder, and every sign-in session is revoked. An erased user stays in the list, marked Erased, and still counts in its totals.

The console cannot erase a user. Your server erases one by naming the user’s subject at your identity provider, with any of your API keys. A user with no link to your identity provider, such as one who has only ever signed in on your site with an emailed code, has no subject to name and cannot be erased this way.

curl -X POST https://your-tenant-host/v1/id/upstream/erase \
  -H 'Authorization: Bearer <api-key>' \
  -H 'x-edgekit-site-id: site_example' \
  -H 'content-type: application/json' \
  -d '{"subject": "user-6475b8"}'

const response = await fetch('https://your-tenant-host/v1/id/upstream/erase', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.EDGEKIT_API_KEY}`,
    'x-edgekit-site-id': 'site_example',
    'content-type': 'application/json',
  },
  body: JSON.stringify({ subject: 'user-6475b8' }),
});

const { userId, applied } = await response.json();

• 200 with applied: true erased the user. applied: false means the user was already erased; the request is safe to retry.
• 404 not_found, No user is bound to that subject.: no user is linked to that subject.
• 503 service_unavailable, This tenant has no identity provider.: your organization has no identity provider set up, so there is no subject to name.

The key’s site pin is checked, but the erasure is not limited to that site: a key pinned to any of your sites can erase any of your users. See the API reference.