REST API
128 operations, described in an OpenAPI 3.1 document. Lists page with a cursor, and errors come as problem+json.
Most of what a shop does in Talstok can also be done through the API: 128 operations on products, stock, orders, customers and settings. Selling at the till, suppliers and purchase orders, staff and payment settings stay in the dashboard. AI assistants connect over MCP with the same key.
The REST API and the MCP server take a key, and the key’s role decides what they may do. The catalogue is public, for a shop’s own website.
128 operations, described in an OpenAPI 3.1 document. Lists page with a cursor, and errors come as problem+json.
131 tools for AI assistants, with the key’s permissions. It speaks protocol 2026-07-28, and 2025-11-25, 2025-06-18 and 2025-03-26 for older clients.
Products, collections, menus, prices, whether each can be ordered (yes or no, never a count), services, buy prices and the shop’s details, read with no key.
Any MCP client that can send a key in a header connects to one address.
The shop owner makes one in Settings, under Apps and API keys, and gives it a role: manager, packer or viewer. It is shown once.
Point the assistant at https://api.talstok.com, as in the settings at the top of this page, and send the key as a Bearer token.
Every tool that changes something accepts dry_run, which checks the change without making it.
The assistant reads products and orders, records counts and the rest, within the key’s role.
Each key belongs to one shop and holds one role: manager, packer or viewer. No key can act as the owner.
Every POST must carry an Idempotency-Key. A retry of the same request with the same key is told what the first one did (its status and the id it made) instead of acting twice.
An error names a stable code and the shop’s rule that refused the request, so your code can change the plan instead of retrying.
Lists page with a cursor, up to 200 rows at a time.
How a website turns a shop into menus and pages, in markdown, with no key: the site guide.
Every path, field and role in one OpenAPI document, read with any API key: openapi.json.
An API for a point-of-sale system: a way for other software to read and change what the till sells from. Talstok’s covers products, stock, orders, customers and settings, and a sale made at the till reads as an order. Ringing up a sale through the API is not built.
Yes. Talstok’s MCP endpoint lets an AI assistant work on a shop with the same permissions as an API key: read products and orders, record stock counts, and the other operations the API offers. It has 131 tools.
No. Everything the API does can be done in the dashboard. The API is there for shops and agencies who want their own website, their own tools or an AI assistant on top.
Yes. Build against a test shop at https://api-test.talstok.com with that shop’s key, where no money moves. Then point the same code at https://api.talstok.com with a key from the live shop.
Each shop’s records live in a database of their own, and every row is checked against the shop it belongs to. A key names one shop, so a request has no way to reach another.
Only when Stripe sends a signed message for that shop. A request from a browser, or from an API key, cannot mark one paid. A sale at the till is marked paid by the signed-in person who takes the money.
No. Orders are never deleted and prices are kept as a history, so the API can always say what an order cost on the day.
A test shop is free, and no money moves in it. Build your tools against its API at https://api-test.talstok.com, then point the same code at https://api.talstok.com with a key from the live shop. A website built on the public catalogue reads the test shop’s own address, then the live shop’s.