API

Programmatic access to system data and actions — so they can be used in your own tools, not only through our screen.

• OperationsFamily
• in AURA subscriptionBilling

Problem

The data is in the system, but it's needed elsewhere: in a management spreadsheet, in a tool someone at your company built, in a report covering multiple locations at once. Without programmatic access, the only option is exporting to a file and manually re-entering — exactly the work the entire system was supposed to avoid.

What we do

We expose system data and actions externally in a way your developer or your tool can use.

• Access is granted and revoked on the permissions side, not by sending a password to someone
• We define the scope directly: what goes out, what stays inside
• Access comes with documentation, because an interface without a description is access only on paper

What's included

Three elements; you decide on the second one, not us:

• Access to system data and its actions
• Permissions: who, to what, and for how long
• Documentation describing how to use it

Timeline

Module doesn't start separately — it activates together with AURA level. How much work it takes on your side depends on what the access should lead to: connecting a ready-made tool is one thing, writing your own is another. Scope and deadline for such work are set before launch, not during.

Cost

Programmatic access does not stand beside the system as a separate contract — it is part of it and expires with it. So it has neither its own price list nor its own notice period. Whether to enable it at all and how widely is settled during configuration, together with the rest of the permissions.

If on your side separate integration work is needed — connection to a system we don't yet support — that's a separate service with its own pricing and its own article: API Integrations.

What you get

Data that doesn't end on our screen. Management can pull it into their own report, the network can sum up several locations, and your programmer can write a tool that we don't have. Plus one protection: since access is granted separately, it can be revoked without changing anything in the system itself.

How to calculate real load before setting access limits

Before asking about a request limit, it is worth calculating how many there will actually be. Formula: requests_per_minute = active_tool_users × refreshes_per_minute_per_user.

• active_tool_users — how many people or processes are actually using the access at a given moment, not how many have access in principle
• refreshes_per_minute_per_user — how often your tool queries the data; a dashboard refreshing every minute is not the same as one polling once a day

With five users polling once a minute, that is five requests a minute — not much. The same dashboard polling once a second is already three hundred requests a minute, and that is a question to ask before launch, not after.

Three ways to get data out: manual export, a ready-made dashboard, programmatic access

The choice depends on how often you need the data and who receives it on the other end.

• Manual export to a file: no developer needed, but someone has to download and forward it every single time
• A ready-made dashboard or report in the system: the data is visible right away, but only in whatever layout the dashboard offers
• Programmatic access (this service): data flows straight into your own tool or into the management's spreadsheet, in whatever shape you choose

Programmatic access makes sense where data needs to flow regularly and automatically into something you already have or are still building. Where a weekly glance is enough, a ready-made dashboard is simpler and cheaper.

When programmatic access does not pay off

Four situations where something else is the better choice:

• Nobody on your side codes or commissions this on an ongoing basis — access with no one to use it just becomes a key nobody picks up
• The need is a one-off, for example a single extract for an audit — a manual export is simpler and cheaper
• It is enough to look at the data every so often, without connecting it to another tool — a ready-made dashboard in the system does the same job for less
• It is really about connecting to one specific other system, not raw data access — that is the Integrations service, not this one

In that last case the difference is not cosmetic: access gives you raw data and documentation, an integration builds a finished connection between two specific systems.

What we need from your side for the access to make sense

Access with no plan for what it is for is just a key sitting in a drawer.

• A technical person — a developer, an integrator, or your own tool — who will actually use the access
• A clear scope: which data and which actions should be exposed, and which should stay inside
• A decision on who on your side grants and revokes permissions when the team changes

Without that last decision, access stays permanently tied to one person — which becomes a problem the moment that person leaves the company.

How to check the effect after a month, without our report

Three things are visible on your own tool's side, without logging into anything of ours.

• Whether requests are coming through at all — visible in the logs of your own tool or integrator
• Whether the documentation is enough for someone new, who has never worked with it, to set up the connection on their own
• Whether revoking one person's access actually cuts the connection off immediately, not a few days later

That last test is worth doing once, deliberately — it is a simpler way to check security than reading the contract.

What API access does not do

Access gives you data and permissions, but it does not write the tool that uses them for you — somebody has to build that tool: your developer or us, and then it is work to be planned, not a switch to be flipped.

Nor do we promise a specific response time or uninterrupted availability — this is not a service agreement with a guaranteed SLA, but access within the system you use every day. And it does not replace connecting systems: if you need a ready, permanent link to a particular external system, that is the integration layer — next door, in the same AURA.

The most common mistake when using API access

A shared password instead of separate permissions. Someone hands one access key to the whole team because it is faster — and then nobody knows which tool is actually using it, and revoking it for one person switches everyone off at once.

The cost of this mistake only shows up when someone leaves or something breaks: you have to shut everything down and start over instead of simply revoking one person's access. That is why we issue permissions one at a time, not as one shared key for everyone.

Whose data this is, and what happens when the API itself changes

The data we give access to is yours — it comes from your own business and stays yours regardless of whether programmatic access is switched on at all.

• Access is granted and revoked at the permissions level, without changing anything in the system itself — revoking it for one person or one tool does not delete any data
• If you part ways with Aura, programmatic access expires together with the rest of the system, on the same terms as everything else — it is not a separate contract to be terminated on its own
• If we change the shape of the data or how it is fetched, we do it as a version change, not a silent overwrite of what already works — old tools should not stop working overnight without warning

The reverse situation — when your own tool depends on someone else's API, not ours — carries the same risk: the other side can change its interface without asking anyone. That is why documentation and logs are part of the access, not an extra — so a change like that is visible right away, not after a week of silence.