t4mer@notebook

// problem · 9 may 2026 · 1 min

API works in Postman but fails in Laravel

The request you think you are sending is not always the request that leaves the process.

Time wasted: 2 hours

Problem

A provider endpoint returned 200 in Postman and 401 or 400 from Laravel with “the same” payload.

Environment

Laravel HTTP client / Guzzle Postman third-party REST API

Symptoms

Postman collection green. Application logs showed a client error. Copying the JSON body into tinker did not help. The URL was identical.

Expected

The same status and body I saw in Postman.

Investigation

Opened Postman’s console. Compared headers, not screenshots. Logged the Guzzle request.

Things I tried

Recreated JSON in tinker. Copied the token again. Switched timeout values. Blamed the provider. The collection-level headers were still invisible.

Root cause

Collection-level headers in Postman (Content-Type / Authorization / Accept) plus a token environment that was not present in the Laravel client. In one variant, Postman sent form-urlencoded while Laravel sent JSON.

Solution

Matched Content-Type and Authorization byte-for-byte. Removed a trailing newline from the token. Stopped treating Postman as a specification.

Why it worked

Servers validate the request they received, not the request you intended. Postman was sending extra defaults.

Lesson

“Works in Postman” means “works with Postman’s hidden defaults”. Diff the raw HTTP.

Found something wrong?

These notes can be incomplete, or wrong in a different environment. Suggest a correction on GitHub or email me at me@t4mer.net.

// related