Point an agent at MyApi.

Everything on this page is implementable today with the open beta. The full, machine-readable reference lives at /openapi.json (OpenAPI 3) and /llms.txt (agent instructions); this page is the human tour.

Quickstart

1. Create an account (free during beta, no credit card).
2. Connect a service — dashboard → Services → pick one of the 121 supported services → approve the OAuth consent or paste an API key. The credential goes into the encrypted vault.
3. Create a scoped token — dashboard → Access Tokens → choose scopes (e.g. services:gmail:read) → copy the token. This is what your agent holds; it is shown once and stored hashed.
4. Make the first call:

curl https://www.myapiai.com/api/v1/services \
  -H "Authorization: Bearer $MYAPI_TOKEN"

You'll get every connected service with its status. From there, GET /api/v1/tokens/me/capabilities tells any agent exactly what its token allows.

Authentication

Three ways in, all ending at the same gateway. All requests use Authorization: Bearer <token> unless noted.

Agents with no credentials at all can request access via the no-auth handshake flow (POST /api/v1/handshakes) and poll until the owner approves — details in /llms.txt.

Scoped tokens

Scope hierarchy

admin:* > services:* > services:{name}:write > services:{name}:read. Write implies read. Per-service scopes are standalone — services:gmail:read works without any global grant, and grants nothing else.

Lifecycle

• Create in the dashboard with an explicit scope list; the plaintext is shown once and stored bcrypt-hashed.
• Constrain further with a persona ceiling, per-agent rate limits, and resource sub-scopes (specific calendars, repos, entities). At call time the narrowest constraint wins.
• Observe — every call the token makes is metered and audit-logged with agent attribution.
• Revoke or pause instantly from the dashboard; revocation takes effect on the next request. Device keys are revoked the same way from /dashboard/devices.

A scoped token is never a provider credential: revoking it cannot break the underlying service connection, and it cannot be used to read vault secrets. More on the security model: /security/.

REST — calling connected services

One proxy endpoint reaches every connected service. The path is the provider's own REST path; MyApi attaches the sealed credential server-side:

# List Gmail messages through the gateway
curl -X POST https://www.myapiai.com/api/v1/services/gmail/proxy \
  -H "Authorization: Bearer $MYAPI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "path": "/gmail/v1/users/me/messages",
        "method": "GET",
        "query": { "maxResults": 5 } }'

• GET /api/v1/services — what's connected and callable right now.
• GET /api/v1/services/{name}/methods — documented operations + proxy usage per service.
• POST /api/v1/services/{name}/execute — predefined high-level methods ({ method, params }).
• Out-of-scope calls are rejected at the gateway with a 403 naming the missing scope — they never reach the provider.

The complete endpoint surface (knowledge base, personas, memory, skills, automations, AFP file access) is in /openapi.json.

MCP

The MCP server surfaces every connected service, your knowledge base, and personas as tools — already scoped by the credential it runs under.

# Claude Code
claude mcp add myapi -- npx myapi-asc-mcp

# Any MCP client (stdio)
npx myapi-asc-mcp

On first run it generates an Ed25519 device keypair and registers it with your account; you approve the device once at /dashboard/devices and the keypair becomes the permanent credential — no token ever sits in the agent's config. Re-running enrollment replaces the old key and revokes it server-side.

• Works with: Claude Code, Claude Desktop, Cursor, OpenClaw, Hermes — any client speaking MCP over stdio or HTTP.
• Quick Connect: mint a one-time enrollment code in the dashboard and pass it to the server for a scoped, pre-approved setup.
• Server card: machine-readable description at /.well-known/mcp/server-card.json.
• Troubleshooting: "device pending approval" → approve it in /dashboard/devices; a 403 naming a scope → the key's scope ceiling excludes that service; re-enrolling on a new machine mints a new device, it never shares keys.

Machine-readable discovery

Workspaces, roles & teams

• Workspaces partition everything — services, tokens, personas, audit history. Every API request is workspace-scoped via the X-Workspace-ID header.
• Members & roles: invite people into a workspace with role-based permissions; owner-only surfaces (billing, user insights, security hub) stay owner-only.
• Portability: snapshot personas, skills, knowledge and memory, then restore or move them between workspaces.
• Organizations: SSO, SCIM provisioning, seat billing, policy controls and audit-log streaming exist for teams that need them — talk to us during beta.
• Seats & pricing post-beta: not finalized; everything is open during beta and commercial packaging will be announced before it applies to anyone.

Something missing or wrong on this page? Say so on Discord — docs bugs get fixed like code bugs.