Connect Make to Software Without an API (July 2026)
Make's HTTP module can call any API. For the portal that has none, a generated backend endpoint slots into your scenario as one more module. Updated July 2026.
Make wins on visual power. Scenarios with routers, iterators, and error handlers go well past simple trigger-action pairs, and the pricing works for agencies. It hits the same wall as every orchestrator, though: the scenario ends where the connector catalog does, and the systems running vertical businesses mostly aren't in it.
TL;DR
Keep the scenario. For the no-API portal, add Make's HTTP module pointed at a Supergood-generated endpoint: the portal's own backend, packaged as documented REST, answering in milliseconds with structured JSON. Maintenance, MFA, and session handling live upstream of your scenario.
The pattern in a scenario
A work order closes in your field-service tool; the client's property portal needs the update. Scenario: watch the field-service event, map the fields, HTTP module POSTs to the portal's endpoint, router branches on the real status code, error handler retries or alerts. Nothing exotic, which is the point: the no-API system stops being a special case.
| Approach in Make | Works when | Watch out for |
|---|---|---|
| Native app/module | Vendor has an API Make wrapped | Most vertical portals have neither |
| Generic HTTP module + vendor API | An API exists but no Make app | Partner-gated APIs take months of approval |
| HTTP module + Supergood endpoint | Portal has no API at all | Backend changes (detected and fixed for you) |
A worked example
Take a concrete case: a CRM behind a login, no Make app, no public API, and a sales team that needs live unit availability on every new deal. Build the scenario in four modules.
Start with a Watch Records trigger on the CRM so the scenario fires when a deal is created. Add the HTTP module next: set the method to GET, point the URL at the generated units endpoint, and pass the API key in a header. The response is structured JSON with each unit's status, price, and availability date, so the fields map straight into later modules without parsing. Route the response with a Router: one branch for units that come back available, one for everything else.
On the available branch, update the deal record with the unit data and notify the rep. On the other branch, create a follow-up task so a human decides what happens next. Attach an error handler to the HTTP module that retries on server errors and alerts on anything else. The whole build is an afternoon, and every module is deterministic: same input, same output, milliseconds per call.
FAQ
Why not drive the portal with a browser automation step? Seconds per step, breakage on every UI change, and MFA prompts that stall unattended runs. Production scenarios need deterministic steps, and a backend call is one; a browser session is not.
Does this change Make pricing? An HTTP call is one operation, same as any module. The heavy lifting happens on the endpoint's side.
Make or n8n or Zapier: which should we use with Supergood? Whichever you already run. The endpoint is plain REST, so all three call it the same way; we wrote the n8n version and the Zapier version of this guide too.
Can Make connect to software without an API? Yes, through the HTTP module. If the platform has no public API, a generated backend endpoint gives Make something to call: the portal's own backend, packaged as documented REST. The scenario treats it like any other module.
Related reading
- How to Automate Software That Has No API: the full option set when the catalog runs out.
- Connect n8n to Software Without an API: the n8n version of this pattern.
- Supergood plus Zapier: the Zapier version of this pattern.
Updated July 2026.