REST API

Base URL https://api.sailo.store/api/v1.

9 operations over four resources. Everything returns { "data": … }; failures return { "error": { "code", "message" } } with a matching HTTP status. Every response carries a sailo-version header, currently 2026-08-12.

Every operation

All of them are also described machine-readably, as OpenAPI 3.1 at /api/v1/openapi.json — no key required, and what you point Postman or an SDK generator at.

What the surface is, and is not

Mostly reads. Two of the 9 operations write, and both are on contacts: create-or-update, and add-or-remove tags. That is the whole write surface and it is a deliberate line rather than a roadmap gap — those two are what an automation actually performs, and everything else an integration needs is a read.

No PUT, PATCH or DELETE. Creating a contact that already exists updates it, so there is no separate update verb to get wrong; and nothing here deletes anything, because a deletion arriving from an automation nobody re-read is not a mistake a seller can undo.

Four resources, not eleven. Shops, orders, products, contacts. Memberships and disputes have no endpoint — they reach you through webhooks instead, and their shapes are written out in the object reference precisely because there is no endpoint to read them off.

The rules that apply everywhere

Each of these has its own page, because each is a thing consumers get wrong in a way that is invisible until it costs something:

• Authentication — the bearer header, scopes, and what a key can reach.
• Conventions — the envelope, ids, money, dates, nulls, versioning.
• Pagination — keyset cursors, and why has_more and next_cursor answer different questions.
• Errors — six stable codes and what to do about each.
• Rate limits — 240 a minute, per key.

Resources

Getting a key

The API is on the Business plan. Every key is read-only unless you tick write, and is shown once at creation. Create one under Settings → Integrations.