Accredo Saturn has an API.
It is a web service: an OData v4 REST API, secured with OAuth2, returning JSON. It reads across the ledger, writes standard records back, runs read-only SQL for reporting, and calls server-side scripts for the business logic no endpoint covers. Knowing which of those four to reach for is most of the job.
Personal reply from Andrew within one business day.
What is the Accredo API, exactly?
The Accredo web service API is a server-side component that exposes the Saturn data model over HTTP as an OData v4 service. An external system authenticates once, receives a bearer token, and then reads and writes records using ordinary REST calls against named entity sets.
That sentence is worth unpacking, because "our ERP has an API" covers an enormous range of things in practice — anywhere from a documented, versioned web service down to a folder somebody drops CSV files into. Saturn's is at the good end of that range, and the specifics matter when you are scoping work against it.
OData is a query protocol, not just a set of endpoints. It means the filtering, field selection, sorting, paging and related-record expansion are all part of the standard rather than something each endpoint invents for itself. Ask for open balances above a threshold, return three fields rather than sixty, page through the result — all of that is expressed in the URL, and it behaves the same way across every entity the service exposes. For an integrator that consistency is the whole value: once you have written one read correctly, you have written all of them.
Authentication is OAuth2 with bearer tokens. An application exchanges its credentials for an access token, sends that token on every subsequent request, and re-authenticates when it expires. Tokens expiring mid-run is the single most common cause of an integration that works in testing and fails at 3am, so any client worth deploying handles the unauthorised response by refreshing and retrying rather than by falling over.
Updates use optimistic concurrency. The service issues a version tag with each record and expects it back on an update. If someone changed that record in Saturn between your read and your write, the write is rejected rather than silently overwriting them. This is the correct behaviour and it is also the thing most first-attempt integrations get wrong — they read, they write, and they quietly clobber whatever a user did in between. Handling the rejection properly, by re-reading and reapplying, is not optional on a live company file.
The service is self-describing. It publishes the set of entities it exposes and the type metadata for each one. That matters more than it sounds: entity and field naming in an ERP is rarely guessable, it varies with what your site has licensed and configured, and building against the live metadata is the difference between an integration that works on your install and one that worked on someone else's.
# Authenticate once, then read with standard OData query options.
# Every name in braces is a placeholder — see the note below.
GET {server}/saturn/odata4/v1/Company('{code}')/{Entity}
?$filter={Field} gt 0
&$select={Field},{Field},{Field}
&$top=50
Authorization: Bearer {token}
# Updates carry the version tag the service gave you.
# Stale tag, rejected write — not a silent overwrite.
PUT {server}/saturn/odata4/v1/Company('{code}')/{Entity}('{key}')
If-Match: {etag}// Shape only. Entity and field names come from your own install's metadata, not from an example.
What can the Accredo API actually do?
Three distinct mechanisms, not one. Most integrations that go wrong went wrong by using the first for a job that belonged to the third — so it is worth being precise about what each is for before any of it is scoped.
| Entity endpoints | Read-only SQL | Server-side scripts | |
|---|---|---|---|
| What it is | The OData surface proper — one addressable entity set per record type, with the full query syntax over it. | A passthrough that runs a SELECT against the underlying database and returns the rows as JSON. | A call that runs a MaxBasic script already installed on the Saturn server, with arguments, and returns its output. |
| Direction | Read and write. | Read only. No inserts, no updates, no deletes. | Whatever the script does — including native posting. |
| Best for | Everyday record work: look up a customer, create one, update a product, page through orders. | Reporting and reconciliation — anything that joins or aggregates across several tables in one round trip. | Business logic and transactions that no endpoint models, and anything that must post the way Saturn posts to itself. |
| Why choose it | Supported, self-describing and uniform. Validation happens inside Accredo rather than in your code. | One call instead of forty. Shaping the result server-side beats pulling raw rows and joining them in the client. | Full access to the product's own routines, so the work obeys every rule Saturn enforces on its own users. |
| Where it falls short | Not every business action is modelled as an endpoint, and a partially-applied multi-step write is worse than a rejected one. | Couples you to the physical schema, which is not a published contract — an upgrade can move it under you. | The script has to be written, deployed, versioned and documented on the client's install. It is not purely a remote call. |
// Endpoints for records. SQL for reading. Scripts for transactions and anything the product does better than you can.
The rule that falls out of the table is short: use the endpoints wherever they can do the job, use SQL when you are only reading and the shape matters, and use a script when the operation has to be atomic or has to obey business logic you did not write. Almost every integration decision on an Accredo site reduces to that.
The third column is the one people miss. It is tempting to treat a REST API as the whole interface and assemble everything from it, endpoint by endpoint — but a financial transaction in an ERP is not one write. It moves stock, it moves a debtor balance, it moves the general ledger, and those movements are only correct together. Assembled from outside, that sequence is one timeout away from a stock movement with no invoice behind it, and that is a fault you discover at month-end rather than in testing. The script that column refers to is a MaxBasic script, and where it attaches inside Saturn — to the save cycle, to the post, or to nothing but a schedule — is its own decision, taken one hook at a time on the MaxBasic scripting page. The field service management case study is the same decision made in anger on a real build, with the integration section setting out which data travelled the API and which had to be posted natively.
Where does the Accredo API stop?
Every integration proposal should say this part out loud, and most do not. The API is good, and it is not a complete remote control for the product. Four limits are worth knowing before anyone quotes on work against it.
Not every business action is an endpoint. The service models records well. It models processes less completely — the things that in the desktop product are a posting run, a document print or a multi-step routine are not all reachable as a single call. Where they are not, the answer is a script on the server, which is a perfectly good answer, but it is a different piece of work with a different deployment story and it needs to be in the estimate.
Derived values are calculated, not accepted. Fields the product works out for itself — costs and prices resolved from the product's own rules being the obvious case — are generally rejected rather than taken on trust. That is correct behaviour, and it surprises people who expected to push a full record in from outside. It also means an integration cannot quietly bypass your pricing rules, which is a feature.
The data model is not always shaped how you would guess. Descriptive and narrative content in particular often lives somewhere other than on the record it belongs to. This is normal for a mature ERP, and it is exactly why the metadata endpoints matter: you build against the model that is there, not the model you sketched on a whiteboard.
An API does not make a bad process good. Automating a manual re-keying step that should not exist just moves the problem and adds a system to maintain. Sometimes the right recommendation after looking at an integration is that the process is the thing to change, and there is nothing to build. That advice is free, and it is given more often than the sales pitch would suggest.
What does an Accredo integration project involve?
Less than most people fear, and in a different order than most people expect. The connection is rarely the hard part; deciding what should cross it, and in which direction, is where the time goes.
The first piece of work is not technical. It is establishing which direction the data actually needs to move and which system owns each field, because "integrate Accredo with our CRM" usually turns out on inspection to be three separate flows with three different owners and three different failure modes. Naming them separately is what stops an integration becoming a permanent maintenance tax.
After that, the sequence is unremarkable and deliberately so: confirm against your install's own metadata what is exposed and what is not; build and prove the reads first, because reads cannot damage anything and they surface the data-model surprises early; then design the writes, choosing per data type between an endpoint and a native post; then handle the boring parts properly — token expiry, retries that cannot double-post, concurrency rejections, and a log someone can actually read when a record does not arrive.
The deliverable is a documented, supportable build. Credentials are yours, the code is yours, and what is installed on the Saturn server is written down. Nothing here requires changing your licensing, your upgrade path, or your relationship with your Accredo partner — that work sits alongside theirs, and coordinating directly with them is normal. If you want the wider picture of what else can be done inside Saturn, the Accredo Saturn capability page covers the scripting, forms, custom tables and reporting this sits next to, and the integration topography section is the short version of the routing decision above.
Trying to work out whether your Accredo data can reach another system? Describe the flow — the audit is free, and the answer is sometimes "don't".
Book a free process auditQuestions about the Accredo API.
Does Accredo have an API?
Yes. Accredo Saturn has a web service API — an OData v4 REST service, authenticated with OAuth2, returning JSON. It is a genuine programmable interface rather than an export folder, and it is the supported route for connecting Saturn to web applications, Microsoft 365, HubSpot, e-commerce platforms and reporting tools.
Do we need anything installed or licensed to use it?
The web service is a server-side component, so it has to be present and enabled on your Saturn install before anything can talk to it. What your site already has depends on your licensing and configuration, and your Accredo partner or Accredo themselves can confirm that in a sentence. It is the first thing to check, because it decides whether an integration is a build or a conversation with your reseller first.
Can the API write transactions and invoices into Accredo?
It can write records, and for standard records that is the right route. A financial transaction is a different case: it moves stock, a debtor balance and the general ledger together, and those movements are only correct as a set. That is better committed by a native script using Saturn's own posting routine than assembled from outside call by call, so the design decision is made per data type rather than once for the whole integration.
How do we get data out of Accredo for reporting?
Two ways, depending on the shape you need. Entity endpoints with OData filters are ideal when you want records of one type with specific fields. The read-only SQL passthrough is better when a report joins or aggregates across several tables, because it returns the shaped result in one call instead of making the client stitch raw rows together. Reads cannot damage anything, which is why they are always the first thing built.
Is it safe to point an integration at our live company file?
It is, with three disciplines in place. Validate every write against live records before sending it. Handle the version-tag rejection properly, so a concurrent edit by a user in Saturn is never silently overwritten. And make retries idempotent, so a call that times out and is repeated cannot post the same thing twice. An integration missing any of those is not finished, regardless of whether it currently appears to work.