Idempotency-Key Header vs Lookup-Before-Create for Okta User Creation Retries

An integration that creates Okta users must retry POST /api/v1/users calls that fail with a 429 or 5xx, yet a retry after an ambiguous failure risks provisioning a second account for the same person. Two documented directions exist: send an Idempotency-Key header so Okta replays the original response for a repeated request, or look up the user by login before re-submitting and treat an existing match as success.

The header approach is documented for user creation, with keys retained for 24 hours. That retention window and the unclear coverage on other write endpoints are the real constraints: a backlog that lags more than a day, or a later extension to group and application creation, may fall outside documented behavior. Lookup-before-create has no expiry, but it leaves a race between the check and the create when workers run concurrently, and it needs a dependable natural key for every resource type.

Assuming Okta API documentation current as of October 2026, which mechanism should be the primary safeguard against duplicate users, and is layering both justified?

• Is Idempotency-Key documented as supported on write endpoints beyond user creation, such as groups or applications?
• What is the documented outcome when the same key is retried after the 24-hour retention window has expired?