Table of Contents
API : Employee Passkeys
Introduction
Admin-facing view of an employee's passkeys, and the endpoint that starts the recovery procedure - see webauthn for the full recovery walkthrough and webauthn-credentials for the self-service equivalent.
Every endpoint here requires both a minimum token access level and
req.user.hasWriteAccess()/hasReadAccessOrIsSelf() against the target employee's customer
(CustomerFeature.CUSTOMER) - see employee for the access level table.
Send enrollment link
Issues a single-use, one-hour enrollment token (see webauthn-enroll) and delivers it
to the employee as both a link and a pasteable code. Requires MANAGER or higher, plus write
access to the employee's customer.
| URL | https://api.telecomx.dk/employee/<employee-id>/webauthn/enroll | ||
|---|---|---|---|
| Method | POST | ||
| Header | Authorization | String | Bearer token |
| Body | JSON object | ||
| hostname | String | Required, 3-120 characters. Hostname of the target portal - decides the enrollUrl template and, once the employee actually completes registration there, the rpId the new passkey is created for |
|
| method | String | Required. EMAIL or SMS |
|
Body example
{ hostname: 'admin.telecomx.dk', method: 'SMS' }
Response
| Property | Type | Description |
|---|---|---|
| success | Boolean | Always true |
| method | String | EMAIL or SMS - the method actually used, which can differ from the request: SMS is only used when requested and the employee has an smsNumber; otherwise the message is sent by e-mail |
{ success: true, method: 'SMS' }
The SMS body is Opret din passkey: <link> followed by Kode til Communicator: <token> on its
own line; the e-mail carries the same link and code in the
EMPLOYEE_PASSKEY_ENROLL_LINK template. Issuing a new token silently replaces any unused pending
token the employee already had - only one enrollment can be outstanding per employee.
This action, and the eventual credential registration, are both written to the employee's change log.
Errors
| Error code | Message | Description |
|---|---|---|
| 404 | not_found | Employee does not exist |
| 422 | hostname | hostname does not name a known, ACTIVE portal |
List
Lists an employee's passkeys across every relying party - for support, so an admin can see what a
user has registered without exposing the public key. Requires PERSONAL or higher or being
the employee themselves, plus read access to the employee's customer (waived when it is the
employee's own account).
| URL | https://api.telecomx.dk/employee/<employee-id>/webauthn | ||
|---|---|---|---|
| Method | GET | ||
| Header | Authorization | String | Bearer token |
Response
Same shape as webauthn-credentials's list response - { credentials: [ { _id, name,
rpId, deviceType, backedUp, createdAt, lastUsedAt } ] }.
Errors
| Error code | Message | Description |
|---|---|---|
| 404 | not_found | Employee does not exist |
Delete
Deletes one of an employee's passkeys. Requires MANAGER or higher, plus write access to the
employee's customer.
| URL | https://api.telecomx.dk/employee/<employee-id>/webauthn/<credential-id> | ||
|---|---|---|---|
| Method | DELETE | ||
| Header | Authorization | String | Bearer token |
Response
{ success: true }
Deliberately does not check “last credential” the way webauthn-credentials's
self-service delete does: an admin can remove the last passkey of a webauthnOnly employee. That
is exactly what a support agent needs when the device holding it is lost - the employee is then
recovered through the enrollment-link procedure above, not left permanently locked out.
The deletion is written to the employee's change log.
Errors
| Error code | Message | Description |
|---|---|---|
| 404 | not_found | Employee does not exist |
| 404 | credential | Credential does not exist, or belongs to a different employee |