OAuth2 Token Request Fails With Grant Type Not Specified When Body Is JSON
What it means
When requesting an OAuth 2.0 access token, the request body was sent as a JSON object instead of the form-urlencoded format the token endpoint expects, so fields like grant_type never arrive as recognizable parameters even though the same values work fine in Postman.
Troubleshooting
- Confirm what content type the token endpoint actually requires. The OAuth 2.0 spec (RFC 6749) mandates application/x-www-form-urlencoded for the token request body, not JSON, even when the rest of the API is JSON-based.
- Compare the raw request Postman sends against what your integration tool actually sends on the wire. Postman's OAuth 2.0 helper auto-encodes the body as form fields; a JSON payload with the same field names will fail even though it looks equivalent.
- Check the Content-Type header on the outbound request. If it says application/json while the body is form-encoded text (or vice versa), the receiving server will misparse or drop fields.
- Verify grant_type, client_id, client_secret, and scope are present as literal key=value pairs joined by & in the body, not nested inside a JSON structure.
Rebuild the request body as a single application/x-www-form-urlencoded string (grant_type=password&client_id=...&client_secret=...&scope=...) and set the Content-Type header to application/x-www-form-urlencoded instead of application/json.
Standardize OAuth token-fetch steps in integration templates to always build the body as form-urlencoded text with the correct Content-Type header, rather than reusing a generic JSON-body pattern copied from other REST calls in the same integration.