Letting other software read your data
The API Studio: publishing one screen at a time, issuing a key, pinning it to an address, and the same publication as an MCP server for an AI agent.
Sooner or later something outside TRANXACT wants your data: a reporting tool, a partner’s system, a website that needs the price list, an AI agent that has been asked a question about your business. The API Studio, under Platform, is where you decide what that is allowed to be — one screen at a time, one column at a time.
Nothing is reachable from outside until somebody publishes it. There is no setting that opens everything and no key that reaches everything. A brand-new deployment has no API surface at all, and that is the correct starting position rather than something waiting to be switched on.
The four decisions, in order
| What | What it decides | Who usually makes it |
|---|---|---|
| An exposure | That one screen may leave this company at all — which columns of it, which rows of it, and whether anything may be written back. | Whoever owns the data |
| A client | That one piece of software exists, what it is called, who to ring about it, and which user of yours it acts as. | Whoever runs the integration |
| A grant | That this client may reach that exposure, with these verbs. | Whoever runs the integration |
| An allowed address | Where the key may be presented from — a browser origin, a host, one server address, or a network. | Whoever runs the integration |
The platform ships three roles for this and keeps them apart on purpose. An API Publisher decides what may leave and cannot issue a key. An API Registrar issues keys and cannot create an exposure. An API Reviewer reads everything and changes nothing. Held by one person, publishing the payroll table and issuing yourself a key that reads it is a complete, unwitnessed export path in which every step looks like an ordinary administrative change.
Publishing a screen
- Open Platform → API Studio and choose a screen. The list is every screen the console has, read out of the product itself — so a screen that shipped this release is on it.
- Tick the columns that may leave. Nothing that is not ticked is ever sent: not in a list, not in a single record, not in what a write hands back. Nothing is ticked to begin with, deliberately.
- Decide the verbs. Read is on by default; create, change and delete are each a separate decision, because letting their system read your item master and letting their system delete it are not the same sentence.
- Optionally restrict the rows — only posted invoices, only this year. It is the same filter every list screen speaks, applied on the server on every call, and nothing a caller sends can widen it.
- Save it. It is a draft, and a draft reaches nothing. Make it live when you mean it.
- Press Preview before you give anybody a key. It shows exactly what a partner would receive, and how many columns were withheld.
Registering the software
A client is a record of a piece of software: what it is called, what it is, who to contact about it, and — the important one — which user of yours it acts as. Every call the key makes is made as that person. Whatever they may not do, the key may not do either.
That is the single most important field on the screen, and it is why an exposure can only ever narrow access and never widen it. Point a key at a user made for the purpose, holding the narrowest role that does the job — not at a real administrator because it was convenient.
The key itself is shown once, when it is issued, and never again. Issuing a new one stops the old one working immediately. A key can be withdrawn without deleting the client, so the register still says who had reach and when it was taken away.
Where a key may be used from
A key with no allowed addresses reaches nothing. No addresses named is read as not reachable yet and never as reachable from anywhere, because a leaked key that works from any laptop in the world is the whole of the risk. Four kinds of entry: a browser origin, a referring host, a single address, or a network in CIDR form.
A client can be marked as usable from anywhere, and sometimes that is right — a partner whose egress address genuinely moves. It is a deliberate switch with a warning beside it rather than the default.
What to send whoever is integrating
The studio prints the four addresses. The base is /api/v1, the key goes in an Authorization: Bearer header, /api/v1/resources lists what this key may reach, and /api/v1/openapi.json is the same thing as an OpenAPI 3.1 document.
Both of those are generated from the key that asks for them. A partner is never handed a document listing forty endpoints they cannot call: theirs describes exactly what they can call and nothing else, and it cannot describe a path that would be refused, because it is built from the same rows the request handler checks.
The same data for an AI agent
The address /api/v1/mcp is a Model Context Protocol server. An agent connecting to it is offered a tool for each thing the key may do and nothing else — no tool for data nobody published, no tool for a verb nobody granted. It is the same publication, described for a model rather than for a developer, so the two can never get out of step.
Write the MCP instructions on the client. It is the only place a model is told that these tools reach a live ledger rather than a sandbox, and the only place you can say that orders here means purchase orders and not sales orders.
What happens on every call
A published call is not a shortcut into the database. It is authenticated, checked against the exposure and the grant, and then made as your run-as user through the platform own API — the same route the console uses. Company scoping, business-unit scoping, place restrictions, closed periods, posting rules, custom fields, custom logic, editability and the audit trail all apply, because they are the same code running.
Every call is recorded, allowed or refused, with the reason. That log is under Platform → API Studio → API Call Log, and a key presented from an address nobody allowed is the single most interesting line it produces.
When it does not work
| What the partner sees | What it means |
|---|---|
| That API key is not recognised | Wrong key, or a new one has been issued since. |
| This API key has no allowed addresses | Nobody has said where it may be used from yet. |
| This API key is not allowed to be used from here | It names the origin and address that actually arrived — usually the partner has moved servers. |
| Nothing is published here as X | The name is wrong, or that exposure is not granted to this key, or it is still a draft. |
| This key may not create X | The exposure or the grant does not permit that verb. |
| You do not have permission to view X | The grant is fine and the run-as user is not. The studio lists these before a partner has to find them. |
The client list shows a readiness column rather than only a status, because a client can be active, hold a key and still reach nothing — no user to run as, no address allowed, nothing granted. Reading active while every call comes back refused is how an afternoon goes.