I gave you a long response in the near-duplicate forum topic you created.
If you want a server-stored conversation and want it in the minimal number of API calls, you can use the Responses API’s original “previous response ID” mechanism I don’t mention there.
Always send your “instructions” field string in every API call for the behavior you want the AI model to have. That’s your “developer message”.
Send “input” with the user message, and capture the received response ID from the API call.
In follow-up API calls, always use the most recent Response ID as the value for the “previous_response_id” API parameter. That run then includes a chain of previous messages and responses along with the latest input you run.
Result: you have to still have your own database, recording response IDs for a chat session for a user and its current state. The API has to retrieve those messages from its own database to prepare the API call.
Perhaps you don’t need to wait for a user to start a new chat in order to create more conversation IDs that are ready to use if using the Conversations API? Create your own cache of IDs that are ready to employ.
Better result: besides sending “instructions”, send all the messages yourself of a user’s chat history session you maintain. The only backend performance issue in retrieving from database lookups is your own.