What the Ettex Platform API actually covers — form submissions, transactional email, sequences, sites and orders — and how keys, auth and errors work before you write any code.
The Platform API is narrower than "automate everything", and knowing the shape of it saves an afternoon. It covers the web and commercial surface of Ettex: what people submit, what you send them, what they buy, and the pages they land on. If you came looking for endpoints that edit documents or spreadsheets, they are not there — that side of the suite is local-first, which is a deliberate architectural choice rather than a gap in the roadmap.
There are two ways to authenticate, and conflating them is the usual first error. Most endpoints take an account token, acting as you; a smaller set takes an API key, which is scoped to a verified domain and revocable at any time. Two endpoints are public by design, because a storefront has to be readable without credentials. A 401 means the key or token is missing or invalid — not that the resource is absent — and reading it as "wrong URL" is how an hour disappears.
Create a separate key per integration rather than one key for everything. Revocation is the only real control you have when something leaks, and a shared key means revoking it breaks four things you had forgotten were using it.
Documents, sheets and slides keep their authoritative copy on the device rather than on a server, so there is no endpoint that rewrites a paragraph in your document from the outside. The practical route for that kind of automation is the opposite direction: generate the content where the data lives, and move the data, not the file. Where an assistant should drive these endpoints rather than your code, the same catalogue is exposed through the MCP server, one tool per endpoint.
No. The Platform API covers forms, email, sequences, sites and orders. Documents and sheets are local-first, so their authoritative copy is on the device rather than behind an endpoint.
The token acts as your account on most endpoints; the key is scoped to a verified domain, is revocable, and is what a server-to-server integration should use.
A missing or invalid key or token. It is an authentication problem, not a missing resource — check the credential before the path.
An OpenAPI document turns your API into something tools can consume — generating clients, powering try-it consoles, and catching the drift between what the docs claim and what the API does.
REST is a set of constraints, not a specification, which is why every API claiming to be RESTful is different. The conventions worth following are the ones that let a developer guess correctly.
Nobody reads API documentation from the top. They search for the endpoint, copy the example, and leave — which tells you exactly what to spend your effort on.