> ## Documentation Index
> Fetch the complete documentation index at: https://docs.assetinfinity.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# The API

> A generated description of the endpoints behind the application, published without a compatibility guarantee.

<Warning>
  **This API has no compatibility guarantee.** The endpoints below are the ones the application itself
  uses. They are generated from the database schema and republished whenever that schema changes, so a
  path, a parameter or a response shape can move in any release without notice, without a version
  number, and without an announcement.

  It is published because knowing what the product can do is more useful than not knowing. Build
  against it only where you can afford to fix it afterwards, and tell us what you are building — an
  endpoint somebody depends on is one we can decide to keep.
</Warning>

## What this describes

Every screen in the application is a client of this API. There is no separate integration surface: the
work orders you see in the product are the rows `/open_work_orders` returns, and creating one from the
API runs the same function, under the same permissions, with the same audit trail as pressing the
button.

That has two consequences worth understanding before you read further.

**Your permissions apply.** A token carries the roles and site scope of the person it was issued to.
An endpoint you can reach still refuses the rows that person cannot see, and refuses the writes their
permissions do not allow. Nothing here is a way around the product's own rules.

**Reads and writes are shaped differently.** Reads are views — filter, order and paginate them with
[PostgREST's query syntax](https://postgrest.org/en/stable/references/api/tables_views.html). Writes
are functions under `/rpc/`, each doing one thing completely, because the transactional logic lives in
the database rather than in a client.

## Getting a token

Every endpoint except sign-in needs one. Exchange an email and password for a session:

```bash theme={null}
curl -X POST https://app.assetinfinity.ai/api/rpc/sign_in \
  -H 'Content-Type: application/json' \
  -d '{"p_email": "you@example.com", "p_password": "..."}'
```

The response carries a `token`. Send it on every subsequent request:

```bash theme={null}
curl https://app.assetinfinity.ai/api/open_work_orders \
  -H "Authorization: Bearer $TOKEN"
```

<Note>
  Tokens are short-lived and idle out. `/rpc/refresh_session` renews one that is still within its
  session ceiling; past that, sign in again. A tenant on its own hostname uses that hostname here
  instead of `app.assetinfinity.ai`.
</Note>

## Where the descriptions come from

Each endpoint's summary is written against the database object it is generated from, so it describes
what that endpoint actually does rather than what a specification hoped it would. Some have no summary
yet — those are endpoints whose underlying object has not been documented, not endpoints that do
nothing. The shape shown is still generated from the real schema and is accurate.


## Related topics

- [AI settings](/config/ai.md)
- [Copilot activity](/analytics/copilot.md)