Pagination

pagination conventions vary across modules and protocols this page documents what's common and where exceptions live rest list endpoints most rest list endpoints accept query params param default notes offset 0 zero indexed limit 50 (varies) max varies per endpoint; some allow up to 1000 sort varies field\ asc / field\ desc filter none endpoint specific response shape (typical) { "items" \[ ], "total" 1234, "offset" 0, "limit" 50 } use total to know how many pages remain graphql list operations most graphql list operations accept an input object query { listdevices(input { limit 100, offset 0, filter { name { contains "plc" } }, sort \[{ field "name", order "asc" }] }) { items { id name } total } } field casing follows the operation's schema (le devicehub uses pascalcase; lem uses camelcase) check the operation on api litmus io to confirm lem async task subtasks get /api/v1/async task/{taskid}/subtasks returns all subtasks usually small, no pagination get /api/v1/async task/subtasks (cross task history) accepts from / to timestamp filters; pagination via offset and limit when in doubt the endpoint's example on api litmus io shows the actual parameter names and casing default limits are conservative prefer pagination over assuming "all rows fit" for very large lists (e g tags across thousands of devices), filter at the source ( filter in graphql, query params in rest) instead of paginating the entire set