How to Solve CAPTCHA in Make.com Without a Code Step

A Make.com captcha step is three HTTP modules and a Sleep, with no code anywhere in the scenario. Submit the challenge, wait, poll until the token comes back, then send it with the form. The part that actually stops people is not the loop. It is the address: a scenario runs in Make.com’s own cloud, so 127.0.0.1 there is Make.com’s container and not your desk, and the HTTP module will only call an HTTPS URL with a certificate it trusts. Get the address right and the rest is fifteen minutes of clicking.
What you need
- A Make.com account on any plan. Every module used here is in the built-in HTTP, Tools and Flow control apps.
- CapSkip running in Server mode on a Windows machine you control, reachable from the internet.
- A hostname pointing at that machine and a publicly trusted TLS certificate for it.
- The page URL of the protected form, and its sitekey.
Local mode and Server mode are both described under connection settings. Local mode is the right choice when your automation and the solver share a machine, which is exactly what a cloud scenario cannot do.
Why the loopback address is not an option here
Make.com scenarios execute on Make.com’s infrastructure, in one of four zones. Your account lives on us1, us2, eu1 or eu2, and every outbound request leaves from that zone’s published egress addresses. Nothing in that path touches your network, so a request to 127.0.0.1 resolves inside the container running your scenario and finds nothing listening.
Server mode is the answer and it is not a different product. The solver still runs on your hardware, still solves without a per-solve charge, and still exposes the same 2captcha-compatible endpoints. What changes is the interface it binds to: instead of answering only the local device, it answers on your network or public IP so anything with the address and a key can call it. A static public IP keeps that address from moving under you.
That published egress list is useful in the other direction too. Make.com documents the outbound addresses per zone, so you can allow only your zone’s addresses through the firewall to the solver’s port and drop everything else. Incoming addresses on Make.com’s side are dynamic and are not published, so do not try to pin those.
Give the solver an address Make.com will accept
This is the requirement that catches everyone, and it is worth reading twice. The HTTP module documents its URL field as an HTTPS endpoint, and it rejects certificates it cannot verify. A self-signed certificate is not good enough, and neither is a bare IP address on port 8080 over plain HTTP.
So put a TLS terminator in front of the solver. Caddy is the shortest route on Windows because it requests and renews a real certificate on its own, and one command is the entire configuration. Point a hostname at the machine first, then run it.
# Fronts CapSkip on 8080 with a real certificate for the hostname. # Ports 80 and 443 must reach this machine for the challenge. caddy reverse-proxy --from solver.example.com --to 127.0.0.1:8080
Verify it from your own machine before you touch Make.com. If curl is happy with the certificate, the scenario will be too, and you have just cut the debugging surface in half.
# Submit a reCAPTCHA v2 job. json=1 makes the reply JSON.
curl -s "https://solver.example.com/in.php" \
-d "key=YOUR_API_KEY" \
-d "method=userrecaptcha" \
-d "googlekey=YOUR_SITEKEY" \
-d "pageurl=https://example.com/page-with-recaptcha" \
-d "json=1"
# {"status":1,"request":"2122988149"}Step 1: submit the CAPTCHA
Add an HTTP module and choose the action that makes a request. Set the method to POST and the URL to your solver’s in.php endpoint. Choose the URL-encoded body type and add five fields, which are the same five the curl call above sends: the key, the method name, the sitekey, the page URL and the JSON flag.
Turn on the option that parses the response. Without it the reply arrives as a single string and you cannot map anything out of it. With it you get a status and a request value, and the request value on a successful submit is the job id.
The method name is what selects the CAPTCHA type. Use userrecaptcha for reCAPTCHA v2 and add version=v3 for v3, turnstile for Cloudflare Turnstile, geetest for GeeTest v3, and base64 for an image CAPTCHA sent inline. The complete parameter list for each is in the CapSkip API documentation.
Step 2: wait before you poll
Add a Sleep module from the Tools app. A reCAPTCHA v2 solve typically takes fifteen to forty-five seconds, so polling immediately just spends an operation to be told the answer is not ready. Twenty seconds is a sensible first wait.
Sleep delays the scenario for up to 300 seconds, five minutes, and that ceiling is the reason the next step is a loop rather than one long pause. It is comfortably more than a single solve needs, but you cannot use it to sit and wait for an unknown number of retries.
Step 3: poll until the token arrives
Make.com has no wait-until-condition module, so the poll is built from a Repeater and a filter. The Repeater lives in the Flow control app and is a bundle generator: give it an initial value and a number of repeats, and it emits that many bundles, each carrying a counter named i. Everything downstream of it runs once per bundle, which is your loop body.
Set the repeats to ten. Behind the Repeater put a second Sleep of five seconds and a second HTTP module that calls res.php with the job id from step 1.
# The poll. Same key, the id from the submit, action=get.
curl -s "https://solver.example.com/res.php?key=YOUR_API_KEY&action=get&id=2122988149&json=1"
# Still working:
# {"status":0,"request":"CAPCHA_NOT_READY"}
#
# Done:
# {"status":1,"request":"03AGdBq24PBCbwiDR..."}Now add a filter on the link leaving that module and let bundles through only when the status equals 1. Everything after the filter therefore runs exactly once, on the poll that succeeded, and no other attempt gets past it. Be clear about what that does and does not do. The Repeater still emits every bundle you asked it for, so the loop does not end early; what ends early is the waiting, because the token moves on the moment a poll finds it. The token is the request value on that bundle.
One property of the API shapes this design and is easy to miss. A result is readable once, so the first successful poll is the only one that will ever hand you the token. Map it into whatever comes next straight away rather than calling res.php a second time to fetch it again.
The same submit-and-poll shape appears in every no-code tool, and the differences are all in what the platform imposes around it. The self-hosted version of this flow, where the automation and the solver can share a machine, is written up in the n8n CAPTCHA workflow guide. A platform where a step runtime ceiling rather than a Sleep ceiling sets the shape is covered in the Zapier walkthrough.
What the loop costs in operations
Make.com bills operations, and an operation is one module run over one bundle. A trigger counts once no matter how much it returns, but every module behind the Repeater runs once per bundle, so ten repeats of a Sleep plus an HTTP call is twenty operations even when the token arrives on the second try. The filter does not stop the loop; it only stops bundles moving past it.
That count is fixed, not typical, which is what makes the two habits below worth having. Make the first Sleep long enough that the answer is usually ready by the first or second poll, because that is what lets you run a low repeat count at all. And set the repeats to cover the realistic worst case rather than a comfortable one: ten repeats at five seconds adds fifty seconds on top of the initial wait, which is plenty for v2.
The solving itself is not metered at all. CapSkip runs on your own machine, so the only thing a retry costs you is the operations Make.com counts for the modules that made it.
Step 4: send the token with the form
What you do with the token depends on the target. If you are posting a form, add a third HTTP module and include the token as the g-recaptcha-response field alongside the real form fields. For Turnstile the field is named cf-turnstile-response instead, and the solver also returns the user agent it used, which a challenge page will insist on seeing in the request headers.
Tokens expire, and for reCAPTCHA v2 the window is about two minutes from the moment the solve completes. Put the submit module immediately after the filter. Anything slow, such as fetching a record or building a payload, belongs before the solve rather than between the solve and the submit. Both submission styles and the timing are covered on the reCAPTCHA v2 solver page.
Common errors and what they mean
| What you see | Cause | Fix |
|---|---|---|
| A connection error on the first module | The solver is on a loopback or private address | Switch CapSkip to Server mode and use a public hostname |
| A certificate or TLS error | Self-signed certificate, or plain HTTP | Front the solver with a publicly trusted certificate |
| The response arrives as one unparsed string | The parse option is off on the HTTP module | Turn it on, then re-map the fields |
| ERROR_WRONG_USER_KEY | The key field is empty or malformed | Check the value mapped into the request |
| ERROR_GOOGLEKEY | An empty or wrong sitekey reached the solver | Read the sitekey off the live page again |
| CAPCHA_NOT_READY on every repeat | The loop is shorter than the solve takes | Raise the first Sleep, or add repeats |
| A second poll comes back without the token | A result is readable only once | Map it on the successful poll, do not re-fetch |
| The form rejects a token that looks fine | It expired before the submit ran | Move slow modules ahead of the solve |
FAQ
Can the scenario reach the solver on 127.0.0.1?
Make.com is a hosted product and there is no self-hosted edition, so the loopback address is never yours in a scenario. If your automation genuinely runs on the same machine as the solver, then you are describing a different tool. A self-hosted n8n instance keeps the traffic on the local device, and so does a script written against one of the CapSkip SDKs.
Is exposing the solver to the internet safe?
It is if you narrow who can reach it. Turn on key validation so an unauthenticated request is refused, give the scenario its own key so you can revoke it alone, and restrict the firewall rule to the published egress addresses for your Make.com zone. The TLS terminator in front of it means the key never crosses the network in the clear.
Why not one long Sleep instead of a loop?
Because a single Sleep tops out at 300 seconds and because you would be guessing. A fixed wait either burns wall clock on every run or comes up empty on the slow ones, and it gives you no second attempt either way. The Repeater gives you the retries, and the token reaches the submit module the moment a poll finds it, usually the second one. The loop itself still runs its full count, so what this buys you is reliability rather than a smaller bill.
Does the scenario need a proxy for the solve?
Usually not. Proxy support exists for reCAPTCHA, Turnstile and GeeTest, and it matters when the target site ties the token to the IP that will submit it. Image CAPTCHAs do not take a proxy at all. Add the proxy parameters to the first HTTP module, the one that calls in.php, and only if you see tokens rejected despite arriving in time.
The short version
Put CapSkip in Server mode, front it with a hostname and a trusted certificate, then wire four things in the scenario: an HTTP submit, a Sleep, a Repeater with a Sleep and an HTTP poll behind it, and a filter that only lets a finished result through. No code step is involved at any point. The same flow collapses to a single call in Python, Node.js, PHP or C#, and every one of those is shown on the CapSkip SDK page.
Worth knowing before you scale a scenario up. Because CapSkip is a captcha solver running on hardware you already own, the number of solves never appears on a bill. The only thing that grows with volume is the operation count Make.com charges for the modules around it.
