Authentication - AutoGrowth

Every /v1 endpoint authenticates with a developer API key sent as a bearer token:

Authorization: Bearer a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f60718293a4b5c6d7e8f90

There is no other way in. No cookies, no query parameter, no unauthenticated endpoint except the spec itself.

Creating a key

Open Settings → Developer API

In the dashboard, go to Settings, then the Developer API section. You need the Manage API keys permission — organization owners have it automatically, other roles need it granted. See Team.

Name the key and create it

The name is for you. It shows up in the key list with the key’s last-used time, so name keys after what will use them.

Copy it now

The raw key is shown once, at creation. AutoGrowth stores only a SHA-256 hash of it and cannot show it again. Lose it and your only option is to delete the key and create another.

Key format

A key is 64 hexadecimal characters — 32 random bytes, hex-encoded — with no prefix and no separator:

a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f60718293a4b5c6d7e8f90

Treat it as a password. Anything holding it can do everything you can do to your own rows, including scheduling runs that post to your accounts.

A key created by authorizing an MCP client looks different — it is generated by the MCP server rather than the dashboard, and you never see it. It behaves identically everywhere else.

Revoking a key

Delete it in Settings → Developer API. The next request with it answers 401. Deletion is the only revocation: keys do not expire, and they are not rotated for you. The list shows every key in your organization, so a teammate with the Manage API keys permission can revoke yours, and you can revoke a stale one left behind by someone who has moved on — including a key created by an MCP client.

What a key can see

A key is not an organization-wide credential. It inherits the role and the permissions of the user who created it, and most resources are then narrowed to that user’s own rows.

This is the single most surprising thing about the API, so it is worth stating flatly.

Resource	What the key sees
Accounts, content, collections, prompts, scripts, executions	Only the key owner’s own rows. Not the organization’s. An owner’s key does not see a teammate’s accounts.
Devices, tags	Organization-scoped. An owner sees every phone; anyone else sees only phones assigned to them or carrying one of their assigned tags.
Automations	Global. The same catalog for every organization, minus admin-only entries.
Stats	Mixed, and documented per field on `GET /stats/dashboard`.

Two consequences worth planning around:

A key cannot act on behalf of a team. If three people each own accounts, you need three keys, or one user who owns everything.
The dashboard’s “view as” is not available here. The dashboard lets an owner look at a teammate’s rows; a key always sees its own owner’s.

The key’s organization is resolved from its owner’s current membership, not from the organization the key was created in. A user who moves to another organization takes their keys’ access with them.

Auth error responses

Status	Body	Cause
`401`	`{"error": "Authorization required. Use: Authorization: Bearer <api-key>"}`	No `Authorization` header, or one that does not start with `Bearer`
`401`	`{"error": "Invalid API key"}`	The key matches no row — wrong, mistyped, or deleted
`403`	`{"error": "Account disabled or not found"}`	The key is valid but its owner’s user is disabled or gone
`403`	`{"error": "User not in any organization"}`	The owner belongs to no organization
`403`	`{"error": "Organization not found"}`	The owner’s organization row is missing
`403`	`{"error": "Insufficient permissions"}`	The key is fine; the owner’s role lacks the permission the endpoint requires

401 means the credential is wrong — retrying with the same key will never work. 403 means the credential is fine and the account behind it is not allowed to do this; retrying will not help either, and it is not a reason to re-authenticate.

A key deleted mid-request loses. The middleware re-checks the key when it stamps lastUsedAt and answers 401 if the row went away, so a revocation cannot be outrun by a request already in flight.

Handling auth in your client

async function autogrowthFetch(path, init = {}) {
	const res = await fetch(`https://api.autogrowth.farm/v1${path}`, {
		...init,
		headers: {
			...init.headers,
			Authorization: `Bearer ${process.env.AUTOGROWTH_API_KEY}`,
		},
	});

	if (res.status === 401) {
		// Wrong or deleted key. Retrying changes nothing.
		throw new Error('AutoGrowth API key is missing or invalid');
	}
	if (res.status === 403) {
		// Valid key, not allowed. Surface it to an operator.
		const { error, code } = await res.json();
		throw new Error(`AutoGrowth refused the request: ${code ?? error}`);
	}
	if (!res.ok) {
		const body = await res.json();
		throw new Error(body.error ?? `AutoGrowth request failed (${res.status})`);
	}

	return res;
}

​Creating a key

​Key format

​Revoking a key

​What a key can see

​Auth error responses

​Handling auth in your client

Creating a key

Key format

Revoking a key

What a key can see

Auth error responses

Handling auth in your client