Access Provisioning

Approving an access says the consumer should have access — it does not create the grant in the data platform. That work happens outside Entropy Data, in a component you run. Provisioning is where the outcome is recorded, so an access carries both facts: the agreement, and whether the permission behind it actually exists.

Who reports it

Provisioning is reported by a component you run — a connector or your own automation — that acts on the event feed. The pattern:

1. It subscribes to the feed and receives an AccessActivatedEvent when an access becomes active, and an AccessDeactivatedEvent when it ends.
2. On activation it creates the grant in the data platform (a role, a group, an ACL); on deactivation it removes it.
3. It reports the outcome through the endpoints below, so Entropy Data — and the consumer and provider — can see whether the grant actually exists.

Entropy Data's Databricks, Snowflake, and BigQuery connectors do exactly this out of the box; the SDK lets you build the same for any platform. Two rules keep it robust: report only for the access agreements whose output port your component owns (several connectors may share one feed), and treat every transition as idempotent — an event may be delivered more than once, and the latest report always wins.

Reporting a transition

Six endpoints, one per outcome, in two directions. The body is optional on all of them.

POST /api/access/{id}/provisioning/provisioning-started
POST /api/access/{id}/provisioning/provisioning-succeeded
POST /api/access/{id}/provisioning/provisioning-failed
POST /api/access/{id}/provisioning/deprovisioning-started
POST /api/access/{id}/provisioning/deprovisioning-succeeded
POST /api/access/{id}/provisioning/deprovisioning-failed

Each carries only what is meaningful for it: a start carries context, a success carries the reference identifying the grant, a failure carries diagnostics explaining what went wrong.

curl -X POST 'https://api.entropy-data.com/api/access/orders-analytics/provisioning/provisioning-succeeded' \
  -H 'x-api-key: <your-api-key>' \
  -H 'Content-Type: application/json' \
  -d '{
    "platform": "bigquery",
    "executor": "Orders Access Connector",
    "reference": "projects/acme-prod/roles/orders_analytics_reader",
    "customProperties": [
      { "property": "grantId", "value": "g-9f2c41ab" }
    ],
    "links": { "Run log": "https://connector.example.com/runs/8412" }
  }'

Fields you leave out keep their previous value, so a component need not resend unchanged context on every call.

Reading the state

GET /api/access/{id}/provisioning returns the current record, and the access resource itself carries the same object read-only, so one call gets you both:

{
  "id": "orders-analytics",
  "info": { "status": "approved", "active": true },
  "provisioning": {
    "status": "provisioned",
    "platform": "bigquery",
    "executor": "Orders Access Connector",
    "reference": "projects/acme-prod/roles/orders_analytics_reader",
    "provisionedAt": "2023-01-01T09:15:20.705Z",
    "note": "Granted through the platform console"
  }
}

Reconciling instead of reporting

If your component works out the truth by inspecting the platform rather than by following its own steps, PUT /api/access/{id}/provisioning replaces the whole record in one call. Unlike the transition endpoints, fields absent from the payload are cleared.

Recording it without a component

Not every access is provisioned by an automation. When the grant is created some other way — through a platform console, an existing internal process — someone with edit permission on the access can record the state directly in the web UI, from the Actions menu on the access page. It captures the same facts the API does and has no side effects: nothing is sent to the platform, and no notifications go out.

Both paths write to the same record, so the principal on the resulting event distinguishes them: api-key:... for a component, user:... for a person.

What it does not change

Provisioning is informational. info.active and the lifecycle of the access keep exactly their current meaning, so nothing about the approval workflow depends on it.

A terminal state reported by a component notifies by email: success reaches the consumer, failure reaches the providing team. Progress reports, and anything recorded in the web UI, notify nobody.

API reference

The provisioning endpoints are part of the Access API — see the OpenAPI specification for the formal definitions.