AssetCenter
Location event setup
Configure the custom events your organization logs against locations, such as fire inspection, through the public API.
Last updated
Event definitions
Use https://my.assetcenter.app/api/v1/location-events to configure the events your organization can log against locations. Definitions include appearance, availability, an optional status change, fields, and display ordering. Location event setup works the same way as asset event setup, with one group (location) and no category or cost-category restrictions.
To record an event against a location, use log a location event. Read recorded history through location timelines.
Endpoints and permissions
| Action | Endpoint | Permission |
|---|---|---|
| List definitions | GET /api/v1/location-events |
location-events:read |
| Get a definition and fields | GET /api/v1/location-events/{event} |
location-events:read |
| Get setup options | GET /api/v1/location-events/options |
location-events:read |
| Create a definition | POST /api/v1/location-events |
location-events:create |
| Update a definition and fields | PATCH /api/v1/location-events/{event} |
location-events:update |
| Delete an unused definition | DELETE /api/v1/location-events/{event} |
location-events:delete |
| Change display order | PUT /api/v1/location-events/{event}/position |
location-events:update |
The token fixes the organization, regardless of its creator’s selected account. Its creator must remain an active administrator. These permissions are independent of location-record permissions and of asset event setup. New Read Only keys include location-events:read; new Full Access keys include all four. Custom keys can select each separately. Existing keys keep their current permissions; create a replacement key to grant the new access.
Status-changing events
Set sets_status to active or inactive to make an event also change the location’s status, for example an event that marks someone as having left. Logging such an event additionally requires locations:lifecycle, follows the same date rules as a status change, and records a status event next to it when the status actually changes.
Fields and history
Definitions start with the built-in date, time, and notes fields. Add custom fields of any supported type. PATCH changes only supplied properties. Omitting fields preserves them; supplying fields replaces the complete field list in array order. Existing field IDs and slugs must be retained. Fields with saved values cannot be removed or change datatype; hide them with visible: false.
Definitions referenced by logged location events, or with saved field values, cannot be deleted. Set visible to false instead. Every write requires Idempotency-Key, with successful responses replayable for 24 hours.