AssetCenter
Person event setup
Configure the custom events your organization logs against people, such as badge issued, through the public API.
Last updated
Event definitions
Use https://my.assetcenter.app/api/v1/person-events to configure the events your organization can log against people. Definitions include appearance, availability, an optional status change, fields, and display ordering. Person event setup works the same way as asset event setup, with one group (person) and no category or cost-category restrictions.
To record an event against a person, use log a person event. Read recorded history through person timelines.
Endpoints and permissions
| Action | Endpoint | Permission |
|---|---|---|
| List definitions | GET /api/v1/person-events |
person-events:read |
| Get a definition and fields | GET /api/v1/person-events/{event} |
person-events:read |
| Get setup options | GET /api/v1/person-events/options |
person-events:read |
| Create a definition | POST /api/v1/person-events |
person-events:create |
| Update a definition and fields | PATCH /api/v1/person-events/{event} |
person-events:update |
| Delete an unused definition | DELETE /api/v1/person-events/{event} |
person-events:delete |
| Change display order | PUT /api/v1/person-events/{event}/position |
person-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 person-record permissions and of asset event setup. New Read Only keys include person-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 person’s status, for example an event that marks someone as having left. Logging such an event additionally requires people: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 person 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.