Endpoints that need attention

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 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: 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, 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 <tenant>.
4. Wait a minute or two — consent takes a moment to propagate — then Verify now.

Permissions that commonly need consent, and what they unlock: 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: 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, 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.

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: 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.

​

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.

​

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.

​

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.