# Relynk resource types

Looking up type keys (rooms, equipment, kinds of sensor) and the relationships a building uses, before filtering resources or points by type.

Each function is a POST to the path shown, relative to the connector's base URL, with its body as JSON; the response is JSON. The types below are JSDoc.

Notes:
- Add `?tenantId=<id>` to every call when `GET /me` lists more than one tenant for the user.
- Errors are `{ "error": { "code", "message" } }`; a 400 message says how to change the request.
- Lists page with `nextCursor` (or `offset` and `hasMore`). Times are Europe/Oslo, ranges half-open `[from, to)`, ids are UUIDs. `null` means no data.
- A path never changes its contract; a new version gets a new path.

## POST /resourceTypes.list/v1

The REC/Brick types the tenant actually uses, with how many resources of each type, e.g. to find the type keys of rooms, air handling units or temperature sensors before filtering other functions by them.

Body: `ResourceTypesListInput`. Response: `ResourceTypesListOutput`.

```js
/**
 * @typedef {Object} ResourceTypesListInput
 * @property {string} [buildingId] A building id (from buildings.list). Matches the building itself and everything that is part of it (uuid)
 * @property {Array<"Asset" | "Space" | "Collection" | "Point" | "Unit">} [mainTypes] Only these main types (min items 1)
 */

/**
 * @typedef {Object} ResourceTypesListOutput
 * @property {Array<ResourceTypesListOutputTypesItem>} types
 */

/**
 * @typedef {Object} ResourceTypesListOutputTypesItem
 * @property {string} typeKey Key to filter by, e.g. "brick_Temperature_Sensor"; filters include subtypes
 * @property {string} name
 * @property {string} mainType Asset, Space, Collection, Point or Unit
 * @property {string} typePath Position in the type hierarchy, e.g. "Point.Sensor.Temperature_Sensor"
 * @property {string | null} parentTypeKey
 * @property {number} count Resources of exactly this type
 */
```

## POST /resourceTypes.relationships/v1

How types are connected in one building: which relationships exist between which types, and how often. Use it to plan a walk with resources.related, e.g. brick_Has_Part from the building to levels to rooms, or brick_Feeds from an air handling unit to the rooms it serves.

Body: `ResourceTypesRelationshipsInput`. Response: `ResourceTypesRelationshipsOutput`.

```js
/**
 * @typedef {Object} ResourceTypesRelationshipsInput
 * @property {string} buildingId A building id (from buildings.list). Matches the building itself and everything that is part of it (uuid)
 */

/**
 * @typedef {Object} ResourceTypesRelationshipsOutput
 * @property {Array<ResourceTypesRelationshipsOutputRelationshipsItem>} relationships
 */

/**
 * @typedef {Object} ResourceTypesRelationshipsOutputRelationshipsItem
 * @property {string} fromTypeKey
 * @property {string} relationship Relationship key for resources.related, e.g. "brick_Has_Part"
 * @property {string} name Read from → to, e.g. "Has Part"
 * @property {string} inverseName Read to → from, e.g. "Is Part Of" (resources.related direction "in")
 * @property {string} toTypeKey
 * @property {number} count
 */
```