Fallback pattern when a third-party API supports neither idempotency keys nor sender-chosen IDs: before creating, query an index endpoint with enough uniquely-identifying data to detect an existing resource; if found, acknowledge and stop; otherwise create. On retry, the check re-discovers the previously-created resource and avoids a duplicate. Caveats: prone to race conditions with multiple senders, and vulnerable to receiver-side consistency issues where the resource is created but a surrounding workflow fails invisibly. Sometimes the best available option, but inferior to proper idempotency-key support.