API Request Troubleshooting
404, 401, 403, 409, 422, 429, and 500 investigation.
Use status code, error code, request ID, route, method, and auth context to classify the failure.
Source boundary
Source boundary: AutoCore current main 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60, checked against immutable v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f.
The exception filter standardizes error codes and request IDs. Confirm API prefix, method, DTO shape, token validity, permission/ownership, conflict state, throttling, and server logs before changing the client.
| Check | Source-backed expectation |
|---|---|
| Scope | Do not paste bearer tokens, cookies, or full provider bodies into tickets. |
| Evidence | Use placeholders, timestamps, release identity, route, status, and request ID where relevant. |
| Safe action | curl -i https://api.example.invalid/api/v1/does-not-exist |
| Stop condition | Unknown authorization, destructive impact, secret exposure, or conflicting evidence. |
Verification
Run the safe check, record its result, and compare the outcome with the documented contract. If the result depends on external configuration or provider availability, mark it as configuration-dependent rather than claiming a product guarantee.
curl -i https://api.example.invalid/api/v1/does-not-exist
Safety boundary
Examples are non-production and use placeholders. Do not deploy, reset, force a migration, create secrets, activate providers, replay sensitive work, or expose private data from this page.