HTTP traffic
Every request the game makes, captured, replayable, and overridable.
HTTP capture is kept separate from the remote spy, because they answer different questions. Remote traffic is the game talking to its own server; HTTP is the game talking to everything else.
What gets captured#
Both shapes of HTTP:
game:HttpGet,HttpService:GetAsyncand friends, hooked as functionsrequest/http_request/syn.request, captured off-thread
Each record holds the URL, method, headers, body, status, response body, response size, and how long it took.
Replaying a request#
Any captured request can be fired again, verbatim, and the fresh response is shown next to the original. That is how you find out whether an endpoint is still live, whether a token has expired, or what changes between two calls.
Replay uses the executor's own request function, so it carries the same
cookies and headers the game would send.
Overriding a response#
You can intercept requests by URL substring and return your own response instead of letting the call go out:
| Field | Meaning |
|---|---|
match | A substring of the URL. The first matching rule wins. |
status | The status code to return |
body | The body to return |
headers | Response headers |
The game receives your response as though the server sent it. This works for
both the direct HttpGet family and the request family.
What this is for
Mocking a paywall check, testing how a script handles a 500, or seeing what a game does when its config endpoint returns something unexpected. It is the fastest way to answer "what happens if…" without touching the game's code.
Why it is separate from the remote spy#
They fill up at completely different rates. A game might fire two hundred remotes a second and make four HTTP calls a minute. Mixed into one stream, the HTTP calls are invisible.
Keeping them apart also means you can leave HTTP capture on permanently — it costs almost nothing — while remote capture is something you switch on for a specific question.