Unified logging and monitoring across every system, not one log per vendor
Every API call is logged in the same structured form: the endpoint, the response, the timestamp, the target system and the account key. The systems all answer differently, the record does not, and it shows that a transfer happened rather than storing what moved.
What is unified logging and monitoring
With one integration, debugging is a matter of reading two records: yours and the system's. The cost of adding the next system is not linear, because the question changes. It stops being what went wrong in our code and becomes where this went wrong, and every system answers that question in its own format, through its own portal or through none at all, on its own clock.
Unified logging and monitoring is what keeps that question answerable from one place. Every API call is logged in the same structured form, holding the endpoint that was called, the response, the timestamp, the target system and the account key. That is enough to reconstruct what happened at what time, for one tenant, across systems, without opening anything else.
Records are kept for 30 days on Start and Scale and 90 days or more on Enterprise, so how far back you can investigate is part of the plan you are on.
The word doing the work is unified. The systems' own responses and messages have nothing in common, and normalising them is what makes a single record shape possible at all, whether you read it in the Maesn portal or through the API. It is the same normalisation principle as the error envelope you already handle, applied to the trail a call leaves behind instead of to the answer it returns.
The question is rarely what broke, it is where
Four places to look when a sync fails, and each of them can only see part of it.
Your own logs show the call you made and the error you received. That is enough to know something upstream refused and not enough to know which of your customer's systems it was or what it objected to. The vendor's portal knows, if it has one and if the customer grants you access, which is two conditions that fail often. The customer knows something is wrong, usually last, usually in the form of a screenshot.
The real problem is the fourth card. Even with all three sources open, nothing connects them: no shared identifier, no shared clock and no shared vocabulary for what happened. That correlation work is where the hours go, and it grows with every system you support.
Five things, for every call
A log is only useful if every entry has the same shape, because that is what makes it searchable, comparable and countable. Maesn writes one record per API call with the same five fields whether the call went to a system with a modern REST API or to one that answers in files, which is the difference between a trail you can follow and a pile of vendor-specific messages.
It holds that a data transfer took place, not the data that moved. The payload itself is not stored.
The last strip is the part worth reading twice. The record establishes that a data transfer happened, with which endpoint, to which system, for which connection and when. It does not keep the payload, which is how this coexists with not storing customer data. You can prove what your integration did without Maesn holding what it moved.
The same trail, in your own logs
Six documented fields worth storing on your side, so your records line up with Maesn's instead of sitting beside them.
None of these needs a request of its own. If you store context alongside your own error records, a failed sync is already attributable to one system at one moment, and a support question becomes a lookup. That shift lands hardest with customer success teams, because the answer stops depending on who remembers the last incident. If you surface meta.warnings anywhere a user can see it, the field a target system silently ignores stops being a discovery you make in a report six weeks later.
Background work leaves the same kind of trail. An asynchronous operation reports its progress through the task it hands back, entry by entry rather than as a single verdict, and every webhook event names the object it concerned and arrives signed, so an event that surprises you can be traced to a record and to Maesn.
Watching the systems you did not build
The failures that hurt most in an integration business are the ones at a vendor you have no account with. A system is slow for an hour, an endpoint returns errors after a release, a maintenance window nobody told you about lands in the middle of your nightly sync. You find out from a customer, which is the worst available channel.
Maesn learns about an outage from the vendor rather than from an alert of its own and passes it on to the tenants running on that system, so the notice does not have to start with your customer. What reaches your application is not silence but a typed error: a system that is temporarily unavailable arrives as a 503 with the service_unavailable type.
Retrying and pacing are narrower than that. Maesn retries and paces on the asynchronous endpoints. Everything synchronous passes the target system's 429 straight through, so the backoff and the schedule stay yours. That is the difference between a sync you can retry deliberately and one that disappeared.
One question, one place to answer it
- Correlate your logs with each portal
- Guess which system a failure came from
- Learn about outages from customers
- Discover dropped fields in a report
- The system named in the response
- Requests, responses and webhooks logged
- Connected systems watched for you
- Ignored fields named as warnings
Support cost is the quiet part of an integration's total cost. It does not appear in the build estimate, it arrives afterwards, and it scales with the number of systems and the number of customers rather than with the amount of code. The single biggest lever on it is being able to answer where something happened without asking anybody.
That is why the system is named in the response rather than left for you to infer, and why a field a system does not use is reported as a warning instead of dropped in silence. It is the same principle as the common data model: the differences between systems are absorbed, and the ones that still matter to you are made visible on purpose.
Common questions
What exactly does Maesn log?
How long are the records kept?
Do the logs contain our customers' data?
Why does a unified log matter more than a log?
How do I tell which system a failure came from?
Can I see what the target system itself said?
How would I know a field was ignored?
How do I follow a long running operation?
Are webhook events traceable to a record?
What happens when a connected system has an outage?
Why does this matter more with a Unified API than with one integration?
Build once on the Unified API.
See how unified logging and monitoring works for your integration, or dive into the technical reference.