Most questions about a payments integration are not really questions about payments. They are questions about access. Which key ran that batch overnight. Why our partner saw a run of rejections last Tuesday. Whether anyone at Magellan has touched this account, and if so, what they touched. Whether the traffic hitting our credentials is coming from where we think it is.
Those are answerable questions, but historically you answered them by asking us, and we answered from logs you could not see. That is a reasonable way to run a support desk and a poor way to run an account you are accountable for. So we have made the underlying record yours: API Monitoring, in the portal, holding one entry for every authenticated request ever made against your account.
Know whether your integration is healthy
The first capability is the plainest one. At any moment you can establish how much traffic your account is taking, what proportion of it succeeded, how much failed outright, and how much was refused on permissions rather than broken — a distinction worth having, because a run of denials is a story about who is allowed to do what, and a run of server errors is a story about something being wrong.
Alongside that you can see the same success-and-failure split plotted over time, in counts or as a proportion, over windows from a day out to ninety. Which means you can tell the difference between a bad afternoon and a slow drift — and you can tell it yourself, at the moment you wonder, rather than a day later in a reply from us.
Answer questions without writing a query
The more useful capability is that every attribute of every request is something you can pivot the whole account on. Method. Status code. Outcome. The person or key behind it. The resources it touched. The route it called. The country and city it came from. The kind of actor it was. The merchant it was made on behalf of.
These compose the way you would want them to. Selecting several values of the same attribute widens the question; selecting across different attributes narrows it. So which endpoints is this one key being refused on, and has it always been? is a question you assemble in a few seconds rather than one you file a ticket about. Every aggregate on the page re-derives itself as you go, so the numbers you are reading always describe the slice you have actually selected — never the account as a whole with a filtered list beneath it.
One decision underneath makes this work at volume: we record the route that matched, not the URI that was called. Ten thousand calls about ten thousand different customers aggregate into a single meaningful row for /v1/customers/{customerId} instead of shattering into ten thousand useless ones. The identifiers are not lost — they are kept on the individual events, as structured resource references, which is what lets you ask the opposite question and pull up every call that touched one specific account.
Know where your access comes from
Credentials get shared, copied into places they should not be, and occasionally used by someone who should not have them. The usual reason this goes unnoticed for months is that nothing was watching the origin of the traffic, because nothing could.
Now the geography of your access is a first-class dimension. You can establish which countries your requests originate from and in what proportion, resolve any of them down to cities and individual source addresses, and see which of those addresses are failing rather than succeeding. Locations are derived from the forwarded client IP using MaxMind's GeoLite2 city data. It is all operable from the keyboard as well as the mouse, because a control that only half your team can use is only half a control.
The point is not that you will study this daily. It is that traffic from a country you do not operate in becomes something you can notice, instead of something you would have had to know to go and ask about.
Every request is accountable to someone
Underneath the aggregates, every individual request keeps a record, and that record is complete enough to close a question rather than open one: the outcome and its status code, when it happened, who the actor was and who it was performed by, the method and the route, the resources it touched as structured references, the source address, the city and country, the client that sent it, the environment it ran against, and two identifiers — one for the event, one for the trace.
The trace identifier is the one that earns its place. It is not a reference number we mint for the audit record; it is the live OpenTelemetry trace ID for that request, the same identifier our own engineers correlate on across services. Sending it to us is therefore a complete bug report rather than the beginning of one — it resolves to the same request everywhere it went.
And the record does not only live on a screen you have to remember to open. These events are produced at the edge, one per authenticated request, onto the same stream that drives webhook delivery — so the history can be pushed to you and kept alongside whatever you already run, rather than only browsed here.
People, keys, and us
Attribution is only worth having if it is honest about what it knows. An actor is one of three things, and they are never blurred together.
A person
Someone acting as themselves, attributed by their email address. The ordinary case, and the one you can put a name to immediately.
An API key
A machine credential, attributed by the name you gave the key — so you learn which key, not merely that a key was used. The email field stays deliberately empty here rather than being filled with whatever the token happens to claim.
Magellan support
When we act on your account, the record says so — performed by Magellan Support, on the event itself. Never quietly attributed to one of your users, and never absent from the history.
That third one is the capability we would most want if the account were ours. Support access is a normal part of running a payments platform and a bad thing to have to take on trust, so it is recorded like any other access, and it answers to the same questions as any other access.
Platforms get one dimension more. If you run sub-merchants, every call records the merchant it was made on behalf of as well as who made it, so the whole history of what was done for any one of your merchants is a single question. You can also scope the entire view to any subset of them. That boundary is enforced on our side rather than in the browser — no one widens their visibility by editing a URL.
The limits are deliberate
A feature that records every API call had better be exact about what it records. This one keeps metadata and nothing else. No request bodies. No response bodies. No query strings.
Headers are an allowlist of exactly two: the merchant identifier and the request identifier. Everything else is discarded where the event is created, before anything is written down. Authorization headers, cookies, webhook signing secrets — not redacted on screen, not stored behind a permission. They never reach the record at all, not even as a name with an empty value beside it.
The trade is real: you cannot reconstruct a request from this history. What you get instead is a complete account of who reached your platform and what they reached for, safe to hand to an auditor and safe to open in front of anyone. An audit trail people are nervous to look at is not one anybody ends up using.
Available now
API Monitoring is live in the portal today for admin roles, across your own account and any merchants beneath it. There is nothing to switch on and nothing to instrument — if you have been calling our API, the history is already there.
Read more about how we think about financial automation, browse the API documentation, or talk to us about access.