ICAP is the persistent, tenant-scoped system of record for physical-access data. Applications use its API to manage people, credentials, access targets, visits, and selected integration settings without depending directly on each connected Physical Access Control System (PACS).
ICAP can act as the master for the access data it owns across interconnected applications and PACSs. It maintains the canonical intended state, including the data model and lifecycle of its resources, then coordinates distribution to connected systems. AIS can provide a unified integration path to many PACSs, but it does not own that canonical business data or govern its lifecycle.
Responsibilities
|
Component |
Responsibility |
|---|---|
|
Your application |
Business workflows: onboarding, approvals, visitor handling, reporting, and user experience. |
|
ICAP |
Persistent intended access data, tenant configuration, roles, and the relationships between them. It is the system of record for the data it owns. |
|
AIS |
Access Integration Service; it translates ICAP-driven work for connected PACSs. It performs integration work but is not the business-data master. |
|
PACS |
Enforces its local access-control capabilities and runtime behavior. |
ICAP records the intended state. A connected PACS can impose capabilities or constraints, and downstream synchronization can complete later than the API call that initiated the change. A PACS can also be explicitly configured as the periodic import source for an identity or visitor category; that configuration limits ICAP's master role for that category. See PACS integration.
Core model
An identity represents a person who needs ongoing access, such as an employee or contractor. A visitor represents a temporary person; a visit represents the occasion in which the visitor attends. Neither record alone grants physical access.
Access normally requires the appropriate combination of:
-
A person or visit participant.
-
A credential, such as a card or PIN.
-
An access-unit assignment.
-
When PACS integration is used, eligible mappings and propagation configuration.
This model is deliberately separate: a card can be replaced without recreating a person, and temporary visit access does not change the visitor's reusable record.
Important boundaries
-
Every resource belongs to one tenant. A request always carries that tenant in its path.
-
An API user is an authenticated external principal, not an ICAP identity. Authorization is managed through roles and role assignments.
-
ICAP API operations manage ICAP's record. They do not promise that an external PACS has already completed its work.
-
The API supports current v1 resources and operations. Do not build workflows around capabilities not exposed in the API reference.
Next steps
Set up authentication, then follow the quickstart. For definitions of terms used throughout the documentation, see the glossary.