Abacus API Integration
Abacus is one of the established ERP platforms for larger companies in Switzerland, covering finance, payroll, procurement and project management, plus industry modules such as AbaBau for construction. Connect it through Maesn and you reach it with the same REST API and the same data model as every other supported system.
An Abacus integration in days
Abacus asks one question before any of the usual ones, and it is a question about architecture rather than about code. Here are the three specifics, and what Maesn takes off the table.
Both are target systems here
The Abacus REST API covers the standard modules. The AbaConnect webservices expose endpoints it does not, which is where module extensions such as AbaBau for construction live. Maesn holds each as its own target system, so the choice is configuration rather than a second integration.
Settled once, at connect
Abacus can be installed at your customer or run on a hosted subscription, so the base URL is different per customer rather than fixed per vendor. It travels with the authentication call as a query parameter and is stored with the connection, so your code never holds an installation address.
Collected on the async task
On the AbaConnect path many endpoints, POST requests in particular, return a task id rather than a result, and those webservices accept one running request at a time. Maesn holds the task state, so the result is a second call against a shared endpoint rather than a queue in your backend.
What reaches your code is a REST call and an account key. Teams go live in days, and the system after Abacus is a configuration step rather than a second project.
A short call is usually enough to tell whether Maesn fits your use case.
HERO Software runs the trades back office across four markets
HERO Software digitises the back office for trades businesses of two to fifty employees, from the quote through to the invoice. Its own site names Germany, Austria, Switzerland and the Netherlands as its markets. Switzerland is where Abacus sits, and construction is where its AbaBau module does.
“The support provided is truly first class, with impressively quick response times. The documentation is thorough and easy to follow, which made integration a smooth process for me.”
Three reasons to reach the Abacus API through Maesn
Connecting Abacus directly is a project you can finish. Finishing it twice, once per API, and then adding the next system is the part that decides your roadmap.
The Abacus-specific work stays here
The service user in Abacus, the callback that carries the Abacus version, the base URL that differs per customer and the task polling on the AbaConnect side are what every Abacus integration has to solve. Each is solved once, on our side, for every customer you connect.
Where Abacus is strong, and it is not the ledger
Contacts, customers, projects and sales orders with their line items are what this connection reaches, which is the order-to-cash and project side of an ERP. Tell us which objects your use case needs and we confirm them for the path you are on.
The next system costs nothing
Once Abacus runs, every other supported accounting and ERP system answers on the same interface. Your second integration is a configuration step.
An Abacus listing is assessed rather than submitted
Most providers stop at the API. Maesn also prepares the listing, and on Abacus that matters more than usual because there is no self-service route into the programme: every application is handled individually and there is a qualification step in front of the listing.
Technical enablement
One integration against the Unified API and one data model, identical to every other system Maesn supports. Your engineers meet the same interface here as they will for the next system.
Partnership support
Maesn prepares the material the assessment asks for and stays behind the integration afterwards. The listing carries your product's name, not ours.
An individual application
There is no automated listing route. Each application is handled on its own terms, which means the timing depends on the conversation rather than on a queue.
A formal qualification step
The programme assesses the integration before it is listed. That is preparation work rather than engineering work, and it is the half Maesn has done before.
The integration runs under your product's name, and the partner status is yours rather than ours. Maesn is the layer behind it.
We prepare the material the assessment asks for and stay behind the integration afterwards.
One Abacus connection, two values that travel with it
Abacus authenticates through an authorisation code grant against a service user you register, and the part that is specific here is what the handshake does not settle: an Abacus installation has its own address, and the data inside it belongs to an environment.
- OAuth
- The Abacus REST API
- Username and password
- The AbaConnect webservices
One account key either way. Which credential your customer hands over follows the path you chose, not your code.
- The base URL, once
- It depends on whether your customer runs Abacus locally or on a hosted subscription, so it is provided with the authentication call and held with the connection from then on.
- The environment, per call
- Calls that target Abacus endpoints carry the environment name, and a documented endpoint returns the environments a connection can reach. So it is one lookup rather than a value your customer has to type.
On the AbaConnect path the connect step can stay inside your product entirely: it is one of seven target systems with the headless flow, where you post the credentials from your own form and the account key comes back in the same response.
- 1
You register a service user in Abacus
Set up as user dependent, with the login redirect URL pointing at Maesn's callback for your Abacus version. The version sits in that URL, so an estate on different Abacus releases is something the connection knows about rather than something your code branches on.
- 2
Your customer authorises it
The grant runs against their own instance, and the base URL for that instance travels with the call. The redirect comes back to Maesn, so the code exchange and the token lifecycle happen here instead of in your backend.
- 3
You work with one account key
Maesn stores the connection and returns an account key. From there every request carries your API key plus that account key, the same two headers you already send for every other system in the catalogue.
Every system in the catalogue authenticates differently, and Abacus is the case where the handshake settles less than usual: it proves who the customer is without saying which machine to call or which environment to read. Unified authentication is what keeps that from becoming two implementations. The base URL is settled while your customer connects, the environment is one documented lookup, and the same page covers the headless route, which is how the AbaConnect credential can be collected inside your own product instead of on a page outside it.
Nothing in Abacus calls you, so the read is scheduled
Change detection on Abacus is a read you schedule, and the schedule has one more constraint than usual because AbaConnect answers one request at a time. Events on a particular object are enabled when a use case needs one.
Nothing today. No object carries a native event and neither Abacus doc has a webhook section, so a change in a customer's installation stays invisible until something goes and reads it.
One scheduled read, with the same filter and the same pagination you use for every other system. The code that detects change on Abacus is the code you already wrote, pointed at a different account key.
One constraint belongs to the AbaConnect path rather than to the REST API, and it shapes the schedule instead of the code: those webservices accept one running request at a time, so a catch-up after downtime is a queue instead of a fan-out. Worth deciding before the build, because it is the kind of limit that only shows up under the load of a first large customer.
A system without events is where the cost of a per-system integration shows up most plainly: you write a change-detection loop for Abacus, and then another one for the next system with its own filter syntax and its own idea of what a page is. One way to filter and page removes that repetition, so the loop you build here keeps working against a system that does push events. What you handle in the event model and what you pull on a schedule stay two paths, and only one of them is Abacus’s today.
The AbaConnect side adds a second reason to think about shape rather than speed. Its webservices answer with a task id and finish in their own time, so the result is collected rather than returned. That is the same mechanism asynchronous processing describes for every other long-running call in the catalogue, so the collecting half is not something you write twice.
What an Abacus integration needs up front
Abacus puts four things in front of an integration, and all of them are easier to plan for than to discover halfway through a build.
- An Abacus instance with administrator permissions
- Your customer's instance, and for production the connecting user also needs permission to reach the mandant-provisioning API. Without an instance, Abacus's own API team can grant a sandbox one on request.
- A service user, set up as user dependent
- You create it in Abacus following their Authorization Code Grant guide and point its login redirect URL at Maesn's callback for the Abacus version you integrate with. Then the client id comes to us once, plus the mandant id if you are on a sandbox.
- The environment, on calls that target Abacus
- Data belongs to an environment rather than to the account, and the environment name is required when you call Abacus endpoints. One documented call returns the list, so it is a lookup at connect time rather than something your customer has to know.
- On the AbaConnect path, a user that is used nowhere else
- The account that runs the integration must not be signed in anywhere else, the Abacus UI included, because a second session invalidates the first and stops the integration. A dedicated service account is the documented recommendation, and it is worth creating before the first test rather than after it.
We walk through the service user, the sandbox and the AbaConnect path with you.
Two paths into Abacus, one shape in your code
Abacus is one product with two target systems, the REST API and the AbaConnect webservices, and which one your use case needs decides what it reaches.
Whatever you read comes back in the shared common data model, so a customer record from Abacus has the same shape as one from a system ten times its size, and the code you write here is the code you reuse for the next one. Which of the two paths you are on is a configuration value, not a second implementation.
What Abacus is good at through Maesn is worth knowing before you plan against it, because it does not look like the others. On most systems here the first objects you can touch are the ledger ones. On the Abacus REST path they are contacts, customers, projects and sales orders with their line items, which is the order-to-cash and project side of an ERP. That makes it a strong fit for keeping records aligned between your product and your customer’s, which is what customer and supplier data sync is built around. Tell us which objects your use case needs and we confirm them for the path you are on.
Tell us which objects your use case needs and we will confirm what is possible on each path.
