Skip to main content
Sync tells C1 what access exists. Provisioning lets C1 change access. Provisioning is optional - many connectors sync only. But this is where your connector goes from “showing access” to “managing access.” It’s the difference between a dashboard and a control plane.

The provisioning interfaces

The SDK provides several interfaces you can implement:

Grant and revoke

V2 vs V1: The V2 interface returns a list of grants from Grant(). This handles cases where one logical grant creates multiple underlying grants. New connectors should use V2.

CreateAccount

DeleteResource

Implementing grant and revoke

Know your entities. In Grant/Revoke, data comes from two sources:
  • Principal = who is getting access (provides context like workspace/org/tenant)
  • Entitlement = what access they’re getting (provides the role/permission ID)
When extracting IDs, verify each comes from the correct entity.

When to implement

If your target system supports adding/removing users from groups, roles, or permissions programmatically, implement Grant and Revoke. This covers most access control systems.

Grant implementation

Revoke implementation

Idempotency

Make operations idempotent. When a grant “already exists” or a revoke target is “not found”, return success - the desired state is achieved.
Provisioning operations should be idempotent - calling Grant twice for the same user+entitlement should succeed both times. This makes retries safe and simplifies the whole system. Grant idempotency:
  • If user already has the entitlement, return success (not an error)
  • HTTP 409 Conflict typically means “already exists”
Revoke idempotency:
  • If user doesn’t have the entitlement, return success
  • HTTP 404 Not Found typically means “already revoked”

Using annotations

The SDK provides annotations to signal idempotent states:

Real examples

Active Directory group membership (LDAP)

Google Workspace role revocation (REST API)

Edge cases

Validate principal type

Always check that the principal is the expected type:

Store grant IDs

If the target system returns an assignment ID, store it in the grant:
This allows Revoke to use grant.Id directly instead of searching.

Multiple entitlement types

If a resource offers multiple entitlement types, dispatch appropriately:

CreateAccount (JIT provisioning)

CreateAccount enables just-in-time (JIT) user provisioning - accounts are created in target systems only when access is needed.

When to implement

  • User accounts can be created via API
  • You want to enable JIT provisioning workflows
  • The target system supports account creation without interactive signup

Basic pattern

DeleteResource

DeleteResource removes resources (users, groups, etc.) from the target system.

When to implement

  • You want to deprovision users when they leave
  • Resources can be deleted via API
  • You want cleanup automation

Basic pattern

Declaring capabilities

Capabilities are auto-generated, not manually written. When you implement provisioning interfaces, the connector binary automatically advertises those capabilities.
This produces:

Interface-to-capability mapping

Quick reference

Interfaces

Method signatures

Idempotency checklist