Skip to main content
The API has two kinds of endpoint. A list such as /assets or /work_orders is read with GET, and you shape the answer with query parameters. An action such as /rpc/create_asset is called with POST, and its arguments are the keys of a JSON body.

Choose the columns

select names the columns you want. Without it you get every column, which on /assets or /work_orders is a lot.

Filter

Add a parameter named after a column, with an operator and a value: Several filters on one request must all match.
The full set of operators is in PostgREST’s own reference, which is the server answering these requests.

Sort and page

order sorts, and limit and offset page. Send Prefer: count=exact to learn how many rows match in total. The answer then has a Content-Range header such as 0-1/10, meaning rows 0 to 1 of 10.

Find an id

Actions take ids, and the record you have in hand usually has a code instead. Two ways to turn one into the other:
  • Filter the list by its code. Most lists carry the record’s own number or code, so /asset_meters?select=meter_id&code=eq.P-102-HRS returns the meter whose code is P-102-HRS.
  • Ask list_options. It returns the id and label of every record a field may point at, and takes a search term:

Call an action

Every action is a POST to /rpc/<name>. Each key of the JSON body is the name of one argument, and an argument you leave out takes its default:
An action that takes p_values takes a record’s fields inside it, as an object. The page for each of those actions, under Integration API in the sidebar, lists the fields.

What you can see

A token sees what its account may see. A list returns only the rows at the sites the account can reach, and an action is refused when the account does not hold its permission. Two accounts can make the same request and get different answers, and both are correct.