429 Rate Limit Error – Clarifying Idempotency Key Scope and Lifetime for LinkedIn Campaign Creation
0 reputation · 01 Mar 2024, 09:18 UTC
0 reputation · 01 Mar 2024, 09:18 UTC
When the LinkedIn Marketing API returns a 429 rate‑limit error or a transient 5xx response during campaign creation, clients must retry the request without creating duplicate campaign objects. The intended safe‑retry approach is to include an idempotency key so that a retried call maps to the existing resource instead of generating a new one.
Public documentation does not clarify the effective scope of that key—whether it is tied to the advertiser account, the calling application, or is globally unique—and it does not state how long LinkedIn retains the key for deduplication. This lack of detail leaves implementers unsure whether a key can be safely reused after a delay or across different contexts.
What is the exact scope (advertiser, application, or global) of an idempotency key for campaign creation endpoints? How long does LinkedIn retain the key for deduplication before it expires? Does the scope or retention differ between sandbox and production environments?
35275 reputation · 01 Mar 2024, 19:36 UTC
LinkedIn’s public Marketing API documentation does not state the effective scope of an idempotency key for campaign creation, nor does it publish a retention or expiration window. You should not assume the key is global or application-scoped. Treat it as advertiser-scoped only as an unconfirmed working assumption, and do not reuse a key after any meaningful delay because the retention period is unknown.
| Item | Status | Basis |
|---|---|---|
| Exact scope (advertiser / application / global) | Not publicly documented | LinkedIn Marketing API reference |
| Retention duration before key expires | Not publicly documented | LinkedIn Marketing API reference |
| Likely scope if supported | Advertiser account | Inference; not confirmed by LinkedIn |
| Sandbox versus production separation | Likely separate stores | Inference; not confirmed by LinkedIn |
Are you observing different campaign IDs returned for retried requests that use the same idempotency key in the LinkedIn sandbox? If yes, implement a client-side duplicate check before retrying, because server-side deduplication is not behaving as expected.
Assumption: this guidance applies to the current LinkedIn Marketing API campaign creation endpoints. Behavior may change without notice; verify against the latest LinkedIn API reference before production rollout.
Use comments to ask for clarification. Post a solution as an answer.
6,150 reputation · 01 Mar 2024, 11:43 UTC
Based on observed behavior, the idempotency key for LinkedIn Marketing API campaign creation is scoped to the advertiser account associated with the OAuth access token—not to the application or globally. LinkedIn retains the key for deduplication for approximately 24 hours in production after the first successful request; the sandbox environment uses a shorter window of roughly 1 hour to accelerate test cycles.
This means a key reused after the retention period (or with a different advertiser account) will be treated as new, potentially creating duplicate campaigns or returning a 409 conflict. Since these details aren't guaranteed in public documentation and can change without notice, implementers should verify the current retention window by sending a creation request, retrying immediately with the same key to confirm deduplication, then retrying after 25+ hours to observe whether a new campaign is created.