Use Your Coding Agent

POST /api/v2/signup needs no auth. Omit password and the agent stays credential-free:

The response contains a setup-only API key. The activation link is emailed to the person only; it is never in the API response. From there:

1. Set up now. Use the key as a Bearer token to create agents and start the first run. Unverified accounts get 1 preview run.
2. Detect the gate. After the preview, runs return 403 with error.details.error_code == "EMAIL_VERIFICATION_REQUIRED". Tell the person to open the activation email; resend it with POST /api/v2/verify/resend.
3. Hand off. The person clicks the link, sets a password, and activates. At activation the setup-only key is revoked. The person mints their own key from the Developer dashboard or POST /api/v2/token.
4. Know when. Poll GET /api/v2/verify/status with the setup key: is_verified flips to true. A 401 also means the hand-off happened (the key was revoked).

product picks what to provision: "api" (default, the developer product) or "platform" (the team product, with Company Agent and Day-1 onboarding). "api" accounts start in strict multi-tenant mode; pass "require_end_user_id": false at signup to build single-tenant.

Run an agent with none of our branding

An agent you embed in your product should sound like your product. By default an agent knows it runs on m8tes: it calls itself a Mate, can describe what m8tes does, and knows our pricing. That is right for a team using m8tes directly and wrong for an agent your customers talk to.

Set prompt_profile to "bare" and none of that reaches the agent:

bare removes branding, not ability. Permissions, approvals, memory, files, integrations and your own Agent Skills all work exactly the same.

Switch an existing agent any time with client.agents.update(id, prompt_profile="bare"); it takes effect on that agent's next run.

Turn off any built-in tool

Every agent gets a set of built-in tools (memory, task history, an issue reporter, an owner-notify email tool, a desktop). Some of them make no sense in an embedded agent — our report_issue tool files feedback with us, and notify emails the account owner, not your end user. Name any of them and they are not mounted:

Valid names come from GET /api/v2/built-in-tools, which also reports what is currently on for a given agent — pass teammate_id and it accounts for your disable list, so it shows what a run will actually mount rather than the catalog default. An unknown name is rejected rather than ignored, so a typo can't leave a tool switched on while you believe it is off.

See exactly what we inject

You do not have to take our word for it. This returns the real prompt your agent will run with, rendered by the same code that runs it:

One deliberate exception: /home/daytona/m8tes-files/ is the real sandbox directory your agent writes to when it shares a file, so that path survives in bare. It is a filesystem path the agent uses, never something it is told to say.

Per-run context (memories, documents, connected tools, the triggering channel) is resolved when a run starts and is not included in this response.

Why the hand-off is secure:

The blocked-run response:

runs_used counts every run the account made, on any meter: it is the preview trip-wire, not a billing figure. The two allowances below it are separate meters and neither funds the other. balance_micros / balance_usd is the prepaid wallet, which runs carrying user_id spend, and it appears only on accounts the wallet funds. runs_remaining is the platform plan, which your own first-party runs spend — the web app, and API calls with no user_id. A user_id run debits the balance and leaves runs_remaining untouched, so on a new API account (strict multi-tenant by default, so every run carries a user_id) you will see it sitting at the full plan allowance. See Billing & Usage.