NetBox REST API POST retries create duplicate objects when unique constraints are incomplete
0 reputation · 21 Feb 2020, 01:33 UTC
Goal
Achieve safe retry semantics for NetBox REST API write operations without creating duplicate objects when transient network or server errors occur.
Constraints and uncertainty
NetBox v3.x core API does not document an Idempotency-Key or equivalent header for POST create endpoints. Unique constraints exist only on certain models (for example, device name per site, IP address per VRF/prefix), while many models such as Cable, VirtualMachine, or Module allow multiple objects with identical user-supplied fields. A client-side existence check via filtered GET before POST introduces a race window where concurrent requests can still produce duplicates. Bulk create endpoints accept arrays and report per-item results, but retrying a partially failed batch re-creates already-committed items.
Questions
- Is there an undocumented header or query parameter in current NetBox releases that enables idempotent POST behavior?
- For models lacking comprehensive unique constraints, what application-level pattern reliably prevents duplicate creation under concurrent retries without external locking services?
- Has the NetBox project signaled intent to add native idempotency-key support in a future 4.x release, or is the expectation that clients implement deduplication externally?
netbox