Simplist is usable from a script, from an AI agent, and offline on your phone — and it can pull data in on a schedule without you doing anything. All four use the same records you already have.
API keys
Create a personal API key under Account → API keys. The full sk_… secret is shown once, at creation, so copy it then.
By default a key has the same access your account has, but you can narrow it when you create it:
- Access — Full access, or Read-only. A read-only key can list, search and export; every write is refused.
- Workspace — All workspaces, or one specific workspace. A workspace-bound key is also barred from account-level things like managing keys or backup configuration, so a narrow key can never be used to mint a broader one.
Revoke a key at any time from the same page.
The REST API
Send Authorization: Bearer sk_… on any /api/… route. The key stands in for the browser session, and key-authenticated requests skip the CSRF round-trip, so a script needs no cookie handling.
Pick a workspace with an x-simplist-workspace header; omit it to use your default workspace.
curl https://your-simplist-instance/api/models \
-H "Authorization: Bearer sk_…" \
-H "x-simplist-workspace: <workspace-uuid>"
An interactive reference for the whole surface is published in the app at /api-docs, and the OpenAPI specification behind it is served at /api/openapi.json — fetch it with your key to feed Postman, a code generator, or any other OpenAPI tool.
One exception: changing your password refuses key authentication, because it revokes every other session and that is meaningless without one. Change your password in the web app.
AI agents (MCP)
Simplist is its own MCP server, so an agent like Claude can create models, write documents and manage files on your behalf. The same sk_… key works as a bearer token, or you can connect through the OAuth flow.
Either way, the connection can be made read-only. Connecting through OAuth, choose Read-only under Access on the approval page; with a key, create it as Read-only. A read-only connection only sees the tools that list, search and read, and every write is refused. Whatever you choose, a connection never gets more than your own role in the workspace allows. An MCP client that only asks for read access (the mcp:read scope) is shown as read-only on the approval page, and you cannot widen it.
Keeping an agent’s changes safe
Everything an agent writes is labelled with the key or app it used, in a record’s history and in the activity feed. The Agents page (in the sidebar) shows each agent session, meaning each connection that changed something, with what it touched.
- Undo a session. Undo session walks back everything that session did: records it created go to Trash, records it deleted come back, and records it changed return to how they were. A record someone changed after the agent is left alone, and the result tells you which. Renames, merges and other changes to models and fields are listed for you to fix by hand rather than reversed.
- Review changes first. A key created with Review changes first (or an app approved with Review changes first under Access) doesn’t change anything directly. Each change waits on the Agents page, showing what the record holds now beside what the agent wants, until you Accept or Reject it. The agent can check what you decided.
- Limit what a key may do. A key can be refused deletes, refused changes to models and fields, or limited to writing in only some models. Change these at any time with Permissions on the API keys page; an agent that is already connected is held to the new rules from its next change.
A key with any of these limits can still read through the REST API, but it can only make changes through MCP, where the limits are enforced.
What agents are told about your workspace
When an agent connects, Simplist gives it a briefing: your models and what they are for, what belongs in each field, how often each field is filled in and its usual values, how models link, a couple of recent records written by people, and any changes you recently rejected. It is built from your workspace each time, and you can read exactly the same text under Agents → Briefing.
- Describe your models and fields in the model editor (see Models and fields). Agents read those descriptions too.
- Notes for agents, on the Agents page, are read before everything else: “Never delete records; set Status to Archived instead.” A key can carry its own notes as well, under Permissions.
- Example records can be switched off on the same page if you’d rather their content not go to the AI an agent runs on.
The in-app reference at /mcp-docs lists the available tools and how to connect.
Connectors
A connector is a standing instruction that turns something outside the app into documents of a model you choose. Three kinds ship today:
- Web page — paste a URL and it files the page’s title, description, site name and address.
- Calendar feed — point at an
.icsaddress and it files one record per event, re-reading every fifteen minutes. - News feed — point at an RSS, Atom or JSON Feed address (blogs, newsletters, podcasts, release notes, and the feeds automation tools like Zapier or n8n publish) and it files one record per entry, re-reading every fifteen minutes. The format is worked out for you.
Set one up at Connectors: name it, pick the model it files into, and point each thing the source produces at one of your fields. That mapping is the connector. It decides nothing on its own — it repeats a choice you already made, with no AI involved.
Attributes are mapped by kind, so a calendar’s start time is only offered your date fields and cannot be filed into a text field where it would look right and sort wrong.
Some consequences worth knowing:
- Syncing twice does not duplicate. Each source item is keyed by a stable id, so a second sighting updates the record the first one made, or does nothing when nothing changed.
- The records are ordinary documents — versioned, searchable, editable, and kept if you delete the connector. Their history attributes them to the system rather than to you, so a synced record does not read as something you typed.
- Vanished sources are flagged, never deleted. An event removed from a calendar leaves its record in place, because by then it may carry notes and relations that exist nowhere else. The connector page tells you how many records are affected. A news feed only ever shows its latest entries, so an older entry dropping off the end is not treated as removed.
- A connector that stops working is counted on the Connectors item in the sidebar, so a broken feed is noticed the day it breaks.
- Any single sync can be undone in one move. Records it created go to trash; records it changed go back to what they were.
Working offline
Simplist is an installable progressive web app. You can browse, create, edit and delete records — and change your models — with no connection, and it syncs when you are back online. A small badge marks anything not yet saved to the server.
Conflicts are never resolved silently. If someone changed a record while you were offline, /sync holds it for an explicit decision: keep yours, or discard it.
Outbound webhooks
Any workspace, on any plan, can register endpoint URLs that receive a signed POST when a document is created, updated or deleted — for wiring Simplist into something else you run. Configure them under Workspace settings → Webhooks; each endpoint gets a signing secret, shown once.
Every POST carries an X-Simplist-Delivery header. A delivery that fails is retried, and each retry of the same event carries the same value, so store the ids you have handled and ignore one you have seen before.