Access orders and API integration
Purpose and prerequisites
An access order grants people or teams time-limited permissions without requiring a reservation. People, units and matching controls must exist. You need the relevant management permissions in the selected workspace.
Plan in the app
Open Access orders. Create an order with a clear name, people or teams, units and validity windows. Choose the required actions and review before saving. Check status and assignments afterwards. An order is neither workspace membership nor an occupancy block.
Receive orders from a management system
An authorised integration can maintain people, service teams and access orders through the REST API. Referenced people and units must already be linked by their external identifiers. The integration requires the enabled allocation and automation capabilities. Credentials belong only in the integrated system, never in documentation or an order name.
Integration contract
Under /api/integrations/v1/tenants/{externalTenantId}/access-orders/{externalOrderId}, integrations read with GET and create or replace with PUT. PUT on /lifecycle explicitly cancels. Changes require the current ETag in If-Match; a stale revision returns 412. PUT replaces the complete order, so removed entries cease to apply. Omitting an entire order from a synchronisation does not cancel it. Edit externally managed orders in their source system. The API does not sign users in or create technical device mappings.
Related: Reservations, people, team management, devices and controls.