HTTP Debugger
An HTTP Debugger in the Salesforce context is any tool that captures, inspects, and replays HTTP requests and responses traveling between Salesforce and an external system.
Definition
An HTTP Debugger in the Salesforce context is any tool that captures, inspects, and replays HTTP requests and responses traveling between Salesforce and an external system. Developers use HTTP debuggers when diagnosing integration failures: a callout returns the wrong status code, an inbound API call posts the wrong payload, an OAuth handshake stalls midway, or a Salesforce Connected App rejects a SAML response. The debugger surfaces the raw HTTP exchange so the developer can see exactly what was sent and received.
Salesforce ships a small set of native debugging tools (Apex Debug Logs with Callout filter, the Developer Console Logs tab, the Salesforce Workbench REST Explorer) that show the Salesforce side of any HTTP exchange. For the external side, developers reach for third-party debuggers (Postman, Charles Proxy, Fiddler, mitmproxy, Wireshark, Chrome DevTools Network tab). The combination is mandatory for any non-trivial integration work, because a callout failure rarely tells you which end is misbehaving until you compare both sides of the wire.
Which debugger to reach for at each layer of an integration
Apex Debug Logs for outbound callouts
Setup, Debug Logs, add a trace flag on the user making the callout. Open the log after the callout runs; the System.HttpRequest and System.HttpResponse lines show the full URL, method, headers, and bodies on both sides. Apex Debug Logs are the canonical place to start when diagnosing an Apex-initiated integration. The log is per-user and time-bound, so trace flags expire after a set duration.
Workbench and the REST Explorer
Workbench (workbench.developerforce.com) is a web tool maintained by the developer community that lets developers issue arbitrary REST calls to a Salesforce org. It is the fastest way to test a Salesforce REST endpoint with custom headers, parameters, and bodies. The Workbench REST Explorer shows the full request and response, mimicking what a third-party tool would.
Postman for external API testing
Postman is the de facto HTTP debugger for testing external APIs from a Salesforce perspective. Build a collection that mirrors the calls Apex makes; run them with the same credentials and headers Apex would use. When Postman gets a different response than Apex did, the gap is in Apex code or Named Credential configuration; when both produce the same wrong response, the gap is in the external API. Postman is also useful for testing Salesforce inbound REST API endpoints.
Charles Proxy and Fiddler for over-the-wire inspection
Charles Proxy and Fiddler are full HTTPS proxies. Configure your local Salesforce CLI or developer machine to route traffic through the proxy, and every request and response is captured. These tools are essential when the issue is not in the callout itself but in some intermediate layer (a CDN rewriting headers, a corporate proxy stripping cookies, a TLS cipher mismatch). Setting them up requires installing a root certificate to decrypt HTTPS.
mitmproxy for headless and CI environments
mitmproxy is the command-line equivalent of Charles. It runs on Linux, captures HTTPS traffic, and exposes a Python API for scripting filters and transformations. Use it when debugging an integration that runs in CI (Apex tests calling a sandbox endpoint, Heroku app calling Salesforce) where a GUI debugger is not available.
Browser DevTools for Lightning and Visualforce
Chrome DevTools Network tab captures every HTTP call the Salesforce UI makes. For Lightning Web Components calling @AuraEnabled methods, this is where the request and response live. For Visualforce pages making AJAX calls, same answer. The Network tab also shows the timing breakdown, which surfaces performance issues that the Salesforce side alone never sees.
Logging callouts in production safely
Production diagnostics need to be light-touch. Apex Debug Logs are limited in production by retention and visibility; persistent logging requires a custom logging framework (Log__c custom object, an APM tool like New Relic, or a Splunk integration). For HTTP callouts, the common pattern is to log the URL, status code, and a hash of the body, never the body itself when it contains PII or credentials.
Trace an outbound Apex callout end to end
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.
Trust & references
Cross-checked against the following references.
- Debugging ApexSalesforce Developers
- Apex HTTP CalloutsSalesforce Developers
Straight from the source - Salesforce's reference material on HTTP Debugger.
- Set Debug Log FiltersSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is an HTTP Debugger?
Q2. What's a common HTTP debugger for Salesforce?
Q3. Why is HTTP debugging important for integrations?
Discussion
Loading discussion…