The REST API: Tokens, Permissions and Limits
There is a real REST API behind the product, and there is no developer portal where you click "generate token". How authentication actually works, why a token carries your permissions rather than its own, and what the API is genuinely good for.
Most SME operations platforms answer "do you have an API?" with yes, and the yes covers everything from a documented public interface to three endpoints that exist because the mobile app needed them. Ours is closer to the second than the first in origin and closer to the first in coverage, and the honest framing is worth having before you plan a build around it.
What exists: several hundred authenticated endpoints spanning inventory, procurement, assets, sales, POS, projects, HR, accounting and reporting, behind token authentication, rate limiting and the same permission model as the web interface. What does not exist: a developer portal, a token-generation screen, or a published contract we promise not to change.
How you get a token
Through the authentication endpoints the mobile application uses — you post credentials and receive a bearer token. There is no settings page where you mint a personal access token for a script, which surprises developers and is the actual position.
What the token is
Property Reality
Type Bearer token, sent as an Authorization header
Issued by The app authentication endpoints, not a developer screen
Abilities A copy of that user's tenant permissions, plus a mobile marker
Lifetime Expires — thirty days by default
Scope One organisation. There is no cross-tenant token
The third row is the important one and it is a genuinely good design: a token cannot do more than the person it belongs to. Grant that user fewer permissions and every script using their token becomes narrower, immediately, with no code change. It also means the reverse — an integration token belonging to an administrator is an administrator.
Create a user for the integration
This follows directly from how abilities work and it is the single most useful practice on this page. Do not run a script on a person's token.
-
Create a named user for the integration
Something recognisable — "Stock feed", "Website orders". Not a shared human account, and not the administrator.
-
Give it a role with exactly the permissions the script needs
Usually read on two modules and write on one. Because the token copies these, this is where the security boundary genuinely lives.
-
Note that it will appear in the audit trail under that name
Which is the point. Six months later "who changed this item" answers "Stock feed" rather than a former employee.
-
Plan for expiry
Tokens expire. A script that has run for a month and then stops has almost certainly hit that, and it needs a re-authentication path rather than a hard-coded string.
-
Remember MFA enforcement
If your organisation requires MFA, the API respects it. Work out how your integration user satisfies that before you build, not afterwards.
The layer nobody expects
Authenticated API traffic passes through the same audit logging as the web interface, which means an integration writing a thousand records a day is a thousand audit entries a day attributed to that user. This is correct and occasionally surprising when someone opens the audit log looking for a human.
What the API is genuinely good for
Good use
A one-off bulk extract
This is the honest answer to the missing full-tenant export button. If you or a developer are willing to page through endpoints, the API is a real route to getting everything out — and it is the route we would point you at.
Good use
Feeding stock or price data to your own website
Read-only, low risk, and the shape of thing the API handles well. Cache aggressively on your side; you are rate-limited and you do not need live figures on a catalogue page.
Careful
Writing transactions from another system
Possible, and it bypasses nothing — the permission model and the posting rules still apply, which is the point. But you now own idempotency: a retried request that creates a second record is your bug to find.
Wrong tool
A continuous two-way sync with another business system
There is no change feed, no webhook fired on every record change, and no cursor-based "what changed since" endpoint. Building continuous sync means polling, which will hit rate limits and will drift. Do not architect around this.
The boundaries, stated
What AWRA OpsHub does today
- Several hundred authenticated endpoints across inventory, procurement, assets, sales, POS, projects, HR, accounting and reporting.
- Bearer token authentication with per-token abilities copied from the user's tenant permissions.
- Rate limiting, MFA enforcement and audit logging applied to API traffic the same way as to web traffic.
- A dedicated offline sync interface with idempotency on a client-supplied operation id, built for the mobile app and genuinely robust.
- A separate authenticated surface for supplier users, so a vendor-facing integration does not need a staff account.
- A single inbound webhook endpoint for the other direction, authenticated by token and optionally HMAC-signed.
What it does not do
- No developer portal, no token-generation screen and no published, version-guaranteed contract. Endpoints are not promised to be stable across releases.
- No change feed, no per-record webhooks and no "what changed since" cursor — so continuous sync is polling, which will not scale.
- No sandbox environment. You test against your own data.
- No GraphQL, no bulk write endpoint, and no SQL or query workbench of any kind.
- No OpenAPI specification you can generate a client from.
If you are planning a substantial build, talk to us first — not for approval, but because we would rather tell you which endpoints are stable than have you discover it in a release. That conversation is free and it is the only mitigation for the absence of a version guarantee.
The two other doors
Worth knowing about because they solve problems people reach for the API to solve, more cheaply. If you want an external event to cause something here, the inbound webhook is one authenticated endpoint and needs no polling. If you want something here to cause an event elsewhere, outbound webhooks and connectors fire on your own workflow rules and need no code at all.
Between those two and the import templates, a surprising proportion of the integrations people initially scope as API work turns out not to need a developer. Check that first — it is a cheaper answer and it stays working when your developer moves on.
Our take
The API is real, permission-bound, audited and rate-limited, and it is the honest route to a bulk extract. It is not a platform: no portal, no version guarantee, no change feed, no sandbox. Create a named integration user with the narrowest possible role, plan for token expiry, and check whether a webhook or an import template solves your problem before you write code.
Talk to us before you scope the build
We will tell you which endpoints are stable, which of the four integration doors fits your problem, and where an inbound webhook would do the job without a developer — before you commit anyone's time.
See plans & pricingFrequently asked questions
Is there a REST API?
Yes — several hundred authenticated endpoints spanning inventory, procurement, assets, sales, POS, projects, HR, accounting and reporting, behind bearer token authentication with rate limiting, MFA enforcement and audit logging. What there is not is a developer portal, a token-generation screen, a published version-guaranteed contract, an OpenAPI specification or a sandbox.
How do we get an API token?
Through the authentication endpoints the mobile application uses: post credentials, receive a bearer token. There is no settings screen for minting a personal access token, which surprises developers and is the actual position. Tokens expire — thirty days by default — so build a re-authentication path rather than hard-coding a string.
What can a token do?
Exactly what the user it belongs to can do. Token abilities are a copy of that user's tenant permissions, so narrowing the user narrows every script using the token immediately with no code change. The corollary matters as much: a token belonging to an administrator is an administrator. Create a named integration user with the narrowest role that works.
Can we build a continuous two-way sync with another system?
Not well. There is no change feed, no per-record webhook and no "what changed since" cursor, so continuous sync means polling — which will hit rate limits and will drift out of step. Push-style integration works: something happens elsewhere, it posts to the inbound webhook. Pull-style continuous sync is not a shape this API supports.
Is the API a way to export all our data?
Yes, and it is the honest answer to the absence of a single full-tenant export button. Paging through endpoints is real work, but it is a genuine route to a complete extract and it is the one we would point you at. Read [writing your exit plan first](/blog/switching-erp-vendors-exit-plan) for what a migration-grade extract needs to include.
Does API activity appear in the audit trail?
Yes, under the name of the user whose token was used, which is one more reason to create a dedicated integration user. An integration writing a thousand records a day produces a thousand audit entries a day attributed to that name — correct behaviour, and occasionally surprising to whoever opens the audit log expecting to find a person.
