Loading

The Outbound Log

Outbound calls can be logged. Unlike the inbound request log, this one stores the full request and response bodies.

Where to find it

Architect Panel → Configuration:

  • Site Settings — Log outbound API client calls

Architect Panel → Integration & Connections:

  • API Clients — the clients and actions being logged

Architect Panel → Security:

  • Permissions — who can read the log

What is recorded

  • The client and the action.
  • The URL called and the headers sent.
  • The full request body.
  • The full response.

Why it needs the bodies

Because diagnosing somebody else's API requires them. A status code tells you a call failed; only the response tells you the supplier rejected a date format, or returned a success wrapper containing an error, or sent a field their documentation never mentioned.

Without the bodies, an outbound integration problem is a guessing exercise conducted through a supplier's support desk.

Which is exactly why it ships off

Full bodies mean the log contains whatever you send and receive — including personal data. An action submitting a customer's details logs those details in full, alongside the headers, which may include credentials.

This is a substantially more sensitive store than most logs, and it is easy to forget it is on.

Turn it on to debug, and off again

That is the intended pattern, and it is worth being disciplined about because nothing will remind you. Enable it while commissioning or investigating, get what you need, turn it off.

A log left on for a year against a busy integration is a large archive of personal data you never decided to keep.

If you must leave it on

Where an integration is genuinely unstable and needs standing visibility:

  • Restrict who can read it to named administrators.
  • Set a short retention — days, not months.
  • Include it in your record of what personal data you hold.
  • Diary a date to reconsider.

Mind the headers

Headers carry authentication. Anyone who can read this log can potentially read a credential for the supplier's system — so treat read access to it as equivalent to access to that credential, and rotate the credential if the log has been shared more widely than intended.

Take extracts, not screenshots

When sending evidence to a supplier's support team, send the specific exchange rather than a broad export, and check what is in it first. It is easy to send a customer's details to a third party's helpdesk while trying to demonstrate a formatting problem.

The inbound log is different

The inbound request log records metadata — key, datastore, method, outcome, row count, duration — and not bodies. It is safe to leave on permanently, and is. Do not reason about the two the same way.

Worked example

An integration starts failing intermittently. Outbound logging is enabled for an afternoon, and the captured responses show the supplier returning a rate-limit message inside a 200 response. The fix takes an hour, the extract sent to the supplier is trimmed to two exchanges with the customer name removed, and logging goes off the same day.

Recommendations

  • On to debug, off afterwards — every time.
  • Treat read access as credential access.
  • Check extracts before sending them to a supplier.
  • Never reason about it like the inbound log — it holds far more.