The API that
refuses bad accounting.
Every write goes through NolaPro's own models. The rules that stop a bookkeeper from posting a broken journal entry stop your integration too, with an error you can act on instead of a corrupted ledger you find in March.
| Account | Debit | Credit |
|---|---|---|
| 6120Depreciation expense | — | |
| 1710Accumulated depreciation | — |
What this API is for#
NolaPro is an ERP with a real general ledger underneath it. This API is how your software puts data into that ledger: customers, items, orders, invoices, payments, journal entries.
That makes it different from most APIs you integrate with. A bug in a CRM integration produces a wrong name on a screen. A bug here produces a wrong number in someone's financial statements, discovered at year end, by an accountant, who then has to unpick it.
So the design goal is not "accept whatever you send." It is: make it hard to put bad accounting into the system, and tell you exactly what was wrong when you try.
Four things worth knowing before you start#
Writes go through NolaPro itself. The API does not have its own copy of the business rules. It calls the same model code the application calls when a person clicks Save. If a bookkeeper cannot post an unbalanced journal entry through the UI, neither can you, and you get the same rule enforced the same way. This also means rules cannot drift apart between the app and the API over time.
Money is a string, never a number. "1450.0000", not 1450.0. Amounts are stored with four decimal places and quantities with six. JSON numbers are IEEE-754 doubles in most client languages, which will quietly destroy those digits. See Conventions.
Nothing is deleted. Accounting systems cancel, they do not erase. DELETE exists and does what you expect from the verb, but it cancels rather than removes: the record stays, and stays on your reports. It also needs its own scope, so a token that creates invoices cannot void them.
One token, one company. A token is issued for a specific user in a specific company. The company is never a field you send. This removes an entire class of integration bug where records land in the wrong set of books.
Where to go next#
| If you want to | Go to |
|---|---|
| Make a request in the next five minutes | Quickstart |
| Get a token and understand scopes | Authentication |
| Understand pagination, money, dates, idempotency | Conventions |
| Know what an error means and how to fix it | Errors |
| Solve a whole task, not one call | Recipes |
| Move an existing integration off the XML API | Coming from v1 |
The machine-readable spec#
The whole surface is published as OpenAPI 3.1 at /openapi.json. It is not written by hand. It is exported from the API's own route metadata, which is also what generates the reference pages on this site. Point your client generator at it.