Open at both ends
There are about a hundred and twenty routes inside this product and none of them is the public one. Those change shape whenever a screen does. A key holder cannot be redeployed, so the public API is small, versioned and plain.
Out to Excel, in from a file, and a URL that makes leads.
A table exported to Excel from its own header, rows pasted in from a spreadsheet and mapped, and a rule that turns anything posted to /website into a lead.
The tables you defined are the API
A table added by prompt this morning is addressable this afternoon, under its own name, with its own columns. There is no registration step, because a registration step is a thing to forget.
The OpenAPI document is generated per key from the tables that key can reach, partly because a document listing tables you get a 403 on is a document that lies, and partly because a table called "Redundancy Candidates" is one nobody outside HR should learn exists.
- Full CRUD: list with filters, sort, search and paging; read; create; update; delete to the bin
- Bearer keys only, never a cookie and never a key in a query string
- Every read and write goes through the same permission checks the browser does
- A row you may not read and a row that is not there both answer 404
- A rate bucket per key, so one runaway integration is a throttle, not an outage
GET /api/v1/machines?filter=site:eq:214&sort=next_service:asc
Authorization: Bearer … — a key bound to a person
Same privileges, depths, business units and column security
200 — 18 rows, paged, with the columns this key may read
GET /api/v1/openapi.json describes all of it, for this key
Everything it connects to
Each of these is a decision, not a checkbox. Where we refused a common approach, the reason is on the page.
Machines talking to it
- Versioned REST API at /api/v1, full CRUD
- OpenAPI document generated per key from your own tables
- API keys bound to a person, so an audit trail still names somebody
- Inbound webhooks that start a flow, one endpoint per flow
- Outbound HTTP steps with SSRF protection
- Per-key rate limits, configurable
- Connect your own Outlook or Gmail: delegated, per person, never domain-wide
- Messages land on the customer’s timeline: who, when, subject, snippet, link
- Bodies are never stored: a snippet is enough to recognise a message
- Sending goes through your own mailbox, so it passes SPF and lands in your Sent Items
- A deployment mailbox for replies, routed per workspace
- SMTP relay as the fallback, with templates
Identity
- OIDC single sign-on against your own identity provider
- Claim your email domains; nobody outside them is admitted
- Provision an account on first sign-in, or refuse it
- SCIM 2.0, so your directory creates and deactivates people
- The billing owner always keeps a password, so a bad IdP config cannot lock you out
- Two-step verification for accounts that want it
Files and figures
- Import from Excel and CSV, with columns matched for you and errors shown per row
- Export any screen to CSV or Excel
- Attachments on records, with a size and space ceiling per workspace
- VAT numbers checked against the Commission’s VIES service, with the evidence kept
- Quotes and invoices rendered as documents, ready to print or send
- Backups you can take, download and restore
Where we said no, and why
Microsoft Graph and Google both offer a way to read every mailbox in an organisation. Both are refused here. A CRM that can read the chief executive’s mail is a CRM no security team signs off, and a data-protection surface we would own for ever.
One connection per person, granted by them, and the routes never take a user id, they use the one on the session. An administrator connecting or removing somebody else’s inbox is something this cannot do.
- Delegated permissions only, never application-wide
- Metadata, never message bodies
- Polling on the existing queue, not a new public callback
- The legal page names Microsoft or Google only if you connected one
Point something at it
Make a key during the trial, read the generated OpenAPI document, and see whether the surface fits the integration you have in mind.