> ## Documentation Index > Fetch the complete documentation index at: https://support.configview.com/llms.txt > Use this file to discover all available pages before exploring further. # WorkOS setup ConfigView reads your WorkOS environment through the WorkOS API, using an **API key** that a WorkOS admin copies from the WorkOS dashboard. ConfigView only reads. You will end up with **1 required secret** (`WORKOS_API_KEY`) in ConfigView when setup is complete. > **What this data is.** WorkOS is the sign-in layer a software company builds into its own product. The organizations, SSO connections and directories in WorkOS belong to that company's **customers**, and the AuthKit users are the people who use the product. ConfigView reads that customer-facing access estate: organizations and their domains, SSO connections (type and state), Directory Sync directories and the users and groups synced from them, AuthKit users with their organization memberships and roles, invitations, the roles defined in the environment, the audit log actions you defined, and WorkOS's event stream. It never reads sessions, passwords, MFA factors, directory raw attributes, user metadata, Vault data, or the audit log events themselves. ConfigView never creates, changes or deletes anything in WorkOS. *** ## What you need * A WorkOS dashboard account with access to **API Keys** for the environment you want to read * Know which environment that is. A WorkOS API key reads **one environment** (production or staging). To read both, add a second WorkOS connection in ConfigView with the other environment's key **Your own WorkOS dashboard team members are not collected.** WorkOS does not offer an API for listing the people who can sign in to the WorkOS dashboard (its Platform API returns only a team's name and production state). Review dashboard members under **Settings** in WorkOS. *** ## Step 1: Open the WorkOS page in ConfigView Open ConfigView in a second browser tab and leave it open: `https://{companyname}.configview.com/admin/integrations/workos` WorkOS shows a production API key only once, when it is created, so paste it straight into ConfigView instead of keeping it in a notes file. *** ## Step 2: Copy an API key 1. Sign in to the WorkOS dashboard and switch to the environment you want to read 2. Open **API Keys** 3. Create a key named `ConfigView` (or copy the environment's existing key). It starts with `sk_` 4. Switch to the ConfigView tab and paste it into `WORKOS_API_KEY` under **Credentials**, then click the save icon Use a key meant only for ConfigView so you can rotate or revoke it without touching your product. *** ## Step 3: Connect and verify 1. Back on `https://{companyname}.configview.com/admin/integrations/workos`, confirm the credential shows as saved 2. Click **Connect**. ConfigView creates its tables and schedules every collector at your default run time. Stop any you don't want under **Collectors**: | Script | Notes | | - | - | | **Organizations** | The organizations (your customers' tenants), with their domains and how many are verified. | | **Organization Domains** | Every domain an organization has claimed, and whether it is verified or still pending. | | **SSO Connections** | Every SAML or OIDC connection: organization, identity provider type, name and state. | | **Directories** | Every Directory Sync directory: organization, provider type and state. | | **Directory Users** | People synced from those directories: email, name, job title, state and role. Reads one directory at a time. | | **Directory Groups** | Groups synced from those directories. | | **AuthKit Users** | The end users of your product: email, verification, last sign-in. | | **Organization Memberships** | Which user belongs to which organization, with their roles and status. Makes one request per organization. | | **Invitations** | AuthKit invitations and whether each is pending, accepted, expired or revoked. | | **Roles** | The roles defined in this environment and their permissions. | | **Audit Log Actions** | The audit log actions you defined, with their schemas. | | **Events** | WorkOS's event stream. ConfigView keeps every event it collects. | 3. Click **Verify now**. The health check reads the key, lists one organization, and tries one record from each of the other areas. If a check fails: * **The API call fails with 401.** The key is wrong, was revoked, or belongs to another environment. Copy the key again. * **The API call fails with 403.** The key lacks permission to read organizations. * **An area shows as skipped.** WorkOS answered "forbidden" or "not found" for it, which usually means the feature (Directory Sync, AuthKit, Audit Logs) is not enabled in this environment. Nothing to fix. *** ## Data Tables Once the scripts run, these tables are created in your database. Each table has a `run_at` column and a `raw_json` column, which holds the record as WorkOS returned it, minus anything listed under *What isn't collected*. The snapshot tables keep only the newest run. `workos_events` keeps every event ever collected. | Table | Source | Key Columns | | - | - | - | | `workos_organizations` | `GET /organizations` | organization\_id, name, external\_id, domains, domain\_count, verified\_domain\_count, created\_at | | `workos_organization_domains` | `GET /organizations` (each organization's domains) | domain\_id, organization\_id, domain, domain\_state, verification\_strategy | | `workos_connections` | `GET /connections` | connection\_id, organization\_id, name, connection\_type, connection\_state, domains | | `workos_directories` | `GET /directories` | directory\_id, organization\_id, name, directory\_type, directory\_state, domain, metadata\_json | | `workos_directory_users` | `GET /directory_users` (once per directory) | directory\_user\_id, directory\_id, organization\_id, email, first\_name, last\_name, job\_title, user\_state, role\_slug | | `workos_directory_groups` | `GET /directory_groups` (once per directory) | group\_id, directory\_id, organization\_id, name | | `workos_users` | `GET /user_management/users` | user\_id, email, first\_name, last\_name, email\_verified, external\_id, last\_sign\_in\_at | | `workos_organization_memberships` | `GET /user_management/organization_memberships` (once per organization) | membership\_id, user\_id, user\_email, organization\_id, membership\_status, role\_slug, role\_slugs, directory\_managed | | `workos_invitations` | `GET /user_management/invitations` | invitation\_id, email, invitation\_state, organization\_id, inviter\_user\_id, expires\_at | | `workos_roles` | `GET /authorization/roles` | slug, name, role\_type, permissions | | `workos_audit_log_actions` | `GET /audit_logs/actions` | action\_name, schema\_version, target\_types, metadata\_fields | | `workos_events` | `GET /events` | event\_id, event\_at, event\_type, organization\_id, user\_id, connection\_id, directory\_id, subject\_id | *** ## Things worth knowing **One key, one environment.** Production and staging are separate in WorkOS. ConfigView shows whichever environment the key belongs to. **Organizations are your customers.** Their people are in `workos_directory_users` (synced from the customer's directory) and `workos_users` (people who signed up through AuthKit). Join `workos_organization_memberships` to `workos_organizations` on `organization_id` to see who belongs to which customer, and to `workos_users` on `user_id`. **States are WorkOS's.** Connection, directory, domain and invitation states are stored as WorkOS reports them (for example `active`, `inactive`, `draft`, `invalid_credentials`, `unlinked`, `pending`, `verified`). **The event log is a 30-day window.** WorkOS serves roughly the last 30 days of events. The first run collects those and every later run picks up from the newest event stored, so ConfigView becomes the longer record. Sign-in successes and directory user create/update/delete events are not requested because of their volume. Directory user changes are visible by comparing the `workos_directory_users` snapshot over time. **Group membership is not collected.** Reading who is in each directory group needs one request per group. Directory users and directory groups are collected separately. **Rate limits.** WorkOS allows 6,000 requests per 60 seconds per API key, 1,000 AuthKit reads per 10 seconds per environment, and 4 requests per second per directory for directory users. ConfigView paces itself well below all three: 300 requests a minute per script, and 150 a minute for directory reads, one directory at a time. A large environment can take several minutes to read because Organization Memberships makes one request per organization. ## What isn't collected * Your WorkOS dashboard team members (WorkOS has no API for them) * Directory users' raw and custom attributes, AuthKit user metadata and profile pictures * Invitation tokens and accept links, and domain verification tokens * Sessions, passwords, MFA factors, Vault data and audit log event contents * Organization-specific custom roles and the API keys your customers created * The API key itself never goes into the database This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.