Troubleshooting
Authentication failures typically occur when credential types are misused, token exchange parameters do not match the target environment, or short-lived values expire before use. The scenarios below reflect common onboarding and integration issues observed when authenticating to Health Gorilla APIs.
Each issue includes the observable symptom, the underlying cause, and the corrective action required to restore successful authentication.
Common OAuth Errors
The following table summarizes frequently encountered OAuth 2.0 errors and their most likely causes.
| Error | Root Cause | Fix |
|---|---|---|
invalid_token | JWT assertion used instead of an access token | Exchange the assertion at /oauth/token and use the returned access token |
invalid_grant | Expired assertion or incorrect aud value | Regenerate the assertion and confirm the audience matches the token URL |
invalid_client | iss or sub does not match the assigned client ID | Set both values to YOUR_CLIENT_ID |
| Silent failure | Malformed or truncated assertion | Regenerate the assertion and copy the full value |
| Authentication succeeds in sandbox but fails in production | Environment mismatch | Confirm sandbox versus production URLs and audience values |
Example: Using A JWT Assertion As An Access Token
Symptom
HTTP/2 401
www-authenticate: Bearer error="invalid_token"
Cause
Your system used the JWT assertion generated by jwtoken.html as if it were an OAuth access token.
Fix
Exchange the JWT assertion for an OAuth access token before calling any API.
curl -X POST "https://sandbox.healthgorilla.com/oauth/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d 'grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer' \
-d 'assertion=YOUR_JWT_ASSERTION' \
-d 'scope=patient360 user/*.*'
Use the returned access token in the Authorization header for all API requests.
Example: Invalid Client ID During Token Exchange
Symptom
invalid_client
or
improper client id
Cause
The iss or sub claim in the JWT assertion does not match the assigned client ID. This commonly occurs when an email address is used instead of the client ID.
Fix
Set the following values in the JWT assertion:
iss = YOUR_CLIENT_IDsub = YOUR_CLIENT_IDNever use an email address in thesubclaim.
Example: Environment Mismatch
Symptom
Authentication succeeds in one environment but fails in another.
Cause
A JWT assertion generated for one environment was sent to the token endpoint for a different environment. The aud claim does not match the token URL.
Fix
Match the audience and token URL exactly.
- Sandbox environment token URL and
aud:https://sandbox.healthgorilla.com/oauth/token - Production environment token URL and
aud:https://api.healthgorilla.com/oauth/token
Example: Token Exchange Fails Without A Response
Symptom
No response body is returned from the token endpoint.
Cause
The JWT assertion is malformed or expired. Silent failures often indicate one of the following:
exptimestamp is in the pastaudvalue does not match the token URL- Assertion was truncated or corrupted when copied
Fix
Generate a new JWT assertion immediately before token exchange and verify:
expis in the futureaudmatches the token endpoint- The full assertion value was copied without modification
Example: Using An Expired JWT Assertion
Symptom
Token exchange fails after a short delay.
Cause
JWT assertions generated by jwtoken.html include short-lived timestamps and expire quickly.
Fix
Generate a fresh JWT assertion immediately before calling /oauth/token. Assertions cannot be reused after expiration.
Example: Postman UI Does Not Match Instructions
Symptom
Postman screenshots or variable locations do not match the current application UI.
Cause
Postman updates may change layout and labeling without notice.
Fix
Confirm the following:
- Environment variables are stored in the Environment panel
- The JWT assertion is pasted into the correct request field
- The token request uses
application/x-www-form-urlencodedbody encoding
Example: Confusion About grant_type Values
Symptom
Token exchange fails when experimenting with different grant_type values.
Cause
Parameters from multiple OAuth flows were combined, or an unsupported grant_type string was used.
Fix
Use exactly one supported pattern per request. JWT Bearer flow:
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearerassertion=YOUR_JWT_ASSERTION
Client Credentials flow:
grant_type=client_credentialsclient_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearerclient_assertion=YOUR_JWT_ASSERTION
Do not invent alternative grant_type values or mix parameters from different flows.