A valid request URL is required to generate request examples{
"id": "reg-pilot-1-printer",
"label": "Imprimante ticket (remplacée)",
"kind": "printer",
"store": "Boutique Rivoli",
"storeId": "store-rivoli",
"register": "Caisse 2",
"status": "ready",
"lastSeen": "2026-07-13T09:00:00.000Z"
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123,
"fieldErrors": [
{
"field": "<string>",
"message": "<string>"
}
]
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123
}
}Update a paired device
Replaces a paired peripheral’s fields WHOLESALE — this is not a patch. ALWAYS read the device first, apply your change to the object you got back, and send the whole thing. An omitted field does not keep its stored value: id, label, kind, store and register are required (omitting one is a 400), and status is OPTIONAL WITH A DEFAULT OF disconnected — so omitting status flips a ready device to disconnected and makes a working register look offline. storeId is OPTIONAL AND HAS NO DEFAULT, which is the same trap one field over: omitting it DROPS the device’s store reference, leaving only the typed store label, and the shop’s screens then have nothing exact to join on. Carry the storeId you read back, and change it (with store set to the new store’s name) only to genuinely move the device. The body’s id is required by validation but IGNORED: the path deviceId is merged in afterwards and wins, so send the same value in both. lastSeen is re-stamped from the server clock on every call (an update IS a state change), so never send it and never rely on it staying put. Use this to re-label a device or move it to another register; writing status records an OPERATOR-ASSERTED state, it does not probe the hardware, so do not use it to ‘fix’ a device reported as error. 404s for an unknown device — updating never implicitly pairs one.
A valid request URL is required to generate request examples{
"id": "reg-pilot-1-printer",
"label": "Imprimante ticket (remplacée)",
"kind": "printer",
"store": "Boutique Rivoli",
"storeId": "store-rivoli",
"register": "Caisse 2",
"status": "ready",
"lastSeen": "2026-07-13T09:00:00.000Z"
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123,
"fieldErrors": [
{
"field": "<string>",
"message": "<string>"
}
]
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123
}
}{
"error": {
"code": "VALIDATION_FAILED",
"message": "<string>",
"statusCode": 123
}
}Authorizations
Authorization: Bearer <token>. Accepts EITHER a Keycloak access token (scopes-in-token) OR an opaque POS session token; both resolve to the same pos.* scope vocabulary the route guards enforce.
Path Parameters
The paired device id, e.g. reg-paris-1-printer.
1Body
1111111Response
The device as it now stands, with lastSeen re-stamped.
The device as it now stands, with lastSeen re-stamped.
111111^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z))$1