When registering devices in bulk via the device registry API (batch of 200 devices), the operation returns 409 Conflict error for about 30% of devices. The error indicates “Device already exists” but these are brand new devices that have never been registered.
I’m using bulk device onboarding with generated device IDs following the pattern DEV-{timestamp}-{sequence}. How should I handle duplicate device ID detection in bulk operations? Also, how do I parse the batch response to identify which specific devices failed and which succeeded so I can retry only the failures?
The 409 error usually means the device ID already exists in the registry. Are you sure your ID generation is producing unique IDs? If multiple processes are running bulk registration simultaneously, you might have collisions.
Yes, the batch response maintains request order. Each element in the response array corresponds to the same index in your request array. The response includes the device ID, status code (201 for success, 409 for conflict, etc.), and error message if applicable. You can iterate through the response and build a list of failed devices with their specific error codes.
I’ve encountered this before. The bulk registration API processes devices sequentially within the batch, but if you’re running multiple bulk operations in parallel, you can definitely get ID conflicts. The timestamp-based ID generation isn’t sufficient if multiple registration processes start within the same second. Add a random component or use UUIDs instead. For parsing batch responses, the API returns an array with the status of each device - you need to iterate through it and collect the failed device IDs for retry.
We do have multiple gateway devices running registration processes, which could explain the collisions. How do I structure the batch response parsing? Does the response maintain the same order as the request so I can match by index?
For the ID generation issue, consider implementing a distributed ID generation service or using the device’s hardware serial number as part of the ID to guarantee uniqueness. The timestamp approach is inherently prone to collisions in distributed systems. Also, implement idempotency in your registration logic - check if a device exists before attempting to register it in bulk operations.