Grants

A grant is a stored fact that someone has access to a product: what other platforms call an entitlement. It names one product and exactly one holder, either a user or a user organization, never both and never neither. A member of a user organization reaches the organization’s grants through their seat (see User organizations).

A grant carries no price, currency or billing interval. What was paid lives with your billing records, not on the grant.

Identity › Audience › Grants lists every grant. It is read-only.

How a grant is created

Nothing in the console creates a grant. A grant is created when a user buys an offer at checkout, and the user who bought it holds it.

A grant never waits for a user. EdgeKit creates the user first, then writes the grant against them. There is no pending grant for a person EdgeKit has not met yet. A user needs an email address, so EdgeKit cannot write a grant for someone it has no email address for.

After that, your billing provider’s state moves the grant: a renewal extends it, a failed payment or a pause can suspend it, and a payment that clears or a pause that ends resumes it. When your billing provider ends the purchase before the paid period is over, or while the grant is suspended, the grant is revoked. A cancellation that takes effect at the end of the paid period is not a grant change: access runs to that end and the grant expires. Each change, and the two access policy settings for failed payments and pauses, are described in How access follows your billing provider.

Grant states

A grant’s stored status is active, suspended or revoked. Expiry is a date, not a status, so the console and the API fold the two into four states:

State	Meaning
live	Access now: active, and the expiry is empty or in the future.
expired	The term ran out. The stored status still says active.
suspended	No access now, and the term end is unchanged. Recoverable: the grant can go back to active.
revoked	Access withdrawn: ended early, or ended while suspended. Final: restoring access takes a new grant.

A suspended or revoked grant says why in its status reason: dunning, paused, refund, chargeback or billing_provider_terminated.

The Grants screen

One row per grant, newest start first:

• Holder: the user’s name and email address, or the user organization’s name and slug. An erased user is marked erased.
• Product: what the grant gives access to, and the site it is pinned to, or everything the product covers.
• Origin: who created it, such as your billing provider; why, such as purchase; and the offer code, when there is one.
• State, with the status reason and any quotas the grant carries.
• Starts and Expires (open-ended when there is no expiry).

Search matches the holder’s name or email address, a user organization’s name or slug, the product name, the offer code and the grant’s external reference. Filter by State, Source (what created the grant) and Site. A grant matches a site when it is pinned to that site, or when it is unpinned and its product covers the site. Sort by start, expiry, product or holder.

A grant’s screen

Open a grant from the list. Every section is read-only.

• The fact: the holder, the product, the offer it was bought through (None recorded when there is none), the site and the resource. A grant with no site covers whatever its product covers now, and one with no resource covers everything the product covers.
• Term and origin: when it starts and expires, when its trial ended (Never trialled when it had none), what created it and why, its stored status, and the reference at its source, for example your billing provider’s id.
• Quotas: how many of a capability the grant carries, in the capability’s own unit. No row means no limit. EdgeKit enforces one quota itself, membership.seats, on a user organization’s grant. Every other quota is carried for your own code to enforce.
• Replaces: the grants this one replaced in an upgrade. Each stopped when this one started.
• History: every transition, newest first: granted, extended, suspended, resumed or revoked, with who made it and the reference. The history is append-only. A correction is another row, never an edit.

The screen also shows Revoke, which cannot be used from the console today.

Your site reads a user’s grants

GET /v1/grants answers every grant the signed-in user holds that reaches the selected site, newest term first: their own and the grants of every user organization they hold a seat in. Expired, suspended and revoked grants are included, each with its state, so filter on state for the live ones. A grant from a user organization names it in organization, so you can show the user that their employer pays, not them.

The request needs the user’s EdgeKit sign-in session and x-edgekit-site-id. The browser client’s grants method sends both. See GrantsResponseBody and the API reference.

Grants and access from your identity provider

At a site whose sign-in runs only through your identity provider, the access your identity provider asserts about a user arrives with each request as external.* facts. EdgeKit never writes that access as a grant: it does not appear on this screen, GET /v1/grants answers 404 at such a site, and your rules decide whether to combine external.* with grants. See EdgeKit ID.