Debug faster with RequestRocket's built-in debugging tools

The debugging gap in gateway-proxied integrations

When a third-party API call fails, you typically have three sources of information: the error your application received, the vendor’s status page, and your application logs. None of these tell you what actually left your gateway, what the vendor returned, or which rule or filter might have modified the request in transit.

RequestRocket’s debugging tools are designed to close that gap. Every request processed by the gateway is logged, inspectable, and queryable — without any additional instrumentation on your part.

The request log

The request log is the primary debugging surface. Retrieve all requests for a proxy within a time window:

GET /clients/{clientId}/proxies/{proxyId}/requests
  ?processedAfter=2026-04-23T08:00:00Z
  &processedBefore=2026-04-23T09:00:00Z

The response includes a list of request records, each with:

• Request path and method.
• HTTP response status code from the upstream.
• Timestamp and processing duration.
• The credential used for the request.

This is your first stop: look at the status codes. A spike of 429 responses from the upstream tells a different story than a pattern of 403 — one is a rate limit problem, the other is an authentication or authorisation issue.

Inspecting individual requests

For a request that failed or behaved unexpectedly, retrieve the full record:

GET /clients/{clientId}/proxies/{proxyId}/requests/{requestId}

The individual request record shows the details of what the gateway received, what it forwarded, and what it received back. Request and response payloads are not stored — only metadata is logged. This is where you can see:

• Whether the request was blocked by a rule before being forwarded.
• Whether a filter transformed the request or response body.
• The exact path, headers, and timing of the forwarded request.
• The upstream response status code.

If a developer reports “my request is returning an unexpected response”, the request record tells you whether the gateway modified anything in transit — and what it changed.

Debugging rule and filter behaviour

Rules and filters can be hard to reason about without seeing them evaluate against real traffic. The request log is the evidence trail.

Scenario: requests to /v1/admin/users are being blocked

Check recent requests to that path:

GET /clients/{clientId}/proxies/{proxyId}/requests
  ?processedAfter=2026-04-23T00:00:00Z

If the requests show no upstream response (or a 403 status that came from the gateway rather than the vendor), a rule is blocking them. List the rules on that proxy to find the matching rule:

GET /clients/{clientId}/proxies/{proxyId}/rules

Compare the rule’s path.path.pattern against /v1/admin/users to identify which rule is matching. The rule’s notes field should explain the intent — if it doesn’t, adding notes to rules is a debugging investment that pays dividends.

Scenario: response body is missing expected fields

If a caller reports that fields are absent from the response, check the filters on the proxy:

GET /clients/{clientId}/proxies/{proxyId}/filters

Review the operations array on each filter. A destroy operation with a jsonPath pattern that matches the missing field is your culprit. Compare the pattern against the field path to confirm:

{
    "effect": "destroy",
    "jsonPath": { "pattern": "^user\\.internalId$" },
    "notes": "Strip internal user ID from response"
}

If the notes indicate this was intentional (e.g. stripping an internal field before returning to an external caller), the filter is working as designed.

Using telemetry to identify trends before they become incidents

The telemetry API aggregates request data by time interval. At minute-level granularity, you can see patterns that don’t show up in hourly views:

GET /clients/{clientId}/proxies/{proxyId}/telemetry
  ?interval=minute
  &limit=30

Useful debugging patterns:

• Sudden error rate spike at a specific minute — check if a deployment happened at that time, or if a rate limit was hit.
• Latency increase without error rate change — upstream API performance degradation.
• Zero requests for a period — confirms whether a service stopped calling the proxy entirely, which may indicate a deployment or config change on the caller side.

Client-level vs proxy-level telemetry

Client-level telemetry aggregates across all proxies:

GET /clients/{clientId}/telemetry?interval=hour&limit=24

Proxy-level telemetry scopes to a single integration:

GET /clients/{clientId}/proxies/{proxyId}/telemetry?interval=hour&limit=24

Start with client-level to get an overview — are all proxies behaving normally? Then drill into the specific proxy that shows an anomaly. This two-level approach means you’re not looking at per-proxy data for 20 proxies when the issue is with one.

Common debugging workflows

“Why is this proxy returning 401?”

1. Check the proxy’s proxyProxyCredentialId — is it pointing at the correct credential?
2. Check the credential’s credentialAuthType — does the caller know which auth type to use?
3. For jwtVerify credentials: verify the audience and issuer in credentialSecret match your identity provider’s token values exactly.
4. For key credentials: confirm the caller is sending Authorization: <key> in the correct format.

“Why is the upstream getting the wrong request?”

1. Check proxyAdditionalHeaders — are any headers being injected that might conflict with the caller’s headers?
2. Check proxyAdditionalQueryParams — any query parameters being added?
3. Review filters — does any filter have destroy operations on request body fields the upstream needs?

“Requests are going through but slower than expected”

1. Check the individual request record for processing duration breakdown.
2. Compare gateway processing time vs upstream response time to determine if latency is in the gateway or in the upstream.
3. Check proxyMaxRetries — if retries are occurring, each retry adds the full upstream round-trip time.

Next steps

The debugging tools described here are available on every proxy without any additional configuration. Read the RequestRocket documentation for the full request log and telemetry API reference, or start for free.