External Registries

External registries let one organization reuse another organization's registry without re-issuing identities or credentials. The registry owner grants a second organization read access, and that organization can then reference the registry's identities and credentials — for example, to enforce KYC in its own policies using a KYC provider's registry.

Access is granted per registry, is read-only for the recipient, and can be revoked at any time.

Roles and concepts

What the grantee can and cannot do

An active grant gives the grantee read access to the registry:

• Can list and view the registry, and read its credential types, identities, and credentials.
• Can reference the registry's on-chain contracts as a credential source in its own identity-validation policies.
• Cannot write to the registry — registering identities, issuing credentials, or changing configuration remains exclusive to the grantor.

Grant access to another organization

Granting access requires the grantee's Org ID. Ask the grantee to retrieve it and share it with you:

# Run by the grantee — returns their organization, including its id
curl https://ace.api.chain.link/v1/organizations/me \
  -H "Authorization: Apikey <GRANTEE_API_KEY>"

As the registry owner, create the grant:

curl -X POST https://ace.api.chain.link/v1/registries/<REGISTRY_ID>/access-grants \
  -H "Content-Type: application/json" \
  -H "Authorization: Apikey <API_KEY>" \
  -d '{
    "grantee_org_id": "org-456"
  }'

The response is the created grant:

{
  "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "grantee_org_id": "org-456",
  "grantor_org_id": "org-123",
  "status": "active",
  "granted_at": 1800000000,
  "revoked_at": null
}

View who has access

List the active and past grants for a registry you own:

curl https://ace.api.chain.link/v1/registries/<REGISTRY_ID>/access-grants \
  -H "Authorization: Apikey <API_KEY>"

Each entry includes the grantee, the status (active or revoked), and the granted_at / revoked_at timestamps, giving you an audit trail of who was granted access and when.

Use a registry shared with you

As a grantee, include include_granted=true when listing registries to see registries other organizations have shared with you, alongside your own:

curl "https://ace.api.chain.link/v1/registries?include_granted=true" \
  -H "Authorization: Apikey <API_KEY>"

Each registry in the response carries an access_type field:

• "owned" — your organization owns the registry.
• "granted" — another organization (shown in org_id) granted you access.

Once you can see a granted registry, you use it the same way you would reference any credential source:

1. Read the registry to get the on-chain identity registry and credential registry contract addresses per chain, and read its credential types to get the credential_type_hash values you need.
2. Add those addresses and credential type hashes as a credential source on your CredentialRegistryIdentityValidatorPolicy or GroupedIdentityValidatorPolicy instance.

Your policy then validates credentials issued by the other organization at transaction time. Because the grant is read-only, you rely on the grantor to keep the credentials current; if they revoke a credential, your policy sees the change immediately.

Revoke access

As the registry owner, revoke a grant by setting its status to revoked. Identify the grant by the grantee's Org ID:

curl -X PATCH https://ace.api.chain.link/v1/registries/<REGISTRY_ID>/access-grants/org-456 \
  -H "Content-Type: application/json" \
  -H "Authorization: Apikey <API_KEY>" \
  -d '{
    "status": "revoked"
  }'

Revocation takes effect immediately. The grant record is retained with a revoked_at timestamp for audit purposes rather than deleted, so the history of grants and revocations is preserved. To restore access later, create a new grant.

What happens when access is revoked

Revoking a registry access grant is a platform-level action only — it removes the registry from the grantee's view in the ACE Platform (UI and API). The grantee can no longer browse the registry, read its credentials, or reference it in new policy configurations.

Onchain, nothing changes automatically. If the grantee's policies already reference the revoked registry's onchain contracts as a credential source, those policies continue to validate credentials from that registry at transaction time. The onchain policy contracts have no awareness of platform-level access grants — they only know the registry contract addresses that were configured as credential sources.

What each party should do

Grantor — After revoking access, be aware that the grantee's existing policies may still reference your registry onchain.

Grantee — After a grant is revoked, the ACE Platform displays a warning on any policy instance that references a source from the revoked registry. You should remove the revoked registry source from your policy configuration to ensure your compliance setup reflects the current state of your access agreements. Until you remove it:

• The policy continues to validate credentials from the revoked registry onchain.
• You cannot edit the revoked source — you can only remove it.
• You cannot reference the revoked registry in new policy configurations.

Related pages

• Managing Registries — create and manage the registries you own
• Cross-Chain Identity — CCIDs, registries, and credential sources
• CredentialRegistryIdentityValidatorPolicy — reference a registry as a credential source
• Managing Policies — configure policy instances and their credential sources
• Coordinator API Reference — full API schema