AUTH GUIDE / Scenario guide
Purchase first, team next
Sell access before the first login
Ana buys Field Notes for her company, then brings her teammate Leo.
A worked example with fictional people and products.
What this gives you
The intended buyer becomes an account owner after onboarding.
Buying access does not create a universal staff role. Ana owns her company’s account inside this product.
Jump to the implementation recipe ↓See it happen
Follow Ana’s first day
- 01
Buy on the product site
Ana chooses the company’s plan.
What happens behind this step
The billing integration records a recipient-bound owner grant. Payment and login are separate steps.
- 02
Follow the welcome journey
She follows the welcome link and establishes or uses her identity.
What happens behind this step
Keep the originating product/client context. Do not assign the recipient’s grant to a different payer’s current session.
- 03
Enter the right company
Ana signs in and Field Notes opens her company’s account.
What happens behind this step
The owner grant is redeemed at login. Validate the resulting customer account and its entitlement.
- 04
Invite Leo
Ana sends Leo an invitation. Leo joins when he accepts.
What happens behind this step
Use the account-owner invitation flow. Pending invitation is not a seat; acceptance is by the intended recipient.
- 05
Work together
Both work in the same company, with the permissions the app gives them.
What happens behind this step
Owner and member share the selected account. Enforce app permissions for each operation and refuse access after seat revocation under the actual session policy.
The handover to your app
A person, a context, a clear boundary.
Ana enters as owner.
Use Ana’s company account to decide which records this request may reach. The product still checks what this person may do.
{
"sub": "ana-example-id",
"account": "selected-company-id",
"account_role": "owner"
}Build this scenario
The recipe for your developer or agent.
Start with a registered customer app and the policy below. Then connect the specific access path for this scenario.
1. Register the app
Choose your organization and environment, register the HTTPS callback, then configure the client ID and server secret.
Registration request and prerequisites →2. Apply this access policy
{
"surface": "customer",
"allowSelfRegistration": false,
"signupGrantsAccount": false,
"checkoutUrl": "https://www.example.com/pricing"
}Connect checkout to the intended recipient’s owner grant, preserve onboarding context and use accepted invitations for additional seats.
3. Connect hosted sign-in
The app starts login, auth handles the hosted screens, and the validated callback brings the person back to your product.
Complete .NET example →OIDC for other stacks →
4. Check the boundaries
Buying access does not create a universal staff role. Ana owns her company’s account inside this product.
Acceptance checks →Branding and direct return →
Ready-to-use implementation brief
Give this brief and this page’s URL to your developer or agent. Replace the example account and callback values with the approved settings for your app.
Implement the sell access before the first login scenario for a new app using ALKEYON.
Use the customer client policy below in the selected environment.
Register the exact HTTPS app callback and keep confidential credentials server-side.
Connect checkout to the intended recipient’s owner grant, preserve onboarding context and use accepted invitations for additional seats.
Keep the hosted login, verification and recovery flow tied to this app.
Validate tokens and enforce the tenant, account and operation boundaries.
Do not treat a successful login as a payment or membership grant.
Use the current SDK and OpenAPI contracts linked in this guide.
Verify permitted entry, refused entry, correct product return and revoked access.
Client policy:
{
"surface": "customer",
"allowSelfRegistration": false,
"signupGrantsAccount": false,
"checkoutUrl": "https://www.example.com/pricing"
}