Poll Remote URL
The 'Wait Until Your Cloud Job Is Done' Node
- passthrough
- PASSTHROUGH
- STATUS_CODE
- RESPONSE_BODY
A lot of external services work the same way: you submit a job, they hand you a task ID, and the actual result shows up somewhere else, minutes later. Poll Remote URL is the glue that sits in that gap. It keeps hitting a URL - politely, at a fixed interval - until the response matches what you're waiting for, then lets the rest of the workflow continue. It's the missing "check back later" step for any async API you've ever wired into ComfyUI.
The pattern to use it with: kick off a job with Call Remote URL (or one of the API-wrapper nodes from the ecosystem), get a task ID back, then point Poll Remote URL at the status endpoint. It's the same submit-then-poll shape every cloud job service uses, so once you've built it once it transfers anywhere.
The inputs that decide the behavior
url,method- what to hit and how (GET, POST, PUT, DELETE, HEAD, PATCH).match_type- how to judge the response:string- true whenmatch_valueis a substring of the response.regex- true whenmatch_valueas a regex pattern matches the response.json- true whenmatch_value(parsed as JSON) is a subset of the response JSON. Note the author's caveat: the subset check is structural and path-aware, so to match{"status": "ok"}inside{"data": {"status": "ok"}}, your match value must include the full path:{"data": {"status": "ok"}}.
match_value- the thing to match.invert_match- set it and the node waits until the match is false. This is how you wait for something to disappear, which is harder to do in most tools than you'd think.passthrough- any type, echoed to the output for execution ordering.body,headers(optional) - request payload and JSON-string headers.max_attempts- default 30 (min 1, max 1000).delay_ms- default 500, the pause between attempts.
Outputs are PASSTHROUGH, plus STATUS_CODE and RESPONSE_BODY from the last attempt.
Time math and troubleshooting
Do the arithmetic up front: 30 attempts × 500 ms is a 15-second default budget. A slow job that needs two minutes will exhaust it, and the node will not error out - it just returns the last status and body it got, unmatched. So the standard debugging move is to wire RESPONSE_BODY into a Map JSON To Property or a text preview node and see what the endpoint was actually saying when the polling gave up. Nine times out of ten it's "still processing," and the fix is raising max_attempts or delay_ms, not anything wrong with the node.
Two more things from the source worth knowing: a bad regex pattern doesn't crash, it just never matches (and logs to the console), and an exception during an attempt is swallowed and retried - so if the URL is dead you'll wait out the full attempt budget staring at a STATUS_CODE of 0.
Install
It's in comfyui-sg-nodes by sebagallo. ComfyUI Manager → search comfyui-sg-nodes, or git clone https://github.com/sebagallo/comfyui-sg-nodes into ComfyUI/custom_nodes, then restart. Shows up under SGNodes/Network. No model downloads; the only dependency (requests) is already bundled with ComfyUI.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| passthrough | COMFY_MATCHTYPE_V3 | Any type, passed through to output. | |
| url | STRING | Target URL string. | |
| method | COMBO | HTTP method (GET, POST, etc.). | |
| match_type | COMBO | Type of matching to perform (string, regex, json). | |
| match_value | STRING | The value to match against. | |
| invert_match | BOOLEAN | false | If True, waits until the match condition is FALSE. |
| bodyopt | STRING | Request body string. | |
| headersopt | STRING | {} | JSON string of request headers. |
| max_attemptsopt | INT | 301–1000 | Maximum number of polling attempts. |
| delay_msopt | INT | 5000–60000 | Delay between attempts in milliseconds. |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| PASSTHROUGH | COMFY_MATCHTYPE_V3 | — |
| STATUS_CODE | INT | — |
| RESPONSE_BODY | STRING | — |