An error 400 in Make.com is a rejection category, not a diagnosis. It tells you that some request was unacceptable, but it does not tell you whether the bad input was a missing mapped value, the wrong JSON shape, an unsupported API option, an OAuth redirect mismatch, or simply the visible result of an earlier module failing.

That distinction matters because a blind retry rarely repairs an invalid request. It can also repeat work completed before the failure. The safer approach is to preserve one failed run, identify who produced the 400, and change one thing only after the response evidence points to it.

The 400 Diagnostic Card

Use this as a five-minute evidence capture before editing the scenario. Copy the answers into a ticket or incident note.

Field What to record Why it narrows the cause
Failing module App and action name Separates a connection problem from an HTTP/API request
Full error Status, Make error type, message, and response body The words after 400 are usually more useful than the number
Input bundle Required mapped fields and their actual values Exposes empty values, wrong types, and stale mappings
Destination Service and endpoint called Shows whose validation rules apply
Last success Time and scenario version Helps distinguish a changed input from a changed configuration
Repeatability Every bundle or one bundle Separates structural faults from data-specific faults
Prior effects Modules that already wrote data Determines whether replay could duplicate work

Do not paste access tokens, authorization headers, customer records, or other secrets into a shared note. Record the field names and redact values that are not needed for the diagnosis.

Decision Tree: Which Kind of 400 Is This?

Follow the first matching branch. The purpose is not to guess the fix; it is to reach the smallest evidence set that can prove the fix.

If yes, treat it as a connection setup failure, not a payload problem.

  • Compare the redirect URI shown or used during authorization with the URI registered for the OAuth client.
  • Check for an exact mismatch in scheme, hostname, path, region, or trailing slash.
  • Confirm the client ID belongs to the same OAuth project whose redirect list you changed.
  • Reauthorize only after the registered value is correct.

Do not rebuild field mappings at this stage. The request has failed before normal module data can be processed.

2. Does Make name a field, type, limit, schema, or validation rule?

If yes, treat it as a request validation failure.

The useful details may look like “required”, “must be an object”, “invalid value”, “maximum”, or a path to a field. Inspect the actual input bundle rather than the mapping label in the editor: a field that looks mapped can resolve to an empty value or a different type at runtime.

Check in this order:

  1. Is every required value present in the failing bundle?
  2. Is each value the type the destination expects: string, number, boolean, array, or object?
  3. Does a date, phone number, identifier, or enum use the documented format?
  4. Is text, an array, a file, or the whole request above a stated limit?
  5. Did the upstream app change a field name or nesting level?

Make’s error documentation describes bundle validation as checking field types and required values before a bundle is processed. That makes the runtime bundle—not a screenshot of the mapping—the decisive evidence.

3. Does the error come from an HTTP module or a custom API call?

If yes, treat it as an endpoint-contract failure until disproved.

Compare the captured request with the current API documentation:

  • HTTP method and complete endpoint path
  • path and query parameters
  • Content-Type and accepted response type
  • authorization scheme and scope
  • JSON root type and nesting
  • whether an option is actually supported by that endpoint

An invented or unsupported parameter can produce the same 400 as malformed JSON. Removing random fields one by one is slower than comparing the raw request with the endpoint schema.

If the normal run view does not expose enough detail, reproduce one safe input with Make DevTool. Make documents that its Live Stream can show the request headers, request body, response headers, and response body for each module. Redact credentials before sharing any copied raw request or cURL command.

4. Does the message say a previous request failed?

If yes, treat the visible 400 as a downstream symptom.

Move left through the run until you find the first module with an error or unexpected output. Fixing the final module will not help if it received no valid bundle because an earlier request failed.

Record the first failure and the downstream 400 separately. This prevents incident notes from naming the last visible error as the root cause.

5. Does the same scenario work for some bundles but not others?

If yes, treat it as a data-dependent fault.

Compare one successful bundle with one failed bundle. Focus on presence, type, length, encoding, and nested structure. Common differences include:

  • an empty required value
  • text where a numeric ID is expected
  • an array where the app accepts one item
  • a character or byte limit exceeded
  • a line break or quote that breaks manually assembled JSON
  • a record no longer accessible to the connected account

Do not solve a data-specific fault by skipping every 400. Add a filter or normalization step only when you can state which input is invalid and what the valid rule is.

6. Is the response still just “400 Bad Request” with no useful body?

If yes, you have an evidence gap.

Open the run in Scenario history, inspect the failing module and bundle, and reproduce one non-destructive case with DevTool if necessary. If the destination suppresses response details, reduce the request to the smallest valid shape from its documentation, then add fields back in groups. Stop when the failure returns.

Escalate with a compact packet: scenario and module IDs, timestamp and time zone, full redacted response, request shape, whether the fault affects every bundle, and the last known successful run. “It gives 400” alone is not enough for another person to distinguish validation from authentication or endpoint misuse.

A Safe Test Sequence

The order below protects existing data and makes the result reproducible.

  1. Preserve the failed run. Use Scenario history to capture the exact run, status, details, and input bundle.
  2. Mark prior side effects. Note every earlier module that created, updated, emailed, charged, or deleted anything.
  3. Duplicate or version the scenario before structural edits. Keep a known baseline so several simultaneous changes do not erase the cause.
  4. Choose one harmless test bundle. Avoid a live payment, customer notification, or record that could be duplicated.
  5. Change one proven fault. Correct the field, type, endpoint option, connection, or limit named by the evidence.
  6. Run once and compare. Confirm both the previously failing module and the modules after it.
  7. Recover deliberately. Replay old runs only after checking whether upstream actions already succeeded.

Make’s run-replay documentation says replay uses previous trigger data with the current scenario version. That is useful after a logical fix, but it is also why duplicate-risk review belongs before replay rather than after it.

Retry, Resume, Skip, or Stop?

A 400 is usually not transient. Choose handling based on the proven cause, not the convenience of keeping the schedule green.

Response Use it when Do not use it when
Fix and replay Mapping, schema, endpoint, or connection is now corrected Earlier side effects could be duplicated and have not been checked
Retry handler The documented failure is temporary and the request remains valid The same invalid payload will be sent again
Resume with substitute A missing value has a truthful, safe substitute The substitute would create false customer or business data
Skip The invalid bundle is expected, independently logged, and genuinely optional The record is financially, legally, or operationally important
Stop and inspect Cause is unclear or the flow may have partial effects You have already proved a safe, bounded recovery path

Make’s error-handling overview distinguishes these behaviors: Retry stores the failed bundle for another attempt, Resume supplies substitute output, and Skip removes the affected bundle from the flow. None of those directives makes a malformed request valid on its own.

Prevention Checklist for Future 400 Errors

After the immediate fault is fixed, add only the controls that address the observed failure:

  • validate required fields before the destination module
  • parse JSON rather than assembling it with string concatenation
  • cap or split fields that have documented size limits
  • log a correlation ID and destination response without secrets
  • alert on the first failure before repeated errors disable a schedule
  • store incomplete executions when the recovery value outweighs the retained-data risk
  • save a scenario version before changing mappings or endpoints
  • keep one known-good test bundle for future regression checks

The goal is not to catch every theoretical 400. It is to make the next real rejection explain itself without a blind retry.

Methodology and Limits

This guide was built on 23 August 2026 from current Make Help Center documentation for errors and warnings, common error fixes, Scenario history, Make DevTool, error handlers, and scenario run replay. We also reviewed current Make Community search results to classify the different failures users encounter under the same 400 label.

The decision tree is a diagnostic framework, not a catalogue of every connected app’s API rules. A third-party service can return its own message and may not use status codes consistently. Its current API documentation and the actual redacted response body remain authoritative for that specific request. No live customer scenario or connected account was tested for this research-only guide.

Bottom Line

When Make.com shows error 400, ignore the temptation to repair “400” as if it were one fault. Capture the full response and failing bundle, decide whether the rejection belongs to connection setup, validation, an endpoint contract, or an earlier module, and then test one evidence-backed change.

That process turns a vague status code into a bounded decision: correct the invalid request, recover only the affected runs, and add the smallest control that makes the same failure visible next time.