Idira API Integration Architecture: Service URLs, Bearer Tokens, and Least Privilege
Map Idira's service-specific APIs, documented base URLs, bearer authentication, dedicated service-user roles, and safe client practices without guessing endpoints.
Idira’s public API portal presents identity, access, privileged-access, cloud-discovery, and secrets APIs as separate service references. That matters operationally: a valid identity token is not a universal permission grant, and one service’s hostname, role, request path, or TLS requirement must not be copied to another API without evidence. This guide maps the integration boundary using the published Idira API references available on October 5, 2026. It is a scoped API-client guide, not an exhaustive catalog of every licensed Idira product or endpoint.
Palo Alto Networks introduced Idira in May 2026 as an identity-security platform built on the CyberArk foundation. The current API portal uses Idira naming while the documented service URLs below still use cyberark.cloud hostnames. Follow the service’s current API reference exactly; do not derive a replacement hostname from the new brand name. The latter is an operational inference from the published API endpoints, not a claim that all CyberArk hostnames have a permanent migration policy.
Read the service catalog as separate API contracts
The API portal lists references such as Access Requests, Cloud Discovery Service, Identity APIs, Secrets Hub, Secrets Manager SaaS, Secure Cloud Access, Secure Infrastructure Access, and Workspace Delegation. These names describe the references available in the catalog; they do not prove that every tenant is entitled to every capability or that all APIs share the same version, authentication flow, role model, or service-level agreement.
The available references demonstrate distinct service boundaries:
| API reference | Documented base URL or boundary | Authentication or authorization detail in that reference |
|---|---|---|
| Access Requests | https://<subdomain>.uar.cyberark.cloud/api |
Identity-issued bearer token; dedicated service user with applicant and/or approver role as required |
| Secure Infrastructure Access settings | https://<subdomain>.dpa.cyberark.cloud/api |
Bearer JWT from Identity authentication; SiaAdmin role required for this settings API |
| Access API | https://<subdomain>-userportal.cyberark.cloud |
Bearer JWT; its API reference requires TLS 1.3 for clients |
These examples are deliberately not collapsed into a single api.idira.example endpoint. Keep the tenant subdomain, product host, /api suffix where documented, and operation path tied to the exact service reference. Different service APIs may have different base paths and compatibility behavior.
Separate authentication from authorization
The Access Requests getting-started page directs integrators to the Idira Identity API-token instructions, says that Identity authentication returns a token, and requires that token in the Authorization: Bearer header for API requests. It also recommends a dedicated service user rather than a personal user, with the applicant or approver role assigned according to the operation. The Secure Infrastructure Access settings reference separately states that the API requires SiaAdmin. A bearer token being syntactically valid therefore does not imply that the caller has the needed service role.
Use a dedicated non-human account for each integration where the service supports it. Give it only the role needed for its documented actions, store the credential in an approved secret manager, restrict who can read it, and define an owner and revocation procedure. Do not place a token in source control, a pipeline echo statement, a URL, or a ticket. Avoid granting an integration an administrator role merely because it resolves an authorization error. For high-impact operations such as access approval or security configuration, separate request creation and approval identities where the product’s role model permits it.
The API portal also lists rate-limit documentation. Read the current service-specific policy before choosing polling frequency, concurrency, or retry behavior. Do not copy a numeric limit from a different API or assume that retrying a timed-out write is safe. For a request whose outcome is unknown, first reconcile the resulting object or operation state using the documented API before submitting a second create, approve, or revoke operation.
Build a client around the published operation reference
The base URL is only half of a request. Copy the method, resource path, required headers, body schema, pagination model, and error responses from the exact API’s current reference. The following Python template intentionally leaves the operation path external so an integrator does not accidentally invent an endpoint:
import os
import requests
base_url = "https://<tenant-subdomain>.uar.cyberark.cloud/api"
operation_path = os.environ["IDIRA_ACCESS_REQUESTS_PATH"].lstrip("/")
token = os.environ["IDIRA_API_TOKEN"]
response = requests.get(
f"{base_url}/{operation_path}",
headers={
"Authorization": f"Bearer {token}",
"Accept": "application/json",
},
timeout=30,
)
response.raise_for_status()
payload = response.json()Inject IDIRA_API_TOKEN from the pipeline’s secret store at runtime and do not enable shell tracing around a job that handles it. Replace the tenant placeholder and path only with values from your tenant and the Access Requests API reference. This example is a read-only request template, not a claim that every API supports the same method or path. For mutations, use the operation’s documented request body and method, and do not assume an undocumented idempotency key or retry guarantee.
Keep certificate verification enabled. For the Access API specifically, its reference says clients must use TLS 1.3; do not generalize that statement into a universal TLS requirement for every service endpoint unless that service’s docs say so. Likewise, bearer authentication in one API reference is not evidence that every Idira integration accepts the same token audience or tenant context.
Operate API identity as a production dependency
Before enabling automation, test authentication using a low-impact, read-only operation documented for the target service. Confirm the tenant and service host, principal identity, assigned role, response schema, and audit record. Then test the intended permission boundary: the integration should be able to perform its approved action and receive a denial for a sensitive action outside its role. Record a redacted request ID and status, not the token or a response body that may contain secrets.
Handle failures according to the service contract. Distinguish authentication failure, authorization denial, validation error, rate limiting, and transient service failure. Bound retries, add jitter for documented retryable responses, and avoid retrying non-idempotent operations after an ambiguous timeout without first checking their state. Alert on repeated token failures, privilege changes, unexpected response schemas, and authentication from unapproved workloads. Preserve enough request metadata for audit while redacting authorization headers and sensitive payload fields.
Treat token creation, role assignment, API host configuration, and secret delivery as separate control points. A deployment change that switches a token to another product host can silently move an integration across service boundaries. Review base-URL changes and role changes in code review, keep test and production tenant configuration distinct, and periodically verify that the service user remains active and narrowly scoped.
Related:
- HashiCorp Vault Database Secrets: Dynamic Users, Static-Role Rotation, and Lease Operations
- Azure Pipelines Workload Identity Federation: Secure Service Connections and Migrate the Issuer
Sources: