If an API expects JSON, the most common setup problems are usually not “n8n problems”: they are invalid JSON, values with the wrong type, missing authentication headers, or a body shape that does not match the API.
Suppose an API expects a name, age and active flag:
{
"name": "Alice",
"age": 18,
"active": true
}
Notice that 18 is a number and true is a boolean. Writing them as "18" or "true" changes their type.
{
"customer": {
"email": "a@example.com",
"plan": "pro"
}
}
Nested objects are useful when an API groups related fields under objects such as customer, metadata or options.
Content-Type: application/json Authorization: Bearer YOUR_TOKEN
The exact authentication header depends on the API. When n8n has a dedicated credential type for the service, keeping the secret in n8n Credentials is generally safer than pasting a long-lived token directly into a workflow field.
curl -X POST 'https://api.example.com/v1/items' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer YOUR_TOKEN' \
--data '{"name":"Alice","active":true}'
If the cURL request fails too, the problem is probably the API endpoint, authentication, headers or payload rather than the n8n workflow wiring.
n8n documents the HTTP Request node as the fallback for API operations that are not covered by a dedicated app node. The exact options depend on the target API, so always compare the generated request with that API's current documentation.