All posts

FourA Digest — Jun 5 to Jun 12, 2026

Click any Activity row to see the full payload, then reopen it in Playground prefilled. New honeypot guard catches proxies echoing requests as fake responses.

Highlights

Click any request in Activity now and you'll see the full payload. One more click opens it back in Playground, prefilled, ready to re-run. We also caught a class of "proxy" that echoes your own request back as a fake response, and stopped it from polluting your data.

What's New

Activity → Playground: replay any request

Every API call ships back with an X-Foura-Request-Id header. The same id shows up next to the request in Activity. Click any row and you get the full picture: when it ran, which key made it, the request body, the response, the status codes, and the time it took. Click "Open in Playground" and the request loads into the form, prefilled.

Replay used to mean rebuilding the request from memory. Now Activity holds the history, and Playground is the rerun button.

A few mechanics to know. We keep the last 200 payloads per API key for 24 hours. After that, older entries fall off as new ones come in. When a payload has aged out, the dialog tells you, instead of showing a confusing null or "(empty body)" the way it used to.

A request id you can correlate, too. Log the X-Foura-Request-Id response header next to your own request id on the client side, and finding the matching Activity row later takes one paste.

The capture sits off the hot path. Your API request never waits on it. And if the capture store is unreachable, the call still goes through; the dialog just says "no body captured" later.

Validate against the response body

Playground's Validate section gained body-content rules. You can say "succeed only if the response contains X", or "fail if it contains Y", with multiple alternatives separated by |. Works for Single and Proxy. Useful when status codes lie about what actually happened.

Bodyless payloads explain themselves

Failed requests don't have a response body to show. The old dialog rendered that as null or "(empty body)", which was easy to misread as a real empty response. The dialog now distinguishes three cases: the request failed (with the actual error message), no payload was captured, or the server really did return zero bytes.

Small thing, but it removes a recurring "wait, was that the response or a UI bug?" moment.

Reset button in Playground

Brings the active endpoint's form back to defaults in one click. Defaults keep unblocker and tryJsonData on, since that's the 90% path.

Under the Hood

Honeypot proxy detection

Some "proxies" in the wild don't actually forward. They echo your own request back as a plaintext server-variables dump (the HTTP method, the headers, the target host) so the operator can harvest whatever was in it. We've seen the same proxy forward one request, echo the next, and 502 the one after that, all inside a single session.

The body validator now spots the dump's signature before the response leaves our edge. Single returns an honest failure. Proxy Finder retries with a different proxy. Browser inherits the same guard from the shared HTTP layer. So you'll see fewer garbage rows in Activity, and your scrapers won't ingest something that looks like data but is actually a probe.

No reputation change yet. The proxy stays in the pool for now. We just refuse to return its lie to you.

So: if a request lands in Activity tagged as a hard failure where it used to look like a thin "success", that's the guard catching it. Better a clean fail than a poisoned record.