Every system, one common data model
Maesn normalises responses, formats and structures across every ERP and accounting system, so you build against a single schema instead of dozens. Where a native endpoint falls short, Maesn makes the extra calls and fills the gap before the response reaches you.
What is a common data model
A Unified API exposes one standardised set of endpoints across many systems in the same category and normalises each system's data into shared schemas. Instead of learning every ERP's data shapes, you implement a single code base and always receive consistent, normalised data, whichever system your customer runs.
Normalisation happens at the level of the schema, not just the field name. Maesn aligns field names, data types, date and currency formats and the relationships between objects, so an invoice, its line items and its contact fit together the same way in every system. That is what separates a common data model from a plain field-by-field mapping: you build against one predictable structure once, instead of reconciling each system's quirks yourself every time you add another integration.
Every system models data differently
The same invoice looks different in every system: different field names, date formats, currency handling and object structures. Building and maintaining a separate mapping for each one is where integration projects stall.
And the difference is not only in the data. Not every system speaks REST: some are SOAP, some expose GraphQL, some are XML-RPC or JSON-RPC. Parts of some are not requested at all but exchanged as files, as XML or CSV. A single integration across a handful of systems can therefore mean four transport technologies before a single field has been mapped. Odoo is the clearest example in the catalogue: it has no REST API at all, and reaching it means RPC. Behind Maesn all of it arrives as one REST interface, so parsing XML, reading CSV exports or learning a GraphQL schema never becomes your problem.
Normalised, ISO-standardised and complete
Just a few examples. Maesn normalises far more than this, across every field, object and system.
Xero returns it as currencyCode, sevdesk as currency, and Lexware Office has no currency field at all because it only supports euro. Maesn returns one currency field, always with the right value.
One normalised schema
Responses, formats and structures are normalised across every system, so every integration you build behaves identically.
Background multi-calling
Where a native endpoint does not return everything, Maesn makes the extra calls itself and assembles one complete object.
ISO standards enforced
Country codes follow ISO 3166-1, currencies ISO 4217 and dates ISO 8601, validated on the way in and on the way out.
Told what a system ignores
When a target system does not use a field you sent, the response says so in meta.warnings instead of silently dropping it.
Automatic date conversion
Send a date or a full timestamp. Maesn converts it to what each system expects, adding midnight UTC or dropping the time as needed.
{"data": [{"id": "9714f3a2-5b8e-4d1b-8a0c-9f6e7d2f3e4b","invoiceNumber": "1020","currency": "EUR","invoiceDate": "2026-01-01T00:00:00Z","contactId": "eaa28f49-6028-4b6e-bb12-…","lineItems": [ … ]}],"meta": { "pagination": { "total": 125 } }}
Complete objects, assembled for you
Some systems never return a complete object from a single endpoint, and a contact is the clearest case. One system keeps the company, its contact people, their addresses, their email addresses and their phone numbers behind five separate endpoints. Another returns all of it from one. Same object, same customer question, two entirely different amounts of work.
Maesn does that work in the background. You call one /contacts endpoint. Behind it, Maesn either passes the request to the single native endpoint or makes the five calls in the right order and the right formats, then assembles the result before it reaches your code. What arrives is one contact carrying its addresses, contactPersons, emailAddresses and phoneNumbers, whichever system it came from. The multi-calling, the ordering and the reassembly stay on Maesn's side.
"data": [{
"id": "92c4f3a2-5b8e-4d1b-…",
"companyName": "maesn",
"addresses": [ … ],
"contactPersons": [ … ],
"emailAddresses": [ … ],
"phoneNumbers": [ … ]
}]One model, less to maintain
- Map every system's data shapes by hand
- Branch your logic for each system's quirks
- Re-map whenever a system changes its API
- Rebuild for every new system you add
- Build against one schema
- No per-system branching
- Upstream changes absorbed for you
- New systems included automatically
The part that gets underestimated is not the build, it is the years after it. A target system changes a field, renames an endpoint or alters a format, and an integration built directly against it breaks. Either you track every upstream release to stay ahead of it, or you find out when a customer tells you their data stopped syncing. Building is a question of time to market; maintenance is where the cost accumulates, and over the life of an integration it is usually the larger half.
That is the half Maesn absorbs. The systems Maesn partners with notify it of changes before they land, and the work of following them happens on Maesn's side of the interface rather than yours. How well that has held is a checkable fact rather than a promise: Maesn is still on the first version of its API, so nothing you built against it has been taken away. Should a breaking change ever be unavoidable, the intent is to announce it ahead of time and publish the new shape alongside the old one instead of in place of it, so the migration lands in your planning rather than in an incident.
The common data model deliberately covers the fields and objects that every system shares. When a customer needs something outside it, you are not stuck. Customisation handling reaches anything beyond the model: Authenticated Passthrough calls any endpoint in the system directly, and Raw Data gives full, unfiltered access to whatever the system returns. Nothing is locked away, so the model stays clean without limiting what you can build. One model that holds across systems is what product and engineering teams are actually buying when they pick a unified API.
Common questions
What does Maesn normalise?
What if a system has a field the common data model does not cover?
How do I know whether a system actually used a field I sent?
Are new systems automatically covered?
How are dates and currencies handled?
Do I still need per-system logic?
How is the common data model different from field mapping?
Does normalising the data mean I lose access to anything?
What happens when a system changes its API?
Build once on the Unified API.
See how the Common Data Model works for your integration, or dive into the technical reference.