Nine features, one API to build against
Every accounting system names its objects differently, authenticates differently, pages differently and fails differently. Maesn puts one layer over all of them, and these are the nine parts of it your integration actually touches.
Start with the capability your integration leans on
Each page takes one mechanism and shows it end to end, with the systems it has to hold for.
/contactsCommon Data ModelOne normalised schema across every system you connect.environmentSelection=trueUnified AuthenticationEvery auth method and multi-company flow, abstracted.limit · page · lastModifiedUnified Pagination & FilteringOne way to filter, order and page results everywhere.X-MAESN-SIGNATUREUnified WebhooksOne event model, even for systems without native webhooks.endpoint · system · connectionUnified Logging & MonitoringEvery request, response and webhook, logged in one place.downstreamErrorsUnified Error HandlingPredictable errors and graceful third-party outages.GET /asyncTaskAsynchronous ProcessingSend high volumes without minding each system's limits.POST /accounting/passThroughCustomisation HandlingReach any field or object beyond the common data model.claude_desktop_configuration.jsonMCP ServerOne MCP interface AI assistants read and write through.
One authentication, then every mechanism is in place
These are not nine products with nine contracts. A customer authenticates once, and from that single connection the same object names come back, the same filter and paging grammar applies, the same event body arrives, the same error shape comes out and the same request log holds the evidence. Adding a system to your product means adding a system, and nothing else.
That is also why the list is short and stays short. Each entry earns its place by being something you would otherwise write yourself for every vendor you connect, and write again the next time a vendor changes its mind.
A feature is the mechanism, a use case is the workflow
A feature page answers what the layer does and holds for every system behind it. A use case answers what a whole workflow looks like end to end, from the first read to the last write, and it leans on several of these features at once. The integration pages answer the third question, the one a prospect asks first: is the system my customer runs actually connected.
In an evaluation the three usually get read in that order backwards. Someone checks that their system is on the list, then reads the workflow that matches what they are building, then comes here to see what they get to stop maintaining. The case studies are the same story told by the teams who already went through it.
Common questions
What is the difference between a feature page and an integration page?
Do I pick the features I want?
How is the MCP server different from the other eight?
Which page should I read first?
Where do the target systems set the limits?
Build once on the Unified API.
See how the unified API layer works for your integration, or dive into the technical reference.











