api/{debug}

See exactly
where your API fails.

Diagnose the real failure layer across DNS, TCP, TLS, request, and server timing so you can stop treating every API error like a mystery.

Start Debugging

Run the local agent.

Start the local agent with Docker using the command below. This setup keeps the UI talking to 127.0.0.1:8080 and lets the agent reach host localhost services from inside the container.

docker run -d \
--name apidebug-agent \
--add-host=host.docker.internal:host-gateway \
-p 127.0.0.1:8080:8080 \
-v apidebug-agent-data:/data \
--restart unless-stopped \
apidebug/apidebug-agent:latest

Debugging APIs is still too opaque

Most tools confirm that a request failed. They do not explain which layer broke, how far the request got, or what evidence supports the diagnosis.

Every failure looks the same

Timeouts, TLS errors, DNS issues, and backend failures often collapse into the same vague request error.

Most tools stop at the symptom

You get a status code or a generic failure message, but not the network phase that actually broke.

Guesswork burns engineering time

Teams retry, disable TLS, switch networks, and compare headers before they know what actually failed.

The model

Treat every request like a network path.

Apidebug breaks the request lifecycle into concrete stages so you can explain what happened in operational terms, not just application symptoms.

DNSTCPTLSServer
  • Pinpoint the failure stage instead of reading a generic timeout.
  • Measure handshake and response timings across the request path.
  • Preserve diagnostics and analysis reports for later review.
Timeline breakdownPrimary bottleneck: TLS
DNS lookup18ms
TCP connect34ms
TLS handshake162ms
Server responseNot reached

Debug in 3 steps

1

Send the request

Run the real API call through Apidebug instead of reproducing it with stripped-down test traffic.

2

Inspect each layer

Review DNS, TCP, TLS, request, and server timing to see where the lifecycle slowed down or failed.

3

Act on the diagnosis

Use the analysis report, diagnostics, and saved history to explain the issue and rerun with confidence.

Built for real failure analysis

The feature set should help you explain what failed, how it failed, and what to do next.

Failure-stage pinpointing

Identify whether the request broke at DNS resolution, TCP connect, TLS handshake, request write, or server response.

DNS -> TCP -> TLS -> Server

Frame each run as a network path instead of a single success-or-fail event.

Timing and lifecycle analysis

Surface handshake timings, latency segments, and bottlenecks across the request path.

Diagnostics and reports

Capture supporting diagnostics, explanations, and exported analysis details when you need evidence.

Local execution by design

Apidebug runs through a required local agent on your machine, which also gives it access to localhost, VPN-only, and internal environments, including host localhost services reached from the Dockerized agent.

Saved runs and history

Keep request history, stored folders, and repeatable runs close to the analysis trail.