API

The API.

Wellplanner runs on an HTTP API. Every screen in the product is a client of it, which is the only reason it is worth writing this page: there is no partner subset carved off the side, because there is nothing else for us to use.

One API, and the product is its first client.

Ninety three operations over the same record the planner, the workshop, the crew and finance all read. A job, its tool strings, the serials on them, the runs they went on and the lines they were billed as are all reachable, because the product itself has to reach them.

It is described by an OpenAPI document generated from the code rather than maintained beside it, so it cannot drift from what the service actually does. The frontend's own client is generated from that document.

Style
HTTP and JSON. Resource paths, ordinary verbs, no envelope
Surface
93 operations across 76 paths, with 128 schemas
Description
OpenAPI, generated from the code on every build
Isolation
Every request is scoped to one company in the database. How that works
Times
UTC throughout. Run times are never local
Money
Amounts carry their currency. There is no assumed one

How integration works today.

A request carries the token of a signed-in person, and the company it may read is the one that person belongs to. Every call is scoped by the same database rule that scopes the product, which is why there is no second permission model to keep in step with the first.

Service credentials, so an integration can authenticate as itself rather than as somebody, are the next thing we build. The design is settled: a service account is scoped to one company exactly as a person is.

What shapes the rest is your side of it. Most well service companies need Wellplanner to reach two or three systems and no more, and we would rather build against a real one than guess. Which system, in which direction, and how often is the useful thing to tell us.

Service credentials
On the roadmap. A service account, scoped to one company like any other
Bulk export
Available. An administrator downloads every table their company holds, as CSV
Webhooks
Built against a real integration rather than guessed at. Name the event you need
Versioning
One version. A deprecation policy lands with the first integration

Integration

Tell us what you need to connect.

Most well service companies need Wellplanner to reach two or three systems and no more: an accounting package for invoice lines, sometimes a maintenance system for certificates. Naming yours is more useful to us than a feature request.

Reference
The OpenAPI document is available on request, and to every customer once you are signed in