maesn
Product features

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.

Book a demoSee all features
Trusted by winning software teams
HubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesAgicapHubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesAgicap
4.8on G24.8 out of 5 stars on G2
The full set

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.

Why they are one product

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.

How these pages fit

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.

Product features FAQ

Common questions

What is the difference between a feature page and an integration page?

A feature page describes a mechanism of the API layer and holds for every system behind it: how objects are named, how a customer connects, how an event reaches you. An integration page describes one named system, what it exposes and what it does not, and where its own API shapes the answer. You read a feature page to understand what you build against, and an integration page to check whether the system your customer runs is covered.

Do I pick the features I want?

No, and that is the point of the layer. They are properties of the same connection: once a customer has authenticated, the common data model, the paging and filtering behaviour, the event model, the logging and the error semantics are all in place for every system that customer runs.

How is the MCP server different from the other eight?

The eight are how your own product talks to accounting systems. The MCP server is how an AI assistant does: it exposes the same normalised data through the Model Context Protocol, so tools like Claude and ChatGPT can query and update financial data in plain language under the same authentication and the same security model as everything else.

Which page should I read first?

The common data model, because everything else assumes it. Once you know how objects are named and shaped across systems, authentication describes how a customer gets connected to them, paging and filtering how you ask for a slice, webhooks how you hear about changes, and the rest follows from there.

Where do the target systems set the limits?

Where a vendor API stops, and each feature page names that limit on its own page. Some systems have no native event mechanism, some cap the request rate, some expose fields nobody else has. That is the work the layer absorbs: the feature stays the same on your side, and its page describes what happens underneath when a system behaves differently.

Build once on the Unified API.

See how the unified API layer works for your integration, or dive into the technical reference.

Book a demoRead the docs