Skip to main content
Monthly request quota and log retention both depend on your plan:Logs older than your retention window are automatically deleted. Upgrade your plan before the window closes if you need to keep a specific log entry.
For Sync API and Async API endpoints, getrequest’s own processing overhead is negligible — in practice, the latency you see is driven by your network path and the underlying AWS infrastructure, not by getrequest itself. The destination timeout (3 seconds for Sync API, 10 seconds per attempt for Async API) is on your backend, not on getrequest.For Static API endpoints, there is no destination call — the response is returned directly from edge infrastructure, so overhead is minimal, though actual latency still depends on your network and the infrastructure it’s hosted on.
Sync API endpoints wait up to 3 seconds for your destination to respond. If it exceeds that, getrequest returns 504 Gateway Timeout to the caller. The request is still logged with the timeout noted, and you can replay it once your backend recovers. Async API endpoints instead retry automatically — see Sync vs. Async endpoints.
Yes. getrequest forwards any request body, including binary data. Binary payloads are base64-encoded in storage. The maximum body size is 1 MiB for Sync API and Static API.For Async API, the enforced cap is 200 KiB, but that check measures your original (decoded) file size, not what it becomes once base64-encoded for the delivery queue — base64 inflates size by about a third. For a binary payload specifically, stay under roughly 180 KiB to leave safe margin; right at 200 KiB, the request can be silently dropped after already returning 202 to the caller. See Limits, timeouts & error responses for exactly why. Text/JSON payloads aren’t affected by this — they aren’t re-encoded, so the full 200 KiB is genuinely safe for those.
No. A Destination URL can’t resolve to a private, loopback, or link-local address — including cloud metadata endpoints like 169.254.169.254. This is enforced both when you save the endpoint and on every live request (since a public hostname can be repointed to a private address via DNS at any time), and it applies to Replay too. See Limits, timeouts & error responses for the exact blocked ranges.
Sync API proxies inline and returns your destination’s exact response to the caller. Async API acknowledges the caller immediately (202) and delivers to your destination in the background, retrying automatically up to 6 times over about 36 minutes if it fails. Async API is the better fit for webhooks and anything else where the caller doesn’t need to wait on — or see — your actual response. Neither is plan-gated. See Sync vs. Async endpoints.
Yes, both. Authentication verifies the caller hitting your endpoint (Bearer, API Key, Basic Auth, or HMAC) before getrequest processes the request. Destination Authentication attaches a credential to the outbound call getrequest makes to your backend. Neither is plan-gated. See Authenticate endpoints and destinations — including an important note on how these secrets currently appear in captured logs.
On Free, further requests are blocked with HTTP 429 Too Many Requests until the cycle resets or you upgrade. On Dev, Pro, and Gro, you’re not cut off at the quota — overage is billed automatically instead, up to a ceiling; only past that ceiling do requests start getting blocked. Either way, a blocked request is still logged so you can see exactly what was affected. Upgrade to restore full access immediately — mid-period upgrades are prorated.
No. Request replay requires Pro or Gro. On Free and Dev plans, you can view and inspect all captured logs but cannot re-fire them.
Yes, two ways, both requiring Pro or Gro: select specific rows in Logs and click Retry Selected (up to 100 at once), or apply a filter and click Bulk Retry Matching Requests to sweep up everything matching it as a background job, with no size cap. The Retries page also auto-groups recurring failures so you don’t have to build the filter yourself. See Bulk retry & recovering many requests.
Yes. Create a separate project for each environment, with its own set of endpoints. Each endpoint gets its own unique URL regardless of which project it’s in, so there’s no naming to keep in sync across environments.
Team access is coming soon. Currently, each account has its own projects and endpoints. Share log links with teammates in the meantime — they can view the full request and response without needing access to your account.
Yes. Sync API and Async API endpoints are used in production by teams that need full request visibility and replay capability. getrequest is built on AWS API Gateway and Lambda, designed for high availability and low latency.