Import an application's access
Imports the complete access list for one application. Users, resources and permissions are matched by email and title. Any access not present in the body is removed. An email matching no known user creates one. If any row cannot be resolved, nothing is written and every rejected row is listed in the response. Importing into an application with an active access-syncing integration is permitted; the next scheduled sync will overwrite what the import wrote. Because this call replaces all of an application’s access, send a unique Idempotency-Key header so an accidentally repeated request is rejected rather than re-applied.
This is a full replace, not a merge
Import sends the complete access list for one application. Users, resources and permissions are matched by email and title, and any access not present in the body is removed — this is a replace, not an incremental update. An email matching no known user creates one, so send the full intended state every time, not just the rows you want to add or change. The write is all-or-nothing: if any row cannot be resolved, nothing is written and every rejected row is listed in the response. Importing into an application with an active access-syncing integration is allowed, but the next scheduled sync will overwrite whatever the import wrote.Long-running request — combine with idempotency
Replacing every user, resource and permission for an application is a large operation. For a big application the request can be long-running, and the underlying TCP connection may be held open long enough that a proxy, load balancer or client timeout drops it before AccessOwl responds — even though the import is still being applied on the server. A plain retry after such a timeout would re-run the whole replace. To retry safely, send a uniqueIdempotency-Key header and reuse the same key on every retry of that import —
a repeat then returns 409 Conflict instead of re-applying the replace.
Authorizations
Headers
Body
Complete access list

