The standard debugging loop combines Salesforce-side Debug Logs with external-side Postman replays. Walk through it once and the pattern becomes reflex.
- Enable Debug Logging on the user
Setup, Debug Logs, click New, pick the user making the callout, set the level to INCLUDE callouts, save. The trace flag is active for the chosen window.
- Run the callout
Trigger the Apex method that makes the callout. Wait a few seconds for the log to be written.
- Open the log
Setup, Debug Logs, click the latest entry. Search for HTTP_REQUEST or CALLOUT_REQUEST events. The log shows the full URL, headers, and body on the way out.
- Inspect the response
Find the CALLOUT_RESPONSE event. The status code, headers, and body show what the external system returned.
- Replay in Postman
Build a Postman request with the same URL, method, headers, and body. Run it. Compare the response to what the log shows. Differences point to the source of the bug.
- Iterate
Adjust Apex (or external configuration) based on the Postman comparison. Re-run, re-log, re-compare until the responses match expectations.
- Apex Debug Logs can hit the 20-MB-per-log limit on heavy-traffic transactions. Bodies are truncated; you may not see the full callout payload in the log.
- Postman uses your local network and OAuth tokens, not Salesforce''s. A Postman call that succeeds where Apex fails often means the failure is in Named Credential, proxy config, or platform IP allow-lists.
- Charles and Fiddler require installing a root certificate to decrypt HTTPS. Forgetting to clean up the certificate after the debug session is a security risk on shared machines.
- Production debugging requires explicit user permission. Adding trace flags on production users without coordination is an audit finding waiting to happen.