Prerequisites
Before requesting an index, make sure you have:- An Auth0 FGA Enterprise subscription.
- An Auth0 FGA store (e.g.,
store_id=01KJZV40TT1ZB0A1S5V24Q0JYB). - An authorization model (e.g.,
authorization_model_id=01KJZV4R5NER0D3K4A6X9MJ2S5) deployed. - The relation to be indexed (e.g.,
document#can_view)- The relation must be supported by the FGA Permissions Index (also called the Indexable Path). See Model Limitations for unsupported model patterns for the Permissions Index.
(Optional) Test Store
If you want to test the Permissions Index without connecting to your existing FGA data, you can create a new store and use a demo authorization model:- Download the demo .fga.yaml file
- Navigate to the FGA Dashboard.
- Create a new store called
test-permissions-index. - Navigate to the Model Explorer page.
- Drag the downloaded
permissions-index-demo.fga.yamlfile into the Model Explorer to upload the model and tuples. - Select
Import modelandImport tuples. This will seed your store with the model and tuples.
Step 1: Create An Index
Developer Preview: Creating a Permissions Index is a manual process for now. Self-service index creation, via an API and the FGA Dashboard, is planned for General Availability (GA).To create an index, contact your Auth0 FGA Account Executive (AE) or Technical Account Manager (TAM) and provide:
- Store ID (
store_id) - Authorization Model ID (
authorization_model_id) - The relation to be indexed (e.g.,
document#can_view)
Step 2: Configure Client Credentials
After receiving yourindex_id, you need to configure API client credentials with the appropriate permissions to access the Permissions Index API endpoints.
Create client credentials for your application:
- In the FGA Dashboard, navigate to the Store Settings page and create or manage a client.
- Enable Read Permissions Index access to grant your client the ability to 1) list all indexes, 2) read the details of a specific index, and 3) read streamed expansion events.
Step 3: Authenticate
All Permissions Index endpoints require aBearer authentication token. Obtain one using the OAuth2 client credentials flow, as described in Call the API guide.
All access tokens are short-lived tokens. Cache the token for reuse and obtain a new one before expiry to avoid interruptions on the expansions stream.
Step 4: Call the Permissions Index API Endpoints
The Permissions Index API has three main endpoints:List Indexes
Returns a list of all the indexes in the store, including all metadata for each specific index.- Node.JS
- Go
- .NET
- Python
- Java
- CURL
Get Index
Returns metadata for a specific index, including total tuples ingested, total expansions, expansion factor, and freshness.- Node.JS
- Go
- .NET
- Python
- Java
- CURL
Read Expansions
Streams all expansion events from the beginning of the index, or from a savedfrom continuation token.
- Node.JS
- Go
- .NET
- Python
- Java
- CURL
Response format: NDJSON (newline-delimited JSON). Each line is one event. The stream is long-lived — keep the connection open to receive ongoing expansion updates.
Expansion Events
When a tuple is written or deleted in FGA, the index computes the downstream impact and delivers expansion events. Each event carries afrom continuation token that you should persist so you can resume after a disconnect.
operation is one of:
EXPANSION_OPERATION_INSERT— a permission was granted; add this row to your permissions tableEXPANSION_OPERATION_DELETE— a permission was revoked; remove the matching row
result.event.idis the unique, replay-stable identity of the event. Use it to deduplicate a replay, but not to order/sort events.result.event.as_fresh_asis the timestamp to use when measuring the index’s freshness.result.event.tuple_written_atis deprecated. Do not use it in new integrations.
Freshness Events
When no expansions are flowing, the stream emits a freshness event every 2 seconds so you can keep measuring freshness during quiet periods:Other Event Types
The server closes each stream connection after 5 minutes. When that happens, you will receive a close event like this before reconnecting with your last saved
from continuation token:
Step 5: Persist Expansions in Your Database
Use expansion events to maintain a colocated permissions table next to your application data. A minimal table schema looks like:EXPANSION_OPERATION_INSERT, upsert the row. On EXPANSION_OPERATION_DELETE, delete the matching row.
Once populated, you can filter search results with a simple JOIN — no runtime FGA API call required:
Step 6: Resume After Disconnect
The Expansions stream is at-least-once: you’ll never miss an event, but you may occasionally see the same one twice. Duplicates happen when you resume from afrom token that’s behind where you actually left off — typically after a crash that occurs before you saved the latest token.
Design your consumer to handle this: make database writes idempotent (see Designing an Idempotent Consumer), and use event.id to deduplicate before republishing events to another system.
First connection — omit from to start from the beginning of the index:
from continuation token from each event to durable storage.
Reconnecting — pass the last saved from continuation token to resume without missing events: