Undeletable auths + authId reuse -> new keypad codes never reach the device (still unresolved, real guest impact)

Nuki APIs Web
1

Dear All

This is a follow-up to a problem that has been reported here several times and closed for inactivity without a resolution, e.g. “Persistent Sync Issue: Unable to delete/overwrite Keypad entry (Error 204 but entry remains)” (closed 23 March 2026, link) and “Nuki Web API authorization update/synchronization inconsistency”.

In February Andrew O’Connell confirmed the root cause (asynchronous two-phase commit, device is the source of truth, deletions stay pending forever with no reconciliation). It is still happening, it is getting worse, and it now affects real guest arrivals. I manage a guesthouse with 10 Smart Locks and provision guest keypad codes via the Web API.

Baseline (as previously reported): expired keypad authorizations (type 13) cannot be removed - DELETE returns 204 but the row persists indefinitely, PUT on the same row also fails, and a forced lock sync does not purge them. Some are over a year old.

Two twists that make this more than cosmetic:

  1. authId REUSE OVER DEAD ROWS. Creating a new code on a lock that still holds such a dead row makes the cloud assign the new authorization the SAME authId as the dead row. I now have locks where one authId is shared by three authorizations (one dead, two live). In several collision cases the new code exists in the Web API but is NEVER provisioned to the device (absent from the keypad list in the app), so the guest is locked out. Creating it manually from the app is the only workaround, which then leaves duplicate rows with the same PIN that the device rejects with error 0xE0 - permanently frozen, neither updatable nor deletable.

  2. DELETING A DEAD ROW CAN KILL A LIVE CODE. When an expired row sharing an authId with an active guest code was finally removed, the deletion also removed the live code.

Concrete questions:

  • Is there ANY supported way to force server-side cleanup of authorizations that reject both DELETE and PUT, so the allocator stops reusing their authId? These rows also contain former guests’ names that I am required to erase as data controller.

  • Which decentral webhook feature reliably confirms that a created authorization has actually been provisioned to the device - is DEVICE_AUTHS the right one to detect cloud-only codes and trigger a retry, given that API-triggered confirmation webhooks require Advanced API / the central URL?

  • Can the authId allocator be fixed so it never reuses an id still referenced by an undeletable row?

I can share smartlockIds, authIds, record ids and timestamps privately. This has moved from annoyance to guests being unable to enter, so a real answer (not another auto-closed thread) would be greatly appreciated.

Thank you!
Marco

2

Two weeks on, still no response from the Nuki team, and nothing has changed.

To restate the impact, because it is not cosmetic: guests are being locked out.
Newly created keypad codes sometimes never reach the device, expired type-13
authorizations return HTTP 204 on delete but stay on the account indefinitely, and
the reused authIds collide with live guest codes (deleting a dead one has taken down
a live guest code mid-stay).

Could someone from the Nuki team pick this up, or point me to the correct channel to
escalate? I can provide my account ID, the lock IDs and the specific colliding
authIds on request.

I would also note that these undeletable authorizations hold guests’ personal data
(names and access codes) that I am unable to erase on request, so there is a
data-retention concern on top of the operational one.

Thank you.