Check Mercury transactions and webhooks while you debug a payment-handling bug

Last verified on Nov 8, 2026.

Most production bugs involving a bank are really bugs in how your code reacts to money movement: a webhook handler that throws, a reconciliation job that counts a transaction twice, a payout your system never recorded. The bank's side of that story is a list of transactions and a list of webhook endpoints. With Mercury connected, the Sazabi agent can read both while it searches your logs, so you can check whether the transaction your code failed on actually exists.

What the Sazabi agent can do with Mercury

There are two ways to connect, each configured separately.

The MCP connector uses Mercury's hosted server at mcp.mercury.com/mcp, authorized over OAuth. Sazabi's docs call the connector read-only, and Mercury's read tools all fall under its read scope. The ones that matter for debugging:

• listTransactions filters by date range, status and category, with cursor pagination, and getTransaction returns one transaction by ID.
• getWebhooks lists your webhook endpoints, filterable by status, and getWebhook returns one.
• getAccounts, getAccount and getAccountCards describe accounts and their cards, and listCards and getCard cover cards directly.
• getCashflowSummary returns monthly money in, money out and net cashflow for up to 12 months, excluding transfers between your own accounts.
• getRecipients, getTreasury and getOrganization fill in the surrounding records.

Mercury's server also defines write tools, such as requestSendMoney and updateTransaction, which need their own OAuth scopes. Mercury says payments and transfers still need approval inside Mercury. The Sazabi page documents a read-only connector, so grant only the read scope when you authorize.

The mercury CLI runs in the agent's sandbox with a MERCURY_API_KEY and gives read-only access to the banking API, for cases where you want the agent to script a few calls.

Mercury labels its MCP server a beta, so confirm anything important in Mercury itself.

Questions it answers

• Does Mercury have a transaction for this amount and date that our system never recorded?
• Which webhook endpoints are registered, and are any not active?
• Which card paid for this vendor charge, and which account is it on?
• What did cashflow look like in the months around this billing change?
• Is this recipient known to the organization?

A worked example: a webhook handler that started throwing

Your logs show errors from /webhooks/mercury: your handler fails to parse an incoming payload. You ask in the thread:

Our /webhooks/mercury handler has thrown 400s since 08:40 UTC. Check which
Mercury webhook endpoints are registered and their status. Then list Mercury
transactions from 08:00 to 09:00 UTC and tell me which ones we never logged a
successful webhook for.

The agent starts in your logs, collecting the request times and the transaction IDs your handler printed before it failed. It calls getWebhooks to see the endpoints and whether the one pointing at your URL is active. Then listTransactions over the same hour gives it Mercury's list, and for any transaction your logs never mention, getTransaction returns the detail, such as amount, counterparty and status.

The comparison narrows where to look. If the endpoint is missing or inactive, the fix is in Mercury's settings and not a deploy. If it is registered and active, Mercury meant to deliver, so look at your handler's errors around each transaction your logs never mention. A transaction with no request at all in your access logs points at delivery, not parsing; a request that arrived and threw points at your code. An active endpoint alone doesn't prove a delivery happened. The agent can only report this. It will not change the endpoint.

How it fits with other integrations

If a payment processor sits between you and the bank, the Stripe page covers reading that side, and Autumn covers a billing layer on top of it. Findings can go to Slack or into a Linear ticket. The integrations index lists every method and pricing lists the plans.