I’m bringing this issue back to your attention because it’s still causing significant friction in managing access codes. It appears there is a synchronization gap between the Nuki servers/API and the physical Smart Lock that remains unresolved. Sorry if there is already a solution.
The Problem
I recently created a keypad code via the app, but it never successfully synced to the Smart Lock. This has led to a “ghost entry” situation:
Ghost Entry: When I call /smartlock/[lock id]/auth, the code is listed.
Failed Deletion: When I attempt to delete this code, the API returns a 204 No Content (indicating success). However, when I refresh the list, the code is still there.
Conflict: I cannot re-create the code because the system throws an error stating the PIN already exists.
Effectively, I am stuck with a non-functional code that I cannot remove or overwrite.
Suggested Improvements
To prevent these deadlocks, I’d like to propose two logic changes:
Forced Deletion: The API should always prioritize the deletion of a record in the database, even if the physical lock is temporarily unreachable, to allow for a “clean slate” retry.
Sync Logic & Error Handling: Implement a periodic synchronization (e.g., a daily heartbeat at 00:00) between the server and the lock. Alternatively, provide a Webhook notification or a specific error state if a code fails to commit to the hardware, rather than returning a false-positive 204.
Workarounds?
Has anyone found a solid code-based workaround for forced-clearing the auth list when the server and lock are out of sync?
I look forward to hearing your thoughts or if there’s a fix in the pipeline.
When you call the /smartlock/{id}/auth endpoint, the data will be fetched from the server. If the authorisation is present there, it means your locally (via smartphone) created authorisation has been synced to the server. Can you explain what you mean by “ghost entry” in this case? Do you not see the authorisation where you expect it to be?
Regarding the delete request, please note that our API is asynchronous. A 204 response implies the request was accepted by the server, but it doesn’t necessarily mean that the request was then executed on the smart lock (more about this handling of asynchronous API requests can be found in our API documentation). To determine what the error is when attempting to delete the authorisation, you can use the webhook functionality that’s included in our Advanced API. A detailed error message will be contained in the webhook payload.
I understand that the API is asynchronous and that 204 signifies acceptance rather than completion. However, the issue I’m highlighting is that this asynchronous process never completes, leading to what I call a “ghost entry.”
To clarify:
The “Ghost Entry”: The authorization exists on the server (it shows up in the /auth call), but it does not work on the physical Keypad (when checking the Nuki app). Because the server thinks it exists, I cannot recreate it.
The Deadlock: When I try to delete it, the server accepts the command (204), but the change never reaches the lock. Because the server waits for the lock to confirm the deletion before actually removing it from the database, and that confirmation never comes, I can delete it time after time, the entry stays on the server forever.
The problem with the Webhook suggestion: While a webhook can tell me that it failed, it doesn’t solve the fact that I am now blocked. I cannot delete the code (it stays in the system) and I cannot add it (it already exists).
My question to you is: How can I force-delete an authorization from the server when the physical lock is unable to confirm the deletion? Is there a way to break this deadlock without a full factory reset of the hardware?
