{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigololhineigdl56jterxiktqsdcbxx7crwboekrx6zjb7jm33djy",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mkg5olcpmnr2"
  },
  "path": "/t/realtime-api-is-it-possible-to-track-with-event-triggered-a-response/1379703#post_2",
  "publishedAt": "2026-04-26T17:16:39.000Z",
  "site": "https://community.openai.com",
  "textContent": "I don’t think the Realtime API currently exposes a direct “triggering client event ID” field on server events.\n\nresponse.create can include an optional client-side event_id, but the later response.created event has its own server-side event_id and the new response.id. It does not appear to echo the original response.create.event_id.\n\nFor debugging, the best workaround is to include\nyour own correlation ID in response.metadata:\n\n\n    {\n      \"type\": \"response.create\",\n      \"event_id\": \"client_event_123\",\n      \"response\": {\n        \"metadata\": {\n          \"client_event_id\": \"client_event_123\",\n          \"debug_reason\": \"manual_retry\"\n        }\n      }\n    }\n\n\nThen inspect response.metadata on response.created or response.done and map it to the returned response.id.\n\nOne related detail: only one Response can write to the default Conversation at a time, but out-of-band responses can run in parallel. The docs specifically call out metadata as a useful way to disambiguate simultaneous Responses.",
  "title": "Realtime API: is it possible to track with event triggered a response?"
}