maesn
By function

Four teams, one integration, four different questions of it

The engineer asks whether it can be shipped without one client per system. Sales asks whether the answer to “do you support ours” is yes. Support asks which request failed for which customer. Finance asks what the books actually say. It is one connection underneath all four.

Trusted by winning software teams
HubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesAgicapHubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesAgicap
By function

Start with the team whose week this changes

Four pages, one per role, each pointing at the capabilities and workflows that role actually meets.

What each team asks

One connection underneath, four different questions of it

The teamWhat it asks of the integrationWhat answers it
Product & EngineeringCan we ship this without writing one client per system?Common Data Model
Go-to-MarketWhen a prospect names their system, is the answer yes?The connected systems
Customer SuccessWhich request failed, for which customer, and when?Unified Logging & Monitoring
Financial TeamsWhat do the books say, without waiting for an export?The MCP server
One capability per row, not the whole list. Each team page carries the rest of what it meets, and the question in the middle column is the one that team asks first rather than the only one it has.

The questions do not translate into each other, which is why one page cannot answer all four. What does not change between them is the connection: the customer authenticates once, and the same object model serves the engineer building against it, the answer sales gives on a call and the request support looks up afterwards.

How these pages fit

A team page is the reader, a use case is the workflow

Three axes cross on this site and each answers a different question. A use case is a workflow end to end, the same one whoever cares about it. An industry page is the company you are. A team page is the job you do inside that company, and it hands the mechanics off to the other two instead of restating them.

Which is why the same reader often needs two of them: a construction platform and a payables platform sit in different industries, and their engineers ask exactly the same question about how many clients they have to write. What they have in common is the team, not the market.

By function FAQ

Common questions

Why are these pages split by team rather than by feature?

Because the same integration is bought for four different reasons, and the reasons do not translate. An engineer wants to know what is not built twice, a sales team wants to know whether a named system is supported, support wants to know which request failed for a customer, and finance wants a figure without waiting for an export. The capability pages answer what a thing is. These four answer what it is worth to you.

How is a team page different from a use case page?

A use case page explains one workflow end to end, from the read to the write, and it is the same workflow no matter who in the company cares about it. A team page starts from the reader and points at the workflows and capabilities that reader meets. The mechanics live on the use case pages and are handed off rather than repeated.

And how is it different from an industry page?

An industry page addresses the company you are, a team page addresses the job you do inside it. A construction SaaS and a payables platform are different industries whose engineers ask the same question about clients per system, which is why both axes exist and neither replaces the other.

Is every one of these four pages published?

Not yet, and the list does not hide that. All four are linked here, in the navigation and in the footer, because a page that is planned is still the canonical route: hiding a link until launch means going back to add it later, and that is how links get forgotten.

Which team should read which page first?

Whoever is evaluating. In practice the engineering page carries the technical detail on the data model, authentication and the sandboxes, so it is the one an evaluation usually starts with even when the budget sits elsewhere.

Build once on the Unified API.

See how one integration for every team works for your integration, or dive into the technical reference.