Skip to main content
The Endpoints reference documents every C1 API endpoint individually. Some real-world tasks require chaining two or more of those endpoints together — for example, looking up an object’s ID before you can act on it, or triggering a job and then checking its result. This page walks through those multi-step tasks. For single-endpoint tasks (creating an object, fetching a record by ID, and so on), go directly to the Endpoints reference — most single calls are self-explanatory there.
One step below is marked Needs verification. It’s our best reconstruction of the correct call sequence from the API reference, but hasn’t been confirmed against a live tenant. Confirm it with an engineer before publishing.

​
Add an entitlement to an access profile

An access profile is a named bundle of requestable entitlements — in the API, this is a request catalog. To add an entitlement to one, you need the catalog’s ID first.
1

Find the catalog ID for the access profile

List or search request catalogs to find the catalog_id matching the access profile’s display name.
curl
2

Add the entitlement to that catalog

curl
Set createRequests to true if you want C1 to automatically create access requests for the entitlement on behalf of everyone already enrolled in the access profile.

​
Check how many users have completed provisioning for an access profile

There’s no single “provisioning status” endpoint. Instead, find the entitlement(s) backing the access profile, then count tasks against them.
1

Find the entitlement(s) backing the access profile

curl
2

Search grant tasks for those entitlements

taskTypes takes an array of TaskType objects, not plain strings — grant tasks are selected with { "grant": {} }.
curl
Compare taskStates: ["TASK_STATE_OPEN"] (still provisioning) against taskStates: ["TASK_STATE_CLOSED"] (done) counts to get an “x of y” figure. Request a small pageSize (10 or fewer) — each task record is large.A closed task isn’t necessarily a successfully provisioned one — it can also be denied, errored, cancelled, or timed out. To count only successful grants, add "grantOutcomes": ["GRANT_OUTCOME_GRANTED"] to the request alongside taskStates: ["TASK_STATE_CLOSED"].

​
Set an entitlement’s risk level

1

Create the risk level value, if it doesn't already exist

Risk levels are a shared, tenant-wide list of values — check whether the one you want already exists before creating a duplicate.
curl
The response includes the new value’s id — save it for the next step.
2

Apply the risk level to the entitlement

Risk level is a field on the entitlement itself (riskLevelValueId), so it’s set through the same entitlement update call used for any other entitlement field. Scope the update to just that field with updateMask.
curl

​
Extend or remove a grant’s expiration date

You need the app user’s ID (the account binding a person to this app) before you can change their grant’s expiration — you can’t do it by email or entitlement ID alone.
1

Find the app user's ID

Search app users scoped to the app, matching on the user’s email. query is a fuzzy match against display name and description, so confirm the returned user’s displayName is the one you expect before using its id.
curl
2

Update or remove the expiration

To set a new expiration:
curl
To remove the expiration entirely (make the grant permanent), use the equivalent remove-grant-duration endpoint on the same binding instead.

​
Trigger a workflow automation via the API and confirm it ran

Executing an automation and checking its result are two separate calls — the execute call only returns an execution ID, not a result.
1

Execute the automation

curl
The response contains an executionId.
2

Check the execution's status

curl
Check the state field on the returned execution object. DONE is the successful terminal state; ERROR and TERMINATE are failed terminal states. PENDING, CREATING, GET_STEP, PROCESS_STEP, and COMPLETE_STEP mean it’s still running. WAITING and PAUSED_BY_CIRCUIT_BREAKER mean it’s stalled and needs attention — poll or use resolve_paused/clear on the automation to unblock it.

​
Add a service principal as an app owner

Needs verification: the reference documentation for POST /api/v1/apps/{app_id}/owners/{user_id} does not state whether user_id accepts a service principal’s ID, or whether app ownership is restricted to human users via the API. Confirm with an engineer before documenting this as supported — if it isn’t, this section should instead document the limitation.