Register for an Agentic Headless CRM Backend Without Leaving Your Agent

Most developer quickstarts still assume the same old flow:

open a signup page
create an account
find the API key screen
copy the key
paste it into your tool
finally make the first call

That is fine for a normal dashboard-first SaaS product.

It is awkward for an agentic backend.

If the whole point is that an AI agent can operate the backend, registration should also be something the agent can help with. The user should be able to say:

Sign me up for FavCRM. The business is a yoga studio called Stretch + Breathe in Hong Kong.

Then the agent should request the signup code, wait for the user to paste it back, verify the code, and receive an API key.

That is what FavCRM's agentic registration flow does.

What we are building

By the end of this article, you will have:

a FavCRM workspace
a verified owner email
a fav_mcp_* API key
a configured CLI
a first diagnostic check against the MCP endpoint

You can run the flow through an MCP client or through the favcrm CLI.

Path A: register from an MCP client

In an MCP-compatible client, the agent uses two no-auth tools:

register_organisation_request
register_organisation_verify

The request step sends a short-lived email code.

{
  "name": "register_organisation_request",
  "arguments": {
    "email": "you@example.com",
    "organisationName": "Stretch + Breathe",
    "industry": "fitness",
    "country": "HK",
    "timezone": "Asia/Hong_Kong"
  }
}

The response includes a requestId, a masked email, and an expiry time.

{
  "requestId": "signup_req_...",
  "maskedEmail": "yo*@example.com",
  "expiresAt": "2026-05-11T12:00:00.000Z",
  "instructions": "Tell the user to check yo*@example.com for a 6-digit code..."
}

After the user reads the email and pastes the code back, the agent verifies it:

{
  "name": "register_organisation_verify",
  "arguments": {
    "requestId": "signup_req_...",
    "code": "123456"
  }
}

The verify step creates the workspace and returns an API key once.

{
  "organisationId": "org_...",
  "companyId": "co_...",
  "userId": "usr_...",
  "apiKey": "fav_mcp_...",
  "loginUrl": "https://app.favcrm.io",
  "nextSteps": "Set Authorization: Bearer <apiKey> on subsequent MCP calls..."
}

Do not paste that key into source code. Store it in your MCP client config, a local environment variable, or your secret manager.

Path B: register from the CLI

If you are working in a terminal, the CLI wraps the same flow.

Install from source:

git clone https://github.com/favcrm/cli ~/Project/favcrm/cli
cd ~/Project/favcrm/cli
cargo install --path .

Request the email code:

favcrm signup request \
  --email you@example.com \
  --organisation-name "Stretch + Breathe" \
  --industry fitness \
  --country HK \
  --timezone Asia/Hong_Kong

Then verify it:

favcrm signup verify \
  --request-id <request-id> \
  --code <six-digit-code>

By default, signup verify saves the returned API key to the normal CLI config file. Human output masks the key unless you explicitly use --show-key.

That default matters. Agentic systems should avoid leaking keys into logs, transcripts, screenshots, and repo files.

Run the first diagnostic

After verification, run:

favcrm doctor

The doctor command checks:

the MCP endpoint URL
whether auth is configured
the reachable tool count
current organisation context
plan status
WhatsApp connection status when available

For machine-readable output:

favcrm --json doctor

What the agent should do next

Once the API key exists, every normal MCP call should include:

Authorization: Bearer fav_mcp_...

From here, the agent can list tools, inspect schemas, and call CRM operations:

favcrm tool list
favcrm tool describe list_services
favcrm tool call list_services '{}'

A fresh workspace may return an empty services list. That is success. It means auth works and the backend is ready for setup.

Failure modes to handle

Registration is intentionally small, but agents still need to handle edge cases.

Expired code. Ask for a fresh code by calling register_organisation_request again.

Wrong code. Retry verification with the corrected 6-digit code.

Existing account. Ask the user to sign in to the portal and create an MCP key from Settings, or continue through the existing merchant flow.

No email received. Check the masked email, wait a minute, and retry the request if needed.

Token leaked. Revoke the key in the portal and issue a new one.

Why this flow matters

Agentic registration is not just a convenience feature.

It proves that the backend was designed for agents from the first step. The agent can discover the signup tools, request email ownership proof, complete verification, and move directly into useful work.

The user does not need to understand API-key screens before seeing value.

In the next article, we will connect an MCP client and inspect the 165 typed CRM tools that become available after registration.

推荐订阅源

DEV Community