Some integrations are easy. The vendor has a native Make module, you drag it in, fill out a few fields, and you’re done. But what happens when the tool you need doesn’t have a native connector — and building the integration manually feels like staring into a wall of API documentation you don’t have time to decode?

We ran into exactly that situation on a client project. The platform was solid. The use case was real. But there was no native Make module, and the API docs were dense. That’s when we turned to the same workflow-building approach we’ve been refining for months — covered in detail in our field report on using Claude to build production Make scenarios. What happened next changed how we think about the “no native module” problem entirely.

Here’s a full walkthrough: the constraint, the approach, what Claude actually built, how we verified it, and what the result looked like in production.

What Was the Constraint?

The client needed data moving between their CRM and a specialized operations platform — a niche tool that handles a specific workflow in their industry. The platform has a well-documented REST API. It just doesn’t have a Make module.

That’s not unusual. The Make app library is large, but it doesn’t cover everything. When you run into a gap, you have two options: find a workaround that limits what you can do, or build the integration yourself using Make’s generic HTTP module.

The HTTP module is powerful. It can call any REST API endpoint that accepts standard requests. But configuring it correctly — especially for APIs with authentication layers, specific header requirements, and structured JSON payloads — takes time. You have to read the docs carefully, translate them into the HTTP module’s field structure, get the auth flow right, and test until the responses come back clean.

On a straightforward API, that’s a couple of hours. On something with more complexity, it stretches. And every hour spent on configuration is an hour not spent on the actual logic of the automation.

We needed a faster path.

What Was Our Approach?

The approach was direct: pull the vendor’s API documentation, feed it into Claude, and ask it to configure the HTTP module.

We’ve written about the broader production lessons from this kind of workflow in our post on running a custom Make MCP server. The API-docs-to-HTTP-module lesson is one of the most valuable things we’ve found in daily practice. This case study is what that looks like in execution.

Here’s what we gave Claude:

• The vendor’s full REST API reference for the two endpoints we needed — pulled directly from their developer docs
• The authentication method (API key passed as a header, with the exact header name specified in the docs)
• The expected request body structure, including required and optional fields
• The response schema so we could verify what a successful call would return
• A short description of what we needed the scenario to do — which record to create, which fields to populate, and where the data was coming from

That’s it. We didn’t write any JSON by hand. We didn’t try to pre-translate the docs into Make’s structure. We handed Claude the source material and described the outcome we wanted.

What Did Claude Actually Build?

Claude returned a fully configured HTTP module spec — not a summary, not suggestions, but a field-by-field configuration ready to drop into Make.

Specifically, it produced:

• The correct base URL for each endpoint
• The HTTP method (POST for record creation, GET for retrieval)
• The full header block including the API key header formatted exactly as the vendor specified
• The request body as a properly structured JSON object, with field names matching the API schema
• Notes on which fields were required versus optional, pulled directly from the docs we provided
• The expected response structure, flagged so we’d know what to map downstream

This is the part that used to eat time. Formatting JSON inside Make’s HTTP module by hand, getting header names exactly right, making sure the content-type was set correctly — these are small things, but each one is a potential failure point. Claude got them right the first time.

We’ve also found Claude handles this well when there’s ambiguity in the docs. In this case, the vendor’s authentication section had a note about optional OAuth support alongside the API key method. Claude flagged the difference, asked which method we were using, and then configured accordingly. It didn’t silently guess. That matters in production.

If you want to see the step-by-step process for feeding API docs into Claude to build HTTP modules, we’ve documented that in detail at /how-to-feed-api-docs-into-claude-build-make-http-modules/.

How Did We Verify the Output?

Claude’s output was the starting point, not the finish line. Verification is non-negotiable.

Here’s the verification sequence we used:

1. Visual check against the API docs. Before running a single test call, we compared Claude’s output field-by-field against the vendor documentation. Header names, required fields, JSON structure. No surprises here — it matched.
2. Test call with static data. We ran the HTTP module in Make with hardcoded test values — no dynamic variables yet. The goal was to confirm the API accepted the call and returned a 200 response. It did, first try.
3. Response mapping check. We confirmed the response structure matched what Claude described. The fields we needed downstream were present and named correctly.
4. Live data test with mapped variables. Replaced static values with Make variables pulling from the upstream trigger. Ran again. Clean response.
5. Error condition test. Intentionally sent a malformed request to confirm the error handler fired correctly. It did.

Total verification time: about 45 minutes. Most of that was the live data test and confirming the error handler behavior — not fixing structural problems, because there weren’t any.

What Were the Results?

The scenario went to production and has been running without incident.

The “no native module” problem effectively went away. Any platform with REST API docs is now a platform we can connect to Make — quickly, correctly, and without a full day of trial-and-error HTTP configuration.

What Did We Learn?

A few things worth taking into production with you:

Give Claude the actual docs, not a summary. Don’t paraphrase. Don’t try to pull out just the relevant parts. Copy the full endpoint documentation — authentication section, request schema, response schema, error codes. The more complete the input, the more complete the output. Vague input produces vague scenarios.

Describe the outcome, not the method. Tell Claude what the scenario needs to accomplish — which record to create, which data to pass, where it comes from. Let it figure out how to configure the HTTP module. You don’t need to pre-structure the JSON yourself.

Expect clarifying questions on ambiguity. If the docs have two authentication options, Claude will ask. That’s the behavior you want. It means the output will be built for your actual setup, not an assumed one. We’ve covered this more in our roundup of Make scenarios that build faster with AI assistance.

Verify before you trust. The output is the starting point. Visual check against the docs, then test calls, then live data, then error conditions. This sequence is fast when the configuration is correct — and it was.

The native module gap is smaller than you think. If a platform has REST API documentation, it’s connectable. The generic HTTP module handles it. Claude handles the configuration. The constraint that used to slow us down isn’t much of a constraint anymore.

Information in this article is deemed to be accurate at time of publishing. 4Spot Consulting reviews and updates content periodically as best practices evolve.