Querying

Four query parameters. They are documented narrowly because the implementation is narrow, and a reference that promised more would be worse than one that promises little.

curl "$AUTHORIC_URL/$APP_UID/autocrud/tickets?filter=status:open&sort=created_at%20DESC&limit=25" \
  -H "Authorization: Bearer $TOKEN"

The limits, stated plainly

• filter matches on equality only, on one column. There is no OR, no ranges, no LIKE, and no second condition.
• sort takes one column. Direction defaults to ASC if omitted or unrecognised.
• Both are validated against the table's real columns. An unknown column is rejected rather than ignored.
• Rows and references are matched by uid. filter=uid:<uid> finds one row, and a foreign key is filtered under its _uid name: filter=customer_uid:<uid>. Filtering on id or on the raw customer_id is refused with the name to use instead.
• sort=id means creation order. The id itself is never returned. A uid carries no order, so sorting by it is refused.

Paging

# First page
curl ".../autocrud/tickets?limit=25&offset=0&sort=id%20ASC"

# Next page
curl ".../autocrud/tickets?limit=25&offset=25&sort=id%20ASC"

Always sort when paging. Without an explicit order, the database is free to return rows in any order and pages may overlap or skip.

Filtering is not authorization

filter narrows what you asked for. It does not decide what you are allowed to see — policy does that, and it has already been applied before your filter runs. Removing a filter never widens access.

Next