> ## 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. # Kinde setup ConfigView reads your Kinde business through the Kinde Management API, using a **machine-to-machine (M2M) application** that a Kinde admin creates in Kinde. The application gets a client ID and a client secret. ConfigView exchanges them for a short-lived token and asks only for read scopes. You will end up with **3 required secrets** (`KINDE_DOMAIN`, `KINDE_CLIENT_ID`, `KINDE_CLIENT_SECRET`) in ConfigView when setup is complete. > **Scope of this integration today.** Kinde is a customer-identity platform you build into your own product, so most of its users are your customers, not your employees. ConfigView therefore focuses on how Kinde is configured: your applications and their type, the redirect URLs they allow, which APIs each application can call and with which scopes (including who can change things through the Kinde Management API), sign-in methods and enterprise SSO connections, organizations with their MFA policy and members, roles and permissions, feature flags, webhooks, API keys and SCIM directory sync. It also collects user accounts. It never reads passwords, client secrets, connection options or API key values. ConfigView only reads. It never creates, changes or deletes anything in Kinde. *** ## What you need * A Kinde account with permission to add applications and authorize them for the Kinde Management API (an owner or admin of the Kinde business) * Nothing else to enable. Some areas are only filled in if your Kinde plan includes them: API keys, SCIM directory sync and organization MFA settings are plan-dependent. If an area is not available, that collector skips itself and its table stays empty. That does not count as a failure. *** ## Step 1: Open the Kinde page in ConfigView Open ConfigView in a second browser tab and leave it open: `https://{companyname}.configview.com/admin/integrations/kinde` *** ## Step 2: Create a machine-to-machine application 1. Sign in to Kinde and switch to the environment you want ConfigView to read (usually **Production**) 2. Open **Settings → Applications** and click **Add application** 3. Name it `ConfigView`, choose **Machine to machine (M2M)** and save 4. On the application's **Details** page copy the **Client ID** and **Client secret** 5. Switch to the ConfigView tab and paste them into `KINDE_CLIENT_ID` and `KINDE_CLIENT_SECRET` under **Credentials**, then click the save icon for each 6. Enter your Kinde domain in `KINDE_DOMAIN`, for example `acme.kinde.com` (typing just `acme` works too). It is shown under **Settings → Environment → Details**. Use the `kinde.com` address even if you run a custom domain: the token is requested for `https://.kinde.com/api` ### Authorize the application for the Kinde Management API A new M2M application can't call anything until you authorize it for an API. 1. In Kinde, open the ConfigView application and go to its **APIs** tab 2. Switch on **Kinde Management API** and open its scopes 3. Tick these **read** scopes and save. Tick all of them unless you want to leave an area out: | Scope | Used for | | - | - | | `read:applications`, `read:application_connections`, `read:applications_redirect_uris`, `read:application_logout_uris` | Applications, their sign-in methods and allowed redirect URLs | | `read:apis`, `read:api_scopes`, `read:api_application_scopes` | APIs and which applications may call them, with which scopes | | `read:connections` | Authentication connections: email, social, enterprise SSO | | `read:organizations`, `read:organization_users`, `read:organization_mfa`, `read:organization_connections` | Organizations, their members, MFA policy and enterprise connections | | `read:roles`, `read:permissions`, `read:role_permissions` | Roles, permissions and which role carries which | | `read:users`, `read:user_identities` | User accounts and the identities they sign in with | | `read:environment_feature_flags` | Feature flags | | `read:webhooks` | Webhooks | | `read:api_keys` | API keys | | `read:scim_directories` | SCIM directory sync | | `read:businesses`, `read:environments`, `read:passkey` | Business and environment settings, passkey policy | Don't tick any `create:`, `update:` or `delete:` scope. ConfigView never uses them. Give ConfigView its own M2M application rather than sharing one with a script or a backend service. Then you can see exactly what it can do and rotate its secret without breaking anything else. *** ## Step 3: Connect and verify 1. Back on `https://{companyname}.configview.com/admin/integrations/kinde`, confirm the credentials show 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 | | - | - | | **Applications** | Every application with its type, client ID, login and home URLs and sign-in page settings. Makes one request per application. Client secrets are never stored. | | **Application Sign-in Methods** | Which connections are switched on for each sign-in application. | | **Application Redirect URLs** | Allowed callback and logout URLs, flagged when plain http, a wildcard or localhost. | | **APIs** | The APIs registered in Kinde, including the Kinde Management API, and the scopes they define. | | **API Access by Application** | Which applications are authorized for which APIs, with their scopes, and whether any can create, update or delete. | | **Connections** | Email, social and enterprise SSO connections in the environment. | | **Organizations** | Organizations with their MFA policy and enterprise connections. Makes two requests per organization. | | **Organization Members** | Who belongs to which organization and their role keys there. Makes at least one request per organization. | | **Users** | User accounts with sign-in counts, last sign-in, organizations and sign-in methods. | | **Roles**, **Permissions**, **Role Permissions** | Roles and permissions, and which role carries which permission. | | **Feature Flags** | Environment feature flags and their default values. | | **Webhooks** | Webhooks, the host each posts to and the events it carries. | | **Business and Environment** | Business name, industry and time zone, whether the environment is live, domains and the passkey policy. | | **API Keys** | API keys: type, status, creator, scopes and last use. Key values are never stored. | | **SCIM Directories** | SCIM directory syncs: organization, status, last sync and last error. | 3. Click **Verify now**. The health check reads all three secrets, gets a token, reads your applications, and tries one record from each of the other areas. If a check fails: * **Token fails with 400, 401 or 403.** The client ID or secret is wrong, the secret was rotated, the application isn't a machine-to-machine application, or it isn't authorized for the Kinde Management API. Check each in turn. * **Applications fails with 403.** The application is authorized for the Management API but lacks `read:applications`. Add it on the application's **APIs** tab. * **An area shows as skipped.** Kinde answered "forbidden" or "not found" for it. Either that scope wasn't ticked, or your Kinde plan doesn't include the feature. Tick the scope if you want that area, otherwise there is nothing to fix. * **KINDE\_DOMAIN is not a kinde.com host.** Use your `.kinde.com` address, not the custom domain. *** ## 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 Kinde returned it, minus anything listed under *What isn't collected*. Each table keeps only the newest run. | Table | Source | Key Columns | | - | - | - | | `kinde_applications` | `GET /api/v1/applications` and `/applications/{id}` | app\_id, name, app\_type, client\_id, login\_uri, homepage\_uri, is\_access\_control\_enabled, sign-in page settings | | `kinde_application_connections` | `GET /api/v1/applications/{id}/connections` | app\_id, app\_name, connection\_id, connection\_name, strategy, connection\_kind | | `kinde_application_urls` | `GET /api/v1/applications/{id}/auth_redirect_urls` and `/auth_logout_urls` | app\_id, url\_kind, url, url\_host, is\_wildcard, is\_localhost, is\_insecure\_http | | `kinde_apis` | `GET /api/v1/apis` and `/apis/{id}` | api\_id, name, audience, is\_management\_api, scope\_keys, application\_count | | `kinde_api_applications` | `GET /api/v1/apis/{id}` and `/apis/{id}/applications/{id}/scopes` | api\_id, app\_id, app\_name, is\_active, scope\_keys, has\_write\_scopes | | `kinde_connections` | `GET /api/v1/connections` | connection\_id, name, display\_name, strategy, connection\_kind | | `kinde_organizations` | `GET /api/v1/organizations`, `/organizations/{code}/mfa`, `/organizations/{code}/connections` | org\_code, name, handle, is\_auto\_membership\_enabled, mfa\_enforced, mfa\_factors, connection\_names | | `kinde_organization_users` | `GET /api/v1/organizations/{code}/users` | org\_code, user\_id, email, joined\_on, last\_accessed\_on, is\_suspended, role\_keys | | `kinde_users` | `GET /api/v1/users` | user\_id, email, username, is\_suspended, total\_sign\_ins, failed\_sign\_ins, last\_signed\_in, organization\_codes, identity\_types | | `kinde_roles` | `GET /api/v1/roles` | role\_id, role\_key, name, is\_default\_role | | `kinde_permissions` | `GET /api/v1/permissions` | permission\_id, permission\_key, name | | `kinde_role_permissions` | `GET /api/v1/roles/{id}/permissions` | role\_key, permission\_key | | `kinde_feature_flags` | `GET /api/v1/environment/feature_flags` | flag\_key, flag\_type, flag\_value | | `kinde_webhooks` | `GET /api/v1/webhooks` | webhook\_id, name, endpoint\_host, endpoint\_scheme, event\_types | | `kinde_environment` | `GET /api/v1/business`, `/environment`, `/passkey` | business\_name, industry, environment\_name, is\_live, kinde\_domain, custom\_domain, passkey\_policy | | `kinde_api_keys` | `GET /api/v1/api_keys` | key\_id, name, key\_type, key\_status, created\_by, last\_verified\_on, scopes | | `kinde_directories` | `GET /api/v1/directories` | directory\_id, directory\_status, org\_code, last\_sync\_completed\_at, last\_sync\_error | *** ## Things worth knowing **Most Kinde users are your customers.** `kinde_users` is the list of people who sign in to your product. It is useful for sizing dormant accounts and seeing which sign-in methods are in use, but it is not your staff directory. People in Kinde are also not the same as the people who can sign in to the Kinde dashboard (see below). **Kinde dashboard team members can't be read.** The Management API has no endpoint that lists the people who log in to Kinde itself (the owners and admins of your Kinde business), so ConfigView can't show them. Review that list in the Kinde dashboard, in your account's team settings. **There is no audit log to collect.** The Management API doesn't list audit or sign-in events (it can only fetch a single event by ID), so ConfigView doesn't store an event history for Kinde. **Redirect URLs are the main thing to watch.** A callback URL that is plain http, contains a wildcard or points at localhost in a live environment can let someone else receive a sign-in code. ConfigView flags each one. **Management API access is the most powerful grant.** An M2M application authorized for the Kinde Management API with create, update or delete scopes can change users, organizations, roles and connections. `kinde_api_applications.has_write_scopes` marks them. **MFA is per organization.** Kinde's API exposes MFA settings per organization, not for the whole environment, and only where the organization has the advanced organizations feature. Organizations whose settings can't be read show an unknown MFA state. **Rate limit.** Kinde doesn't publish a requests-per-minute figure. It applies a rate limiter and a concurrency limiter and answers HTTP 429 with a `RateLimit-Reset` header. Each ConfigView collector paces itself at 30 requests a minute and waits as long as Kinde asks. Organizations, Organization Members and Applications make a request per record, so they take a few minutes on a business with hundreds of organizations. ## What isn't collected * Application client secrets, SCIM directory secret tokens, API key values, prefixes and suffixes, and connection options (which hold social and SSO client secrets) * Environment variable values * User phone numbers, profile pictures and billing details; the business phone number * The full webhook URL. Only its host is stored, because the path or query string can carry a secret * Billing, subscribers, properties, sessions, invitations and per-user MFA This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.