Integromat ChatGPT: Where the Model Call Belongs in Make

Where does an Integromat ChatGPT call sit in a Make scenario?

Integromat is now called Make. The platform kept its module library, its scenario editor and its pricing structure through the rename, so this is a naming change, not a rebuild, and the rest of this article uses Make throughout. If you’re searching for “integromat chatgpt” because that’s the name you learned the tool under, you’re in the right place.

The question that matters more than the name is where the model call actually sits once you build the scenario. Put it first, ahead of any cleanup, and you’re sending raw, untrimmed data into a call that costs time and money on every run, including on records that were never going to need it. A trigger pulling in new orders, product updates or customer messages carries a mix of clean records and junk: test orders, out-of-stock placeholders, blank fields, duplicate webhooks firing twice for the same event. None of that needs a model call, and all of it can be caught with a Set Variables module and a Filter before the flow reaches the point of spending anything on an API request.

The working order looks like this: trigger, then normalise (Set Variables or a Text Parser module to strip whitespace, fix casing, pull out the fields you actually need), then filter (route out anything missing a required field, anything already flagged as handled, anything below the threshold that makes the record worth processing at all), then the model call, then a validation step on the reply, then a Router splitting success from failure, then the write step to whatever system receives the result — a Shopify product update, a Klaviyo profile field, a support ticket reply. The model sits in the middle of that chain, never at either end. It shouldn’t be the first thing that touches the data, because it shouldn’t have to do the cleanup work a Filter does for free. And it shouldn’t be the last thing before a write, because its reply needs checking before anything downstream trusts it.

What causes a ChatGPT call to fail, ranked by how often it happens?

This list is worth keeping next to the scenario, in the order these failures actually show up when a Make flow has a model call in it. It isn’t a theoretical list of things that could go wrong; it’s ordered by how often each one is the actual cause when a run stalls or produces a bad record.

1. Malformed JSON wrapped in commentary. The most common failure by a wide margin. You ask for structured output and the reply comes back as the JSON you wanted, plus a sentence before it (“Here’s the categorisation:”) or after it (“Let me know if you’d like adjustments”). A parse step expecting clean JSON from the first character fails on the wrapper text, even though the JSON itself would have been fine. This is a prompting problem, not a model limitation, and it’s the first thing to fix because it’s the easiest to fix.

2. A field in the right shape but the wrong type. Take this illustrative example: a price field returns as the string “$12.99” instead of a number the destination expects, even though the JSON itself is valid and the parse step passes it without complaint. A boolean can fail the same way, arriving as the word “true” in quotes rather than an actual boolean. This one is quieter than a parse failure because nothing errors immediately; it surfaces later, in the destination system, as a field that silently didn’t update or updated with a value the receiving app coerced into something unexpected.

3. Refusal or hedged language instead of the structured answer. Ambiguous or borderline content — a product description that reads close to a medical or safety claim, a customer message that sounds like a complaint about to become a legal one — can trigger a reply that declines to answer directly, or answers with caveats wrapped around the actual content. This looks like a malformed reply to a downstream parser, but the cause is different, and the fix is different too: a caveated reply usually means the record needs a person, not a retry.

4. Timeout or an empty response under load. Running a model call inside an Iterator processing a long list, back to back with no pacing, occasionally produces a timeout or an empty string where a full reply was expected. This shows up more on larger batches and busier times of day than on a small manual test, which is part of why it’s easy to miss until the scenario has been live for a while.

5. Schema drift after a prompt or model change. A prompt gets tweaked to add a field, or the underlying model changes its default formatting habits, and the reply shape shifts slightly: a key gets renamed, a nested object flattens, an array that used to have one item now has several. The validation step written against the old shape stops matching, and every record that used to pass now fails, all at once, which is at least easy to notice compared to the quieter failures above it.

6. Data reaching the prompt that was already wrong. An earlier module mapped the wrong field — customer name into the product description slot, an ID into a text field — and the model, doing its best with malformed input, produces an odd reply that looks like a model failure but is actually an upstream mapping error. This is the one worth checking first when a failure doesn’t match any of the five failure modes described here: read the actual prompt that was sent, not just the reply that came back.

How do you stop a malformed or refused reply from stalling the scenario?

Stopping a stall starts with treating the model’s reply as untrusted input, the same way you’d treat a file a customer uploaded. Parse it, check it against what you expected, and only then let it continue downstream.

Make’s JSON app includes a Parse JSON module, and running the model’s reply through it immediately after the call catches the wrapped-commentary failure and any reply that isn’t valid JSON at all. That catches failure mode one. It doesn’t catch failure mode two — a valid JSON object with the wrong field types — so a second check, comparing the parsed object’s keys and rough value types against what the destination expects, needs to sit right after it. This can be as simple as a Filter module checking that a price field is numeric and a required key exists before the flow is allowed to continue to the write step.

From there, a Router splitting the flow into a success branch and a failure branch keeps one bad record from taking the whole run down with it. The success branch continues to the write step as normal. The failure branch routes to a log — a spreadsheet, a database table, a ticket queue, whatever your team already checks — recording the record ID, the raw reply and a timestamp, so a failed record is visible rather than silently dropped.

Make’s own error handling directives on the model module itself matter here too. Setting the module to break stops the entire scenario on any error, which is rarely what you want for a batch run: one bad record shouldn’t cost you the other four hundred behind it. Resume lets the scenario continue past the error with a default or blank value in the failed field, which suits low-stakes fields where a blank is safer than a guess. Commit and rollback control whether partial work already done in the run gets kept or undone; for most enrichment scenarios, resume paired with the failure-branch logging just described gives you both continuity and a visible trail, without silently pretending nothing went wrong the way ignore does.

For failure mode three specifically — a refusal or hedged reply — retrying immediately rarely helps, because the same ambiguous input tends to produce the same cautious reply. A short retry with a slightly reworded prompt is worth one attempt; past that, the record belongs in the human review queue rather than a longer retry ladder. For failure mode four — a timeout under load — a single automatic retry with a short delay handles most cases, since the cause is usually transient. Widening the delay on a second retry before falling back to the queue is a reasonable pattern; treating every timeout as permanent and routing it straight to a person adds review work that a retry would have avoided.

What does scoring every record with the model actually cost?

The trap is pointing an Iterator at the full record set and running every single one through the model call, regardless of whether the record needed it. It’s the simplest scenario to build, which is exactly why it’s the one most teams build first, and exactly why it’s the one that gets expensive without anyone deciding it should.

Here’s an illustrative comparison, not a measured cost, to show why the distinction matters: say a catalogue holds 20,000 SKUs and an enrichment scenario reruns weekly. Sending every record through the model call means 20,000 calls a week, whether or not the record’s data was already complete. If records missing a category tag make up a tenth of that catalogue at any given time, routing only those through the model — with a Filter checking for the missing field before the model call, not after — cuts that hypothetical 20,000 down to 2,000, without changing what the model actually fixes. The other 18,000 records already had what they needed; the model call was never going to change their outcome, only add a cost and a small chance of introducing an error where none existed before.

That arithmetic is illustrative, not a number to plan a budget against — your own catalogue size, refresh frequency and how often records actually need enrichment will set the real figure, and the model vendor’s own pricing page is the place to check current rates rather than a figure carried over from memory. The same caution applies to Make’s own operation allowance: each module run against a record counts against your plan’s operation limit, and that limit varies by plan and changes over time, so check your current plan’s allowance in Make’s own account settings before assuming a scenario will fit inside it at scale.

The broader point holds regardless of the exact numbers: a model call is not a free action to sprinkle across every record in a flow. It’s a step with a cost and a failure surface, and the records that don’t need it are the ones where that cost buys nothing.

Which records actually need a model call, and which don’t?

A record needs the model when the input varies enough that a fixed rule can’t reliably cover it: free-text customer messages that need classifying into a support category, a new SKU description that needs a category tag it doesn’t already have, a product description that needs rewriting to a length limit while keeping meaning intact. These are tasks where the same input doesn’t map to the same output in a way a lookup table could encode.

A record doesn’t need the model when a rule already answers the question. A SKU that already carries a category tag doesn’t need to be re-tagged. An order that already matches a known pattern — same customer, same product, same shipping method as the last ten — doesn’t need a model call to decide how to route it. A customer message that matches an existing keyword pattern for “where’s my order” is cheaper and more consistently handled by a keyword-based Filter than by a model call that might phrase its classification slightly differently each time.

The practical test is a Filter module sitting before the model call, checking for the condition that actually signals ambiguity: is the category field empty, does the message not match any of the known keyword patterns, is this SKU new in the last import rather than one seen before. Records that pass the filter go to the model. Records that don’t, skip it entirely and go straight to whatever rule-based handling already covers them. Building that filter takes longer than skipping straight to the model call for everything, and it’s the difference between a scenario that scales with your catalogue and one that scales its cost with it too.

What happens when the model call fails mid-run, not at the start?

A scenario that fails on record one is easy: you see the error, you fix it, nothing has happened yet. A scenario that fails on record four hundred out of five hundred is a different problem, because four hundred records have already been processed and written, and the run needs to either resume cleanly from where it stopped or be safe to rerun from the beginning without duplicating that work.

Idempotent design matters more here than it sounds like it should. If the write step checks whether a record has already been updated — a “last enriched” timestamp field, a flag set on successful write — before writing again, then rerunning the whole scenario from the start after a mid-run failure simply skips the records already done and picks up from where it stopped, without creating duplicate updates or double-sent messages. Without that check, a rerun reprocesses everything, including the four hundred already-correct records, at full cost and full risk of introducing a new error into records that were previously fine.

Make’s scenario history shows exactly which records ran and which didn’t in a given execution, which is the first place to look after a mid-run failure — not to diagnose why record four hundred and one failed specifically, but to confirm where the run actually stopped, since a Router or Aggregator further downstream can sometimes make that less obvious than it looks. An Aggregator collecting results from a batch before a final summary write is a common point where this gets confusing: if the aggregation step itself fails, none of the individually successful upstream writes are lost, but the summary that depends on all of them might never fire, and checking that separately from the individual record writes avoids treating a summary failure as a full-run failure when it isn’t.

Why does this matter for AI search visibility?

AI-driven traffic to ecommerce stores is no longer a marginal channel. Shopify’s president, Harley Finkelstein, told Q1 2026 earnings call listeners that AI traffic to Shopify stores was up 8 times year-on-year, with AI-search orders up nearly 13 times over the same period — a vendor-reported figure, but a directional one worth taking seriously given the scale of Shopify’s merchant base. When an AI shopping assistant reads your catalogue, your product feed or your site content to answer a shopper’s question, it’s reading whatever your systems actually wrote, including anything a Make scenario enriched, tagged or rewrote along the way.

A malformed reply that slipped past validation and landed in a product’s category field, a description field, or a structured attribute doesn’t just sit there quietly. It’s the exact kind of inconsistent, wrong or blank data that makes a catalogue harder for an AI system to parse correctly, and harder for it to cite your product with confidence over a competitor’s. Independent research from Princeton found that applying deliberate generative engine optimisation techniques can lift AI visibility by 30 to 40 percent — the flip side being that avoidable, unforced errors in the underlying data work against that same visibility, quietly, without anyone connecting the dropped visibility back to the automation scenario that caused it.

Reliable automation and AI search visibility aren’t separate problems. The scenario that reliably catches a malformed reply before it reaches a product field is doing visibility work, even though it looks like an operations task.

Who should not build this without a review queue?

This pattern is built for operators running enough volume that manual review of every record was never realistic in the first place — brands at $3M to $30M in revenue on Shopify Plus or a comparable paid subscription platform, where a catalogue or message volume big enough to need automation is also big enough that a bad batch of silent failures can do real damage before anyone notices.

If your catalogue is small enough that a person could reasonably review every enrichment by hand in an afternoon, the fallback-and-review-queue machinery described here is more infrastructure than the problem needs; a person doing the work directly, with the model as an occasional assist rather than a scenario running unattended, is the simpler and safer choice at that scale. And if nobody on the team is going to check the failure log or the review queue on a routine basis, don’t build the scenario to run unattended at all: an automated flow with no one watching the exceptions doesn’t remove the risk of bad data reaching customers, it just delays when someone notices.

Getting the failure handling right in a Make scenario is, in the end, an AI search visibility problem as much as an operations one: the data your automation writes is the data an AI shopping assistant reads, and Pointerflow’s AI search visibility work starts from exactly that link between what your systems produce and what shows up when a shopper asks an AI assistant about your products.