> ## 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. # Endpoints that need attention > An integration that is collecting normally can still have individual endpoints it cannot read. Here is what each one means and how to fix it. The Integrations page marks an integration **Connected** when it is authenticating and collecting. It can still be unable to read *particular* endpoints, and those are listed under **Endpoints need attention** at the top of the page. Each line names the integration, the endpoint, and what the vendor said. This is deliberately not a failure. An integration where 25 of 26 checks pass is working; one endpoint is not, and that is usually a permission nobody has granted yet or a vendor module you do not license. If the integration itself is down — a credential that is missing, expired, or rejected — it stays red, and [Troubleshooting failed scripts](/error) is the page for that. ## How to read the error The status code tells you which of three things is true, and they have different fixes: | Code | Meaning | What to do | | ------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | **401** | The credential was rejected outright | The whole integration is down, not one endpoint. See [Troubleshooting failed scripts](/error). | | **403** | The credential is valid; it lacks permission for *this* endpoint | Grant the permission below, then click **Verify now** | | **404** | The endpoint does not exist for this tenant | Usually a module you do not license, or a feature you have not configured. Turn the matching collectors off. | The 403/404 distinction matters most. A **403** is yours to fix. A **404** across an entire API family means the vendor is not serving it to your account at all, and no permission change will help. After making any grant below, open the integration and click **Verify now** rather than waiting for the nightly check at 03:10 UTC. ## Microsoft 365 Graph permissions are granted per application, and each one needs **admin consent** — adding the permission is not enough on its own. 1. In the [Entra admin center](https://entra.microsoft.com), go to **Applications → App registrations** and open the registration ConfigView uses. 2. **API permissions → Add a permission → Microsoft Graph → Application permissions**. 3. Add the permission named in the error, then click **Grant admin consent for \**. 4. Wait a minute or two — consent takes a moment to propagate — then **Verify now**. Permissions that commonly need consent, and what they unlock: | Permission | Powers | | ----------------------------------------- | -------------------------------------------- | | `AuditLog.Read.All` | Sign-in logs, directory audit | | `DeviceManagementConfiguration.Read.All` | Intune configuration and compliance policies | | `DeviceManagementManagedDevices.Read.All` | Intune managed devices | | `IdentityRiskyUser.Read.All` | Risky users (needs Entra ID P2) | | `IdentityRiskEvent.Read.All` | Risk detections (needs Entra ID P2) | `IdentityRiskyUser.Read.All` and `IdentityRiskEvent.Read.All` are licensed features. On a tenant without **Entra ID P2** they keep returning 403 no matter how the consent is granted — that is expected, and the right response is to leave those collectors off. If you run more than one tenant, each has its own registration and its own consent. Granting in one does nothing for the others. ## Azure Azure splits its permissions in two, and each half fails differently. **Control plane (ARM) — role assignments.** Add the role at the scope named in the error, under **Access control (IAM) → Add role assignment**, assigned to the service principal ConfigView uses: | Endpoint | Role to grant | Scope | | ------------------------------ | --------------------------- | ---------------------------------------------- | | Subscriptions, resources, cost | **Reader** | Subscription, or the management group above it | | Management groups | **Management Group Reader** | Tenant root management group | | Reservation orders | **Reservation Reader** | Tenant | If the check says the service principal can see **0 subscriptions**, the integration is down rather than degraded — nothing else can be read without a subscription in view. Assign **Reader** at the subscription or management group scope and verify again. **Data plane (Key Vault) — a separate grant.** Listing vaults is a control-plane call and works with Reader; reading what is *inside* a vault is not. For an RBAC vault, grant the service principal both **Key Vault Reader** and **Key Vault Secrets User** on the vault. For a vault still on the legacy model, add an access policy with **get** and **list** on secrets, keys, and certificates. This is why you can see the vault list and still get 403 on secrets — they are two different permission systems, and the vault decides which one applies. ## Google Workspace Scopes for a service account are granted through **domain-wide delegation**, and the service account's own IAM roles have nothing to do with it. 1. In the [Admin console](https://admin.google.com), go to **Security → Access and data control → API controls → Manage Domain Wide Delegation**. 2. Find the client ID for the ConfigView service account, or add it if it is not listed. 3. **Edit** and add the scope named in the error — the full URL, exactly as shown, e.g. `https://www.googleapis.com/auth/admin.directory.group.member.readonly`. 4. Save, then **Verify now**. The scope list is replaced, not merged, when you save. Paste the existing scopes back alongside the new one, or the collectors that were working will stop. Also confirm the impersonated admin account still exists and is a super admin — delegation is granted to the service account, but every call is made *as* that user. ## CrowdStrike Falcon API scopes are set on the API client, under **Support and resources → API clients and keys**. Edit the client, tick **Read** for the scope named in the error, and save. The client secret is not reissued, so nothing needs re-entering in ConfigView. A **404** on a CrowdStrike endpoint is different, and no scope will fix it. If the whole `/incidents/` family returns 404 while `/alerts/` returns 200, your CID does not include the Incidents module — that is a licensing question for your CrowdStrike account team. Until it is added, turn off the collectors that read it: * `crowdstrike_get_incidents.py` Leaving it scheduled is harmless — it exits cleanly and writes nothing — but it will keep appearing on this list. ## Looker Looker returns **404** for an authentication backend that is not configured, so an instance that uses SAML answers 404 for `/ldap_config` and `/oidc_config`. There is nothing to fix; the endpoints do not exist for you. Check which backend you actually use under **Admin → Authentication**, and turn off the collectors for the other two: | You use | Turn off | | ------- | -------------------------------------------------------- | | SAML | `looker_get_ldap_config.py`, `looker_get_oidc_config.py` | | OIDC | `looker_get_ldap_config.py`, `looker_get_saml_config.py` | | LDAP | `looker_get_oidc_config.py`, `looker_get_saml_config.py` | A **403** from Looker is a different matter: several endpoints — scheduled plans, alerts, and the SSO configs — are admin-only, so the API3 credential needs the **Admin** role. See [Looker setup](/looker). ## AWS Add the action named in the error to the ConfigView IAM policy. One is worth calling out because it is optional: * `organizations:ListAccounts` — only needed if you want cost broken down by member account. Without it, ConfigView still collects everything else, and the check reports a warning rather than a failure. Grant it on the **payer** account; a member account cannot list the organization. The full policy is on the [AWS setup page](/aws). ## Google Cloud Roles are granted per project, and the collectors read across every project the service account can see. A 403 on one API usually means either the role is missing on that project or the API itself is not enabled there. Grant **Viewer** at the folder or organization level rather than project by project, and enable the API named in the error under **APIs & Services**. See [Google Cloud setup](/google-cloud). ## When the endpoint is one you do not want Not every line here is worth fixing. If the endpoint belongs to a product you do not own, the honest resolution is to switch off the collectors that read it, on the integration's own page — not to leave them scheduled and failing. The list is meant to reach zero.