Skip to main content

Developer overview

The Developer section covers three ways to extend Atria: the REST API, the Atria.Tools PowerShell module, and Provisioning Manager rules. Choose the interface that owns the lifecycle you need to automate.

Choose an integration path​

RequirementStart hereWhy
Build a new external integrationREST API ReferenceCurrent JSON API with endpoint models and interactive examples.
Authenticate an application or scriptREST API authenticationCreate, protect, use, and revoke bearer API tokens.
Automate supported REST operations from PowerShellPowerShell SDKCmdlets for API sessions, request tracking, and WorkSpace operations.
Maintain an existing XML integrationCortex APILegacy compatibility API for customers, users, services, and provisioning.
Run custom logic inside an Atria provisioning requestProvisioning ManagerLifecycle rules with access to the active request and service properties.

For a new integration, prefer REST. Use Cortex only when maintaining an existing integration or when the required operation has not yet been exposed through REST.

Understand the boundaries​

  • REST API calls originate outside the provisioning process. Many write operations return a request that must be monitored until it completes.
  • PowerShell SDK cmdlets wrap selected REST endpoints. The module does not expose every REST operation; use the interactive reference when no cmdlet exists.
  • Provisioning Manager runs as part of Atria's internal request lifecycle. Rule values exist only for that request unless an action explicitly persists them.
  • Cortex API uses a separate XML contract and HTTP Basic authentication. Its request and error-handling model is not interchangeable with REST.
  1. Confirm that REST or an existing PowerShell cmdlet does not already provide the operation.
  2. Use a dedicated, least-privileged Atria identity or API token.
  3. Develop against a non-production customer and avoid real user data in test payloads.
  4. Treat write operations and provisioning rules as asynchronous unless the relevant reference says otherwise.
  5. Record request IDs and inspect request logs when downstream provisioning fails.
  6. Make repeated operations safe: retries and update requests must not create duplicate external objects.
  7. Test deprovisioning separately. Removal paths often have fewer properties and greater consequences than provision paths.
Protect credentials and request data

API tokens, Basic authentication credentials, temporary passwords, provisioning messages, and connection objects must not be committed to source control or written to ordinary logs.

Reference map​