Members and API keys#

Sugar is invite-only. The initial bootstrap creates one owner; administrators then create expiring, single-use invitations for members.

Before you start#

• Owner bootstrap is complete.
• The public origin and authentication secrets are final.
• Limits are defined for the member's expected usage.

Create a member invitation in the admin portal and share it privately. After the member enrolls, assign the appropriate role and allowance. Members create named sgr_live_ inference keys; the secret is shown once and Sugar stores only its verification material.

Sign-in and account recovery#

A recovery code is a substitute for the second factor, not a way to sign in on its own: it is redeemed at the multi-factor step after the account's first factor has been proved. No route accepts an email address and a recovery code alone.

When a member is locked out, an administrator issues a single-use recovery link for that member from the admin portal. Redeeming it either sets a new password or clears the password and opens a short window to enrol a passkey. Repeated redemption attempts are throttled.

Password checks that guard a security change — changing or removing a password, adding or removing a passkey, disabling multi-factor authentication, rotating recovery codes — are rate limited per member, so a stolen session cannot be used to guess the account password.

Manage keys#

Use separate keys per client or machine. Revoke a key without disabling the member when one client is retired. Disable or revoke member access when the entire account must stop.

Verify#

Use the new key to list models, inspect its effective quota and send one request. Confirm usage is attributed to the intended member and key. Revoke the key and verify further API calls fail while the browser account remains usable.

If it does not work#