DEV Community

Cover image for Register for an Agentic Headless CRM Backend Without Leaving Your Agent
OCLauncher Team
OCLauncher Team

Posted on

Register for an Agentic Headless CRM Backend Without Leaving Your Agent

#backend #ai #mcp #webdev

Most developer quickstarts still assume the same old flow:

  1. open a signup page
  2. create an account
  3. find the API key screen
  4. copy the key
  5. paste it into your tool
  6. 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"
  }
}
Enter fullscreen mode Exit fullscreen mode

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..."
}
Enter fullscreen mode Exit fullscreen mode

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"
  }
}
Enter fullscreen mode Exit fullscreen mode

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..."
}
Enter fullscreen mode Exit fullscreen mode

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 .
Enter fullscreen mode Exit fullscreen mode

Request the email code:

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

Then verify it:

favcrm signup verify \
  --request-id <request-id> \
  --code <six-digit-code>
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

What the agent should do next

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

Authorization: Bearer fav_mcp_...
Enter fullscreen mode Exit fullscreen mode

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 '{}'
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)