Jedes System, ein Common Data Model
Maesn normalisiert Antworten, Formate und Strukturen über jedes ERP- und Buchhaltungssystem, damit Sie gegen ein einziges Schema bauen statt gegen Dutzende. Wo ein nativer Endpunkt nicht reicht, macht Maesn die zusätzlichen Aufrufe und schließt die Lücke, bevor die Antwort bei Ihnen ankommt.
Was ist ein Common Data Model
Eine Unified API bietet eine standardisierte Menge von Endpunkten über viele Systeme derselben Kategorie und normalisiert die Daten jedes Systems in gemeinsame Schemata. Statt die Datenformen jedes ERP zu lernen, bauen Sie eine einzige Codebasis und erhalten immer gleichbleibende, normalisierte Daten, welches System Ihr Kunde auch fährt.
Die Normalisierung geschieht auf Ebene des Schemas, nicht nur beim Feldnamen. Maesn gleicht Feldnamen, Datentypen, Datums- und Währungsformate und die Beziehungen zwischen Objekten an, sodass eine Rechnung, ihre Positionen und ihr Kontakt in jedem System gleich zusammenpassen. Das trennt ein Common Data Model von einer bloßen Abbildung Feld für Feld: Sie bauen einmal gegen eine vorhersehbare Struktur, statt die Eigenheiten jedes Systems bei jeder weiteren Anbindung selbst auszugleichen.
Jedes System modelliert Daten anders
Dieselbe Rechnung sieht in jedem System anders aus: andere Feldnamen, Datumsformate, Währungsbehandlung und Objektstrukturen. Für jedes davon eine eigene Abbildung zu bauen und zu pflegen, dort bleiben Integrationsprojekte stecken.
Und der Unterschied liegt nicht nur in den Daten. Nicht jedes System spricht REST: Manche sind SOAP, manche bieten GraphQL, manche sind XML-RPC oder JSON-RPC. Teile mancher Systeme werden gar nicht angefragt, sondern als Dateien ausgetauscht, als XML oder CSV. Eine einzige Anbindung über eine Handvoll Systeme kann deshalb vier Übertragungstechniken bedeuten, bevor ein einziges Feld abgebildet ist. Odoo ist das klarste Beispiel im Katalog: Es hat gar keine REST-API, und es zu erreichen heißt RPC. Hinter Maesn kommt alles davon als eine REST-Schnittstelle an, XML zu parsen, CSV-Exporte zu lesen oder ein GraphQL-Schema zu lernen wird also nie Ihr Problem.
Normalisiert, ISO-normiert und vollständig
Nur einige Beispiele. Maesn normalisiert weit mehr, über jedes Feld, Objekt und System hinweg.
Xero liefert es als currencyCode, sevdesk als currency, und Lexware Office hat gar kein Währungsfeld, weil es nur Euro unterstützt. Maesn gibt das Feld currency immer mit dem richtigen Wert zurück.
Ein normalisiertes Schema
Antworten, Formate und Strukturen sind über alle Systeme normalisiert, sodass jede Anbindung, die Sie bauen, sich gleich verhält.
Multi-Calling im Hintergrund
Wo ein nativer Endpunkt nicht alles liefert, macht Maesn die zusätzlichen Aufrufe selbst und setzt ein vollständiges Objekt zusammen.
ISO-Normen durchgesetzt
Ländercodes folgen ISO 3166-1, Währungen ISO 4217 und Datumsangaben ISO 8601, geprüft auf dem Hin- und auf dem Rückweg.
Gesagt, was ein System übergeht
Nutzt ein Zielsystem ein gesendetes Feld nicht, sagt die Antwort es in meta.warnings, statt das Feld still zu verwerfen.
Automatische Datumskonvertierung
Senden Sie ein Datum oder einen vollen Zeitstempel. Maesn wandelt ihn in das um, was jedes System erwartet, ergänzt Mitternacht UTC oder streicht die Uhrzeit.
{"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 } }}
Vollständige Objekte, für Sie zusammengesetzt
Manche Systeme liefern aus einem einzigen Endpunkt nie ein vollständiges Objekt, und ein Kontakt ist der klarste Fall. Ein System hält die Gesellschaft, ihre Ansprechpartner, deren Adressen, deren E-Mail-Adressen und deren Telefonnummern hinter fünf getrennten Endpunkten. Ein anderes liefert alles aus einem. Dasselbe Objekt, dieselbe Kundenfrage, zwei völlig verschiedene Mengen Arbeit.
Maesn erledigt diese Arbeit im Hintergrund. Sie rufen einen /contacts-Endpunkt auf. Dahinter reicht Maesn die Anfrage entweder an den einen nativen Endpunkt weiter oder macht die fünf Aufrufe in der richtigen Reihenfolge und den richtigen Formaten und setzt das Ergebnis zusammen, bevor es Ihren Code erreicht. Was ankommt, ist ein Kontakt mit seinen addresses, contactPersons, emailAddresses und phoneNumbers, aus welchem System er auch kam. Das Multi-Calling, die Reihenfolge und das Zusammensetzen bleiben auf Maesns Seite.
"data": [{
"id": "92c4f3a2-5b8e-4d1b-…",
"companyName": "maesn",
"addresses": [ … ],
"contactPersons": [ … ],
"emailAddresses": [ … ],
"phoneNumbers": [ … ]
}]Ein Modell, weniger zu pflegen
- Jede Datenform von Hand abbilden
- Logik für jede Systemeigenheit verzweigen
- Neu abbilden, sobald ein System seine API ändert
- Für jedes neue System neu bauen
- Gegen ein Schema bauen
- Keine Verzweigung je System
- Änderungen am Quellsystem für Sie abgefangen
- Neue Systeme automatisch dabei
Unterschätzt wird nicht der Bau, sondern die Jahre danach. Ein Zielsystem ändert ein Feld, benennt einen Endpunkt um oder ändert ein Format, und eine direkt dagegen gebaute Anbindung bricht. Entweder Sie verfolgen jede Freigabe am Quellsystem, um vorne zu bleiben, oder Sie erfahren es, wenn ein Kunde Ihnen sagt, dass seine Daten nicht mehr abgeglichen werden. Bauen ist eine Frage der Marktreife; bei der Pflege sammeln sich die Kosten, und über die Lebensdauer einer Anbindung ist sie meist die größere Hälfte.
Das ist die Hälfte, die Maesn abfängt. Die Systeme, mit denen Maesn zusammenarbeitet, melden Änderungen, bevor sie greifen, und die Arbeit, ihnen zu folgen, passiert auf Maesns Seite der Schnittstelle und nicht auf Ihrer. Wie gut das gehalten hat, ist eine prüfbare Tatsache und kein Versprechen: Maesn steht weiterhin bei der ersten Version seiner API, es wurde Ihnen also nichts weggenommen, wogegen Sie gebaut haben. Sollte ein brechender Wechsel je unvermeidlich sein, ist die Absicht, ihn vorher anzukündigen und die neue Form neben der alten zu veröffentlichen statt an ihrer Stelle, sodass die Migration in Ihrer Planung landet und nicht in einem Vorfall.
Das Common Data Model deckt bewusst die Felder und Objekte ab, die alle Systeme teilen. Braucht ein Kunde etwas außerhalb davon, stecken Sie nicht fest. Customisation Handling erreicht alles jenseits des Modells: Authenticated Passthrough ruft jeden Endpunkt im System direkt auf, und Raw Data gibt vollen, ungefilterten Zugriff auf das, was das System liefert. Nichts ist weggesperrt, das Modell bleibt also sauber, ohne zu begrenzen, was Sie bauen können. Ein Modell, das über Systeme hinweg trägt, ist das, was Produkt- und Entwicklungsteams tatsächlich kaufen, wenn sie sich für eine Unified API entscheiden.
Häufige Fragen
Was normalisiert Maesn?
Was, wenn ein System ein Feld hat, das das Common Data Model nicht abdeckt?
Woher weiß ich, ob ein System ein gesendetes Feld wirklich genutzt hat?
Sind neue Systeme automatisch abgedeckt?
Wie werden Datumsangaben und Währungen behandelt?
Brauche ich weiterhin Logik je System?
Wie unterscheidet sich das Common Data Model vom Field Mapping?
Verliere ich durch die Normalisierung den Zugriff auf etwas?
Was passiert, wenn ein System seine API ändert?
Einmal bauen, auf der Unified API.
Sehen Sie, wie das Common Data Model für Ihre Integration funktioniert, oder steigen Sie in die technische Referenz ein.