Benefits of the IAM API
Consistent Identity Data Models
Consistent Identity Data Models
Users, roles, groups, organizations, permissions, and credentials return the same schema regardless of the underlying provider.
users in Google Workspace, Okta, and 1Password all return the same fields.Fine-Grained Permissions and Scopes
Fine-Grained Permissions and Scopes
Permissions carry an action type and resource scopes, and roles can be scoped to a specific organizational context, giving you a normalized view of who can do what, and where.
Resource-Level Access Visibility
Resource-Level Access Visibility
List every user with access to a specific resource — a Drive file, a Slack channel, a group — including their resource-scoped roles.
Nested Groups and Organizations
Nested Groups and Organizations
Groups nest via parent and child links, belong to organizations, and expand to their member users, giving you the provider’s directory structure in one shape.
Credential Introspection
Credential Introspection
See what the authenticated connection itself can do:
GET /unified/iam/me returns its auth type, granted scopes, and effective permissions.StackOne SDKs & OpenAPI Specification
Use our official SDKs for faster integration. Build with language-native libraries. Full list here.
OpenAPI Specification
Popular SDKs
Entity Model
The IAM API is built around six core entities.IamCredentials is not included in the diagram above. It is a snapshot of the current connection’s auth state, not a stored identity object. It carries a user reference when the credential corresponds to a known principal (such as an OAuth user or named service account).
Permission and scope model
IamPermission has a type (the action) and a scopes array. Each scope entry has a resource_type (e.g. file, channel, user) and an optional resource_id. When resource_id is absent, the permission applies to all resources of that type.
Roles carry the same scoping via IamRoleScope on the role itself, allowing a role to be valid only within a specific organizational context.
Endpoints
Permission types
IamPermission.type is one of the values below. The OAS admits the full set; providers expose only the permission types that map to their model.
User filters
GET /unified/iam/users accepts the following keys on the filter query object. Filter support varies per connector; passing a filter key the connector does not support returns a 400.
Resource types
GET /unified/iam/resource_types returns the resource type identifiers a connected provider supports for resource-scoped queries. The response shape is { data: string[] }; values are connector-defined, not a fixed enum.
Use these values as the
resource_type query parameter on GET /unified/iam/resource_users.
The type field on an embedded IamResource is declared as oneOf: [string, IamResourceTypeEnum] in the OAS. Current connectors emit a plain string from the connector-defined set returned by this endpoint (e.g. "file", "channel", "group"). Legacy V2 connectors emit the { value, source_value } envelope where value is from the fixed IamResourceTypeEnum set. Parse both shapes when consuming the field.
Listing users by resource
GET /unified/iam/resource_users returns users with access to a specific resource, including their resource-scoped roles. Same response shape as IamUser.
Required query parameters:
resource_type: one of the values returned byGET /unified/iam/resource_typesfor the connected provider.resource_id: the raw provider remote_id of the resource. Not a StackOne-encoded id from a list endpoint. Pass the provider’s native id (e.g. a Drive file id, Slack channel id, group remote_id).
fields, and expand apply as on the other list endpoints.