Start

This page takes you from nothing to a first recorded action, in about ten minutes. Five steps: make an account, get a key, point something at it, connect an app, run one thing and read the receipt.

You need a browser and, for the last two steps, either an assistant that speaks MCP or an HTTP client. There is nothing to install.

1. Make an account

Go to atmon.ai/signup and enter your email. atmon asks for one thing at a time: the email first, then whichever way of signing in your account supports, which may be a link sent to that address, a password, or a passkey.

Signing up creates an organization and one project inside it. A project is the boundary everything else sits in: its own keys, its own rules, its own connected accounts, its own receipts. Most people need exactly one to begin with.

2. Get a key

In the console, open Account and then the key page, or go straight to atmon.ai/console/#/account.

Create a key. It is shown once, in full, and never again: only a fingerprint of it is stored, so there is no way for anyone, including us, to read it back to you. Put it somewhere your code or your assistant can read it.

A key looks like amk_ followed by a long string. It resolves to exactly one project, so nothing you send ever has to name a project.

Keys carry a role, and the role matters:

Role	Who holds it	What it can do
Agent	Your assistant or your application	Search, describe, act, submit work, read receipts
Approver	A person	All of that, plus writing rules and releasing approvals

Give your assistant an agent key. Keep the approver key where a person uses it. The split is enforced rather than suggested: an agent key that tries to rewrite the rules is refused. See Policies for why that matters.

3. Point something at it

Two roads in, and you can take either one first.

If an assistant is going to do the work, connect it over MCP. The address is https://api.atmon.ai/mcp and your key goes in the Authorization header. Most clients read a small block of configuration:

{
  "mcpServers": {
    "atmon": {
      "type": "http",
      "url": "https://api.atmon.ai/mcp",
      "headers": {
        "Authorization": "Bearer amk_your_project_key"
      }
    }
  }
}

The console's key page prints this block with your own values already in it. For your AI has the same thing written out per client, plus the atmon skill, which teaches a model how to use the connection well.

If your own code is going to do the work, call the API directly with any HTTP client, or use one of the SDKs. Everything the SDKs do is a POST with a JSON body, so neither is a prerequisite for the other.

SDKs has the first call in TypeScript and Python, and says where each package stands during the beta. API reference has the same call as plain HTTP.

4. Connect an app

Nothing can act until an account is connected. In the console, open Connect, pick an app, and follow the sign-in. What you connect belongs to a person you name, which atmon calls an entity: a string you choose, usually the id your own product already uses for that user.

That naming is the whole multi-user story. One key serves every person in your project, and each person's connected accounts are theirs. An action taken for user-42 can only ever use user-42's credentials.

Connect an app covers the rest, including apps that take an API key instead of a sign-in flow, and connecting on a user's behalf from inside your own product.

5. Run one thing

Ask for the tool by describing the task, then run the tool you get back.

From an assistant, that is two turns and you write neither of them: it calls search_tools with what you said, then call_tool with the top match. Ask it to do something small and real, like sending yourself a message.

From your own code, the same two steps look like this:

POST https://api.atmon.ai/automaton.v1.RouterService/ResolveTools
{ "intent": "send myself a message on Slack", "entityId": "user-42" }

POST https://api.atmon.ai/automaton.v1.ExecutionService/ExecuteTool
{ "toolSlug": "slack.send_message", "entityId": "user-42",
  "resolutionId": "...", "argumentsJson": "...", "confirm": true }

Two things about that second call are worth knowing now.

confirm is how an assistant states that the person was told what is about to change. Anything destructive is refused without it, and the refusal happens before any credential is unlocked, so nothing reaches the app.

The answer is a receipt, not a bare result. It carries a status, an error code that is empty on success, and the result. A refused call is a normal, successful answer whose status says it was refused; it is not an exception to catch. Error codes has every code and what to do about each.

Read the receipt

Open Overview in the console. The action you just ran is there, with what was asked, what was sent, what came back, and how much it cost. Every call is, including the ones that were refused.