> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beinfi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent onboarding

> Let an agent collect the details, prepare the integration and hand the account to its owner.

Start with `infi_onboard` over MCP or `npx -y @beinfi/cli onboard --json` in the app directory. Without all answers it returns `requires_input`, `missingFields` and `questions`, and creates no account. Ask only for missing details, then call again with all answers and the same directory:

```bash theme={null}
npx -y @beinfi/cli onboard --email founder@example.com --account-name "Acme" --intent usage-saas --json
```

Intents: `crm`, `one-time`, `usage-saas`, `prepaid-ai-chat`. The response separates setup (`ready` / `needs_attention`) from ownership (`registration.status: "pending_claim"`). A passing setup diagnostic is not an application-level test; implement and test the app before reporting success.

## HTTP alternative

Without shell/MCP, POST `https://api-sandbox.beinfi.com/public/v1/claimables` with JSON:

```json theme={null}
{"ref":"lovable","email":"founder@example.com","accountName":"Acme"}
```

No login is needed. Securely persist `apiKeySecret`, `publishableKey`, `tenantSlug`, `productId`, `claimUrl` and `expiresAt`. Email is an unverified contact; it never grants access to an existing account. The seeded product is a draft without a price: follow the catalog recipe before charging. Do not blindly retry this POST if its response is lost.

## Resume and finish

CLI onboarding preserves unrelated environment variables and existing company config, keeps local credentials ignored by git and resumes the same account in the same directory. Use doctor/sync for an existing integration. If provisioning has an uncertain outcome, do not remove the recovery marker to force a second account.

Keep `INFI_SECRET_KEY` in server secrets. `INFI_PUBLISHABLE_KEY` may be exposed to browser APIs that need it; it is an Infi key, not a payment provider key. Never request the human's password or verification code.

Continue in sandbox and hand the human the exact `claimUrl` and `expiresAt`. Signing in and reviewing the prepared name transfers ownership of this same account. Products, keys and slug are preserved. Production setup remains a later dashboard step.

## Claim email

Successful provisioning with an email queues a transactional message with the account name, claim link, deadline and a button to finish registration. API keys stay in the API response and the app's secrets.

Delivery happens in the background and retries on failure. Provisioning does not wait for email delivery. At most one welcome is queued per address every 24 hours. Accounts already claimed or expired are skipped before sending. Omitting email from the POST creates the environment without a message.

Always hand the human the exact `claimUrl` in the conversation and continue integrating. Do not wait for email or create another account to trigger a resend. A `201` confirms provisioning, not email delivery. Receiving the message does not verify identity; the human still signs in to claim ownership.

The default claim window is 30 days. Use the returned `expiresAt` for the exact deadline, including environments with a different window.

Example agent handoff:

> I prepared your Acme account and saved the test keys in the app. Finish registration in Infi at \[returned claimUrl] before \[returned expiresAt]. You may also receive this link by email. I will continue the sandbox integration.

Requires the API version supporting `accountName`/`publishableKey`, CLI 0.2.6+ and MCP 0.1.5+. Email requires the sandbox claim-email update. Publish these docs with those releases; existing bootstrap commands remain available.