LinkedIn Idempotency-Key: Uncertain Duplicate‑Write Prevention Across Mutating Endpoints

Goal

Enable safe retry logic for LinkedIn mutating calls (POST, PUT, PATCH) by leveraging the documented X‑Restli‑Idempotency‑Key header, while ensuring that duplicate writes are not created when a request is retried.

Constraints & Uncertainty

• The API documentation states that the idempotency key is optional and may be supported by some endpoints, but it does not list all endpoints that honor it.
• There is no public specification of the server’s behavior when the same key is used with a different request body, or how long a key remains active before the server may reject it.
• Behavior may differ between the legacy REST API and the newer GraphQL mutation interface.

Specific Questions

1. For which LinkedIn REST API endpoints does the X‑Restli‑Idempotency‑Key guarantee exactly‑once semantics on retry?
2. What response does the server return when a repeated request uses the same idempotency key but a modified payload?
3. Is there a documented expiration period or rate‑limit that causes the server to treat a reused key as invalid after a certain time?