Skip to main content
Errors normally return application/problem+json. Use the stable code field in your error-handling logic. The detail text explains the error for a person and can change. Each endpoint’s reference lists its responses and examples.

Choose the next action

This table covers common cases, not every endpoint-specific code. A timeout does not guarantee that work stopped. Repeating example generation can save another example. Each feedback submission creates a new record, even if you send the same feedback again. Experimental Ask also saves answers and follow-up turns; repeating a request can create another thread or turn.

Keep the request ID

Save X-Request-ID from the response headers. A normal problem response’s instance matches this ID. Include it with the endpoint, approximate time, status and problem code when reporting a failure. Remove authorization headers and sensitive request content from reports. If the service cannot create a request identity, it returns an empty HTTP 500 without a request ID. Clients must handle that case without assuming every failure body is JSON.

Browser request errors

A browser can block a cross-origin response before the playground can display its status or body. Check the destination URL and whether your browser reports a CORS failure. A browser network error alone does not prove your token is invalid or that no work occurred. The playground sends live requests from https://docs.githits.com. If you are reading a preview or another copy of these docs, use the cURL quickstart in your own terminal. The API does not allow those other sites to send playground requests.