SailPoint IIQ REST API Guide 2026: Workflows to Calls

Quick Answer: the SailPoint IIQ REST API lets external systems drive identity operations over HTTPS: identity and access data queries, identity requests, workflow launches and certification operations, protected by the same authorisation model as the console (Basic auth or OAuth-style tokens depending on version and configuration). Two integration patterns exist — calling IIQ’s built-in REST endpoints, and exposing your own endpoint through the API service configuration that hands work to a rule or workflow.

What the Built-In REST Endpoints Cover

Pattern 1: Calling IIQ From Outside

A typical query against a test instance — check a user’s accounts from an automation script:

curl -sk -u "svc-integration:REDACTED" \
  -H "Accept: application/json" \
  "https://iiq.internal.example.com/identityiq/rest/identities/EMP10042"

# Response (abridged):
# {
#   "identity": {
#     "name": "EMP10042",
#     "displayName": "Priya Nair",
#     "attributes": { "department": "Finance", "empStatus": "ACTIVE" },
#     "accounts": [ ... ]
#   }
# }

Field rules that keep integrations out of trouble: credentials belong in a vault, never in scripts; use a dedicated service account with the narrowest authorisation that works; and log every outbound call with a correlation ID you can match in IIQ logs later.

Pattern 2: Exposing Your Own Endpoint

When a portal needs a custom operation — “check this user’s outstanding access requests and risk flags in one call” — you register an API service in IIQ that routes to a BeanShell rule, which returns JSON. The rule does the work; the framework handles HTTP. Skeleton of the rule side:

import sailpoint.object.Identity;
import java.util.HashMap;
import net.sf.json.JSONObject;

Map result = new HashMap();
Identity id = context.getObjectByName(Identity.class, identityName);

if (id == null) {
    result.put("error", "identity not found");
    return JSONObject.fromObject(result).toString();
}

result.put("name", id.getName());
result.put("status", id.getStringAttribute("empStatus"));
result.put("openRequests", countOpenRequests(id));
return JSONObject.fromObject(result).toString();

Design rules for custom endpoints: validate every input (query parameters are user input — treat them like it), return structured errors rather than stack traces, and load-test before launch: a portal polling every 30 seconds per user will find every inefficiency in your rule.

Security Review: What Will Be Asked

Every IIQ REST integration in a regulated client goes through the same review — arrive prepared: service account authorisation scope, transport security, payload sensitivity (identity data is personal data), rate limits and retry behaviour, audit logging of every mutation, and failure mode when IIQ is down (the portal must degrade, not fabricate). Teams that prepare these answers up front ship integrations weeks faster.

One more field lesson: an integration once polled the identities endpoint for 12,000 users nightly “for a dashboard”. It worked, but it multiplied refresh load and slowed the warehouse. The fix was unglamorous — a nightly extract to the dashboard’s own store instead of live polling. REST is not free; design call volume like it costs something, because it does — the invoice arrives as refresh-time degradation nobody connects to the dashboard.

Versioning and Upgrade Discipline

IIQ integrations live across upgrades, so treat every endpoint touchpoint as version-sensitive inventory, owned by someone who will still be there at the next upgrade. Keep an integration register: endpoint, method, service account, payload contract, and the last-tested IIQ version. When an upgrade programme starts, that register becomes the regression scope — and teams without one re-discover their integrations the expensive way, from production behaviour. Built-in endpoints evolve with the platform: response fields can gain attributes (harmless) and behaviours can tighten (not harmless), so contract-test the built-ins you depend on in a sandbox before each upgrade, not after. Custom endpoints are entirely yours: their rules run on the upgraded platform, so the same regression pack applies with extra attention to deprecations in rule APIs. Budget the honest numbers — for a portal with five integrations, two to three integration-person-weeks of upgrade testing is normal, and quoting that early is what makes an upgrade plan credible, because it is the number to defend when the plan gets compressed.

Integration Antipatterns

Five patterns account for most REST integration pain in the field. Polling everything live — dashboards querying identities every few minutes multiply load for data that changes daily; batch extracts to a consuming store fix it. Over-scoped service accounts — one admin account “because it was easier” turns every security review into a negotiation; least-privilege per integration, always. No retry discipline — network blips become duplicate requests, and duplicate access requests are exactly as fun as they sound; idempotency keys and bounded retries are the baseline. Blocking calls inside workflows — a slow external API becomes a slow workflow, then a slow platform; queue and decouple. And logging secrets — integration logs that capture tokens or personal data convert a debug aid into an audit finding; log identifiers, not payloads. Every one of these is cheaper to fix at design review than at incident review, which is the entire argument for the security checklist above — design review is where integrations are actually won.

Training Resources

The SailPoint IdentityIQ Certification Training includes a REST integration lab — build a custom endpoint, call it, secure it, and load-test it. Related integration depth lives in the ServiceNow and Workday integration guide, the wider platform map in the IIQ architecture guide, and the full skill path in the IIQ roadmap. For careers spanning multiple identity platforms, the IAM training track places IIQ’s API patterns in the wider integration landscape.

FAQ

Does SailPoint IIQ have a REST API?

Yes — IIQ ships REST endpoints for identities, access requests, workflows, certifications and system status, and supports registering custom API services that expose rule-backed endpoints for bespoke integrations — knowing which surface fits which need is half the integration interview, and the half most candidates skip.

How do I authenticate to the IIQ REST API?

Standard patterns: HTTP Basic authentication with an authorised IIQ service account, and token-based options depending on version and configuration. Use a dedicated least-privilege account with vaulted credentials — never a personal admin login in a script — personal-account integrations are how offboarding becomes an outage.

Can the IIQ REST API submit access requests?

Yes — external systems such as ITSM tools can raise and track identity requests through the API; the request then runs the same approval, policy and provisioning lifecycle as a console-submitted one — which is precisely the governance argument when integration owners ask to skip it.

How do I create a custom REST endpoint in IIQ?

Register an API service that maps a URL to a BeanShell rule; the rule builds and returns the JSON payload. Validate inputs, return structured errors, and load-test — custom endpoints are the ones that fail under real traffic, so load-test with production-shaped payloads and concurrency.

Is the IIQ REST API the same as Identity Security Cloud’s API?

No. IIQ (on-premises) and Identity Security Cloud (SaaS) have different API surfaces and authorisation models. Concepts transfer; endpoint details and auth flows do not — check the documentation for the exact product version you integrate with. Interviewers use this question to separate experience levels.

Written by SkilBrill Training Institute

October 25, 2026 · 7 min read