Pagination

List endpoints take page and limit as query parameters and report the total in meta:

curl "https://shellius.example.com/api/audit?page=2&limit=50" \
  -H "Authorization: Bearer $SHELLIUS_TOKEN"

{
  "success": true,
  "data": { "items": [ ] },
  "meta": { "page": 2, "limit": 50, "total": 1312 }
}

page starts at 1. Each endpoint sets its own default and maximum limit — the audit log, for example, defaults to 25 and allows at most 100. The reference lists the bounds for each endpoint under Query parameters. Asking for more than the maximum is a 400, not a silent clamp.

To walk a whole collection, keep requesting until page × limit ≥ total.

Exports exist for the big ones

Do not page through the whole audit log to archive it. GET /api/audit/export streams it as CSV or JSON with the same filters.

Rate limits

Shellius rate limits the endpoints an attacker would hammer, by IP address:

Endpoints	Limit
Sign-in, refresh, second-factor, login options	10 requests per minute
Accepting an invite, resetting a password	5 requests per 15 minutes
Device flow polling	30 requests per minute

The reference marks each limited endpoint. Over the limit you receive:

{ "success": false, "error": { "code": 429, "message": "Too many requests, please try again later" } }

with the standard RateLimit-* response headers telling you when the window resets. Some per-user actions — emailed codes, for instance — have their own tighter counters and also answer 429.

Behind a proxy, set it up properly

Limits are per client IP address. If your reverse proxy does not pass the real client address through, every user shares one bucket and sign-ins will start failing under ordinary load.