Skip to main content
Base URL https://api.poixe.com/v1/recoveries
Recoveries (interrupted response recovery) addresses a common situation: you send a non-streaming request (stream=false), and the upstream model actually generates the result successfully, but the connection is interrupted, so your client never receives the response. In this case, the request is usually still completed by the upstream provider and billed. To avoid wasting resources and money on duplicate requests, Poixe temporarily stores the key data and response of that request, so you can try to recover the result after the request fails.
Note: The Recoveries endpoints are free of charge. A stored record is created only when a request is interrupted.

​
Use cases

When a non-streaming request appears to fail or time out on the client, but you suspect the upstream provider may have finished processing it, try Recoveries first:
  • The client network drops or fluctuates, interrupting the connection
  • A CDN or proxy layer forces a timeout or closes the connection
  • A brief system interface fluctuation causes the connection to be closed
  • The request takes a long time, and the client times out before the upstream provider finishes

​
Walkthrough: how to recover after an interruption (core steps)

1

Send a non-streaming request (stream=false)

For example, call an endpoint such as Chat Completions or Responses with stream=false (non-streaming response).
2

The connection is interrupted: the client shows a failure, but the upstream may have finished

Common causes include a dropped client network, a CDN-enforced timeout, or a brief system interface fluctuation that closes the connection.
Note: A non-streaming request may already have been processed and billed normally by the upstream provider, with only the result failing to reach the client. We recommend trying to recover it first and then deciding whether to retry, to avoid being charged twice.
3

The system automatically stores the result of this request

Poixe stores the request and response as a recovery record for later retrieval.
Note: This step is completed automatically by the system. You do not need to do anything extra.
4

Get the request_id (choose any one)

You can get the request_id in any of the following ways:
  • Option A: Console. Check the corresponding request log on the Logs page and get the request_id directly
  • Option B: Call List stored responses to get the request_id from the list
  • Option C: Call lookup, submit the original request JSON, and receive candidate records along with the request_id
5

Recover the full content by request_id

Use Get stored response details: GET /v1/recoveries/{request_id} to retrieve the original request and the complete response body.
6

Optional: clean up stored records

After recovery, you can choose to:

List stored responses

GET /v1/recoveries

Get details (recover a response)

GET /v1/recoveries/

lookup (without a request_id)

POST /v1/recoveries/lookup

Delete a single stored response

DELETE /v1/recoveries/

Delete all stored responses (supports dry_run)

DELETE /v1/recoveries?all=true

​
Retention period and cleanup policy

Recoveries records are kept for 3 days by default and are automatically deleted after the retention period expires. If you want to clean them up immediately, you can call a delete endpoint (single or all).

​
Data security and compliance

Poixe follows strict data and security standards. Recoveries data is used only to help you recover the responses of interrupted requests, and is protected by authentication (only the current user can access their own records). We do not use, process, or analyze this data in any way, and it is not used for any purpose. The data is stored temporarily according to the retention policy and is automatically cleaned up when it expires.

​
Recommendation for long-running requests: use a direct endpoint to avoid CDN-enforced timeouts

The main endpoint is forwarded through a CDN, which has a fixed connection timeout policy. For requests that may take a long time (for example, long outputs, complex tool chains, or extended reasoning), the CDN may close the connection before the response is returned. To avoid such interruptions, you can replace the main endpoint with a direct endpoint (no CDN). Poixe provides two direct endpoints (dc8 / dc15) that you can use directly as alternative addresses for the main endpoint, so they are not affected by CDN-enforced timeouts. If you have higher availability requirements, we recommend configuring both dc8 and dc15 in your client and switching automatically when a request fails, to improve stability.
For background and guidance on choosing, see: Base URL