Your website has an API. And it speaks MCP.

Issue a token from your own backend and let your software — or your AI assistant — read and edit your site directly.

Most website platforms treat the admin screen as the only way in. Yours does not. Every EZsite site exposes the same operations its own backend uses — over HTTP, with a token you issue yourself, and over MCP, so an AI assistant can work on your site directly instead of being told about it.

1. Issue a token

In your backend, open Website → API Token. Choose read or read + write, give it a name and an expiry. The secret is shown once.

2. It is pinned to your site

A token is issued for you and locked to the site you were in. Neither the user nor the website can be changed by the request, so a token cannot reach anything else.

3. Use it

Send it as Authorization: Bearer ezsk_… to /api/v1, or point an MCP client at your site. No separate developer account.

The MCP endpoint

MCP — the Model Context Protocol — is how AI assistants connect to real systems instead of guessing. Your site speaks it at:

POST https://your-domain.com/en/api/mcp

It is Streamable HTTP: one JSON-RPC request per POST, authenticated with your bearer token. Point Claude Desktop, an IDE or your own agent at it and the assistant can read your pages and edit them, with your permission scope deciding what it may touch.

What it can do today

Read: list your sites and read one, list and read pages, list the section types available to your theme and describe the fields of any one of them, list products, list a page's backups.

Write (only with a write-scoped token): update a section, add a section, delete a section, reorder the sections on a page, and restore a page from a backup.

Every write goes through the same backup mechanism your backend uses, so an edit made by an agent can be rolled back exactly like one made by a person.

What that is actually useful for

  • "Update the opening hours on every branch page to close at 10pm" — across twelve pages, without twelve visits to the editor.
  • Pulling this month's promotion from your own system into the homepage banner on a schedule.
  • Letting a copywriter work through an assistant without giving them backend access at all.
  • Keeping a staging site and a live site in step.

The REST API

If you would rather not speak JSON-RPC, the same operations are addressable as resources:

GET    https://your-domain.com/api/v1/pages
GET    https://your-domain.com/api/v1/pages/536
PATCH  https://your-domain.com/api/v1/pages/536/sections/172501750557

Same bearer token, no language prefix, and real HTTP semantics: 200 and 201 on success, 204 on delete, 401 without a token, 403 when a read-only token tries to write, 404 for a page that is not there, 405 with an Allow header when the verb is wrong, 422 when the arguments do not fit the section type. Errors come back as {"error": {"code", "message"}}, successes as {"data": …}.

GET /api/v1 lists every resource, so the API documents itself.

It is the same curated layer the MCP endpoint uses, which is deliberate: a write through REST and a write through an agent go through the same validation, the same scope check and the same page backup, so the two can never drift apart.

The admin API underneath

Both of the above sit on the JSON API the backend itself calls, covering pages, products, categories, orders, members, promotions and more:

GET https://your-domain.com/{lang}/api/{module}/list

with Authorization: Bearer ezsk_… on every request. Your token's scope and the role it inherits decide what it may do — the same permission rules that apply to you in the backend, not a parallel set. It is shaped around the admin screens rather than around resources, so prefer /api/v1 unless you need something it does not cover yet.

Honest limits

  • Tokens are issued by the site owner, not granted to an app. There is no OAuth consent screen yet, so a third-party service cannot ask your customers for access — someone has to issue a token and paste it. That is a deliberate stage, not an oversight.
  • Writes cover page sections, not the whole product catalogue, through either transport. Reading products is supported; bulk catalogue work still goes through the import tools.
  • /api/v1 is the curated surface. It covers sites, pages, page sections, section types, page backups and products. Anything else still goes through the admin API described below.
  • A token is a credential. It is stored hashed on our side and shown to you once. Give it an expiry, and revoke it from the same screen when a project ends.

Building something against it, or want to know whether your use case fits? Tell us what you are trying to automate. If you are already a customer, the token screen is in your backend right now.