Manage multi-turn conversation state on the OpenAI Responses API using previous_response_id, the store parameter, and the Conversations API, accounting for retention and zero-data-retention constraints

Documented steps

1. For simple chaining, pass previous_response_id:'<prior response id>' on the next POST /v1/responses call; the server pulls prior context without you resending the input array.
2. Understand the default: store defaults to true, and 'Response objects are saved for 30 days by default.' They are retrievable via GET /v1/responses/{response_id} and visible in dashboard logs.
3. Re-send 'instructions' on every turn when chaining with previous_response_id; system-level guidance is not automatically carried forward the way it is inside a Conversation object.
4. For durable long-lived state, create a conversation first: POST /v1/conversations.
5. Attach it per request with the 'conversation' parameter, e.g. responses.create(model=..., input=[...], conversation=<conversation_id>), instead of previous_response_id.
6. Note the retention difference: 'Conversation objects and items in them are not subject to the 30 day TTL. Any response attached to a conversation will have its items persisted with no 30 day TTL.'
7. For stateless operation, set store:false and manage history yourself by appending the full prior 'output' array into the next request's 'input'.
8. When replaying manually for reasoning models, include every output item (reasoning, function_call, function_call_output), not just the final message.
9. For zero-data-retention environments, set store:false. Nothing is persisted server-side, so previous_response_id chaining is unavailable and manual replay is required.
10. Budget accordingly: chaining saves request-construction effort, not tokens.