Operation

Claim a device pairing

POST/devices/pairing/claim

Staff claim a pending pairing for their organisation, naming the device and granting roles.

Headers

Idempotency-KeystringOptional: Makes the write safe to retry. The first request with a key does the work and its response is stored for 24 hours; a repeat with the same key and the same request (method, path, query, X-Ticketlayer-Channel, TL-Version and body) gets that stored status and body back, marked `Idempotent-Replay: true`, without running again. The key is scoped to your organisation and your credential. The same key with a different request is 422 IDEMPOTENCY_KEY_REUSED; a repeat while the first is still running waits for it, then answers 409 IDEMPOTENT_REQUEST_IN_PROGRESS if it has not finished. Only a 2xx is stored: after an error the key is free again. Omit the header and the request behaves as it always has.

Body

userCode*string

name*string

accountId*string

locationIdstring

▼accountRoles*object[]

accountId*string

roleId*string

Returns

Pairing claimed

Errors

400: Bad Request - Invalid input
401: Unauthorized - Authentication required
403: Forbidden - Insufficient permissions
404: Not Found - Resource not found
500: Internal Server Error

Every error names its code and links to it. All error codes

curl -X POST "https://api.ticketlayer.com/v1/devices/pairing/claim" \  -H "Authorization: Bearer tlak_..." \  -H "X-Ticketlayer-Org: your-org-slug" \  -H "Content-Type: application/json" \  -d '{    "userCode": "string",    "name": "string",    "accountId": "string",    "locationId": "string",    "accountRoles": [      {        "accountId": "string",        "roleId": "string"      }    ]  }'

Response 200

{
  "pairingId": "string",
  "status": "string",
  "deviceInfo": {
    "type": "string",
    "name": "string",
    "platform": {}
  }
}

Claim a device pairing

Headers

Body

Returns

Errors

Try it in test mode

Body