MicroApps

Appearance

API & automation ​

Everything you can do in the console, you can do from code. The console is just a client for this same public API - what it does, you can do. Two ways in:

  • REST API - plain HTTP and JSON. Good for scripts, servers, CI, dashboards, anything.
  • MCP - the same account, driven by an assistant like Claude that speaks the Model Context Protocol.

Credentials ​

The REST API takes either of two bearer tokens:

  • A login token (JWT), the same one the console uses. Fine for a quick interactive script, but it expires and there is no refresh endpoint, so you would log in again.
  • An API key (mck_...), created once and reused. This is the right choice for anything long-lived or unattended.

MCP is API-key only. Assistants run without a human to log in, so a login token is not accepted there.

Scoped permissions ​

An API key does not have to be all-powerful. When you create one, you grant it a set of permissions - pods:read, snapshots:create, billing:read, and so on - and the key can do exactly those things and nothing else. A key for a status dashboard might only read; a key for a deploy script might manage pods but never touch billing.

The same scoping carries into MCP: an assistant only sees the tools its key is allowed to call. Give Claude a read-only key and it can look but not touch.

A couple of guardrails worth knowing:

  • API keys can never manage your team, roles, or account settings, no matter who created them. Those need a signed-in person: the Owner, or a member whose role grants them.
  • A key's power is capped by its creator. It cannot exceed the permissions of the person who made it, and if that person loses access, the key stops working too.

IP binding ​

Optionally, pin a key to specific IP addresses or ranges. A request from anywhere else is rejected before it does anything. Handy for locking a key to your office, a CI runner, or a single server.

Where to next ​

Built for the long tail.

© 2026 MicroApps