API and MCP
Amendary exposes a read-only REST API and a read-only MCP server so your own tools and agents can read the same workspace data the dashboard shows. Both are read-only: they never change a correction, a page, or a setting, and never spend model budget.
What can the API do?
It reads. A key gives read access to one workspace, scoped to what that workspace already sees in the dashboard. There is no write API: nothing can apply a correction, edit a page, or change a setting through it.
Two surfaces read the same data: a REST API for a CI step or a script, and an MCP server for an agent. They share one auth model and one data path, so they never drift apart.
How do I create an API key?
In the dashboard, go to Settings → API keys. Only the workspace owner can manage keys. Give the key a name and select Create key. The key is shown once, so copy it then and store it somewhere safe. It starts with amk_.
Amendary keeps only a hash of the key, never the raw value, so a lost key cannot be recovered. To rotate, create a new key and revoke the old one.
How do I revoke a key?
On the same Settings → API keys page, select Revoke next to the key. Revoke is immediate: the next request with that key is refused. A revoked key stays listed so you can see it was in use and when it was last used.
What is the base URL and how do I authenticate?
The REST API lives under /api/v1. Send your key as a bearer token on every request:
Authorization: Bearer amk_your_key_hereThe key selects the workspace, so there is no workspace header to set. The OpenAPI schema for these routes is at /api/v1/openapi.json and lists only the read routes.
What data can I read over REST?
Four endpoints, all under the base URL:
GET /api/v1/corrections: pending and recent corrections with their evidence (the source, the changed paths, the stale quote, the planned edit). Paginated, newest first, with an optional status filter.GET /api/v1/checks/status: per-repo freshness. When each repo was last checked, the sha it was compared against, the last run’s outcome, and how many corrections are still pending.GET /api/v1/usage: the workspace’s token-usage summary, the same numbers Settings shows.GET /api/v1/docs: the mapped pages for a repo with a freshness record and each page’s own URL (Notion or GitHub). Optional repo and title filters.
Page text is never returned and never stored. /docs returns each page’s metadata and link, not its contents.
What is the MCP server?
A single JSON-RPC endpoint at POST /mcp that exposes the same read-only data as four MCP tools: list_corrections, get_check_status, get_usage, and get_docs. An agent can ask Amendary to list pending corrections or a repo’s doc freshness directly, with no dashboard round-trip.
It uses the same amk_ key as the REST API, sent as a bearer token, and the same read-only scope. The tools map one-to-one to the REST endpoints, so they return the same data.
Is there a rate limit?
Yes. Both the REST API and the MCP server are rate limited per key, per minute. A busy poller that goes over gets a 429; slow down and retry. API reads are not written to your Activity log, so a poller cannot flood it.
What is a good way to use it?
Common setups:
- A CI step that reads pending corrections and warns on a pull request.
- A dashboard or Slack post that shows per-repo doc freshness.
- A cost check that reads the usage summary on a schedule.
- An agent that asks Amendary, over MCP, whether a repo’s docs are behind.
For what each type of page is and how corrections are drafted, see Document types and Queue & reviews.