Pick what you watch

By default, Intello monitors the entire integration. This is the appropriate setting for most teams. This page describes the situations where a narrower scope is warranted, and how to configure authentication when the specification itself is protected.

The default: monitor everything

When you add an integration, every endpoint, schema, and authentication flow declared in the specification is included in the snapshot. New surfaces appear as Safe additions, removed surfaces appear as Breaking changes, and your team decides how to respond to each.

We recommend resisting the temptation to scope down preemptively. The cost of monitoring extra endpoints is negligible; the cost of failing to monitor an endpoint that later breaks is one production incident.

When narrowing scope is warranted

Three legitimate reasons to reduce coverage:

1. You consume only a small portion of a large API. Providers such as AWS expose thousands of operations, but most teams use only a few. Monitoring the full surface would generate a large volume of irrelevant additions.
2. The provider publishes a single specification covering several products, and you ship only some of them.
3. The specification contains internal-only operations that the provider exposes but your contract prohibits you from using.

If your situation does not fit one of these categories, retain the default.

How scoping works

Catalog providers in the Library carry a recommended monitoring mode and an initial scope, both of which apply automatically when you add the integration. For more granular control, the dependency record supports two filter fields:

• filtered_domains — restricts monitoring to specific API domains (for example, billing or webhooks). Domains are derived from the specification's tags and path structure.
• filtered_endpoints — restricts monitoring to specific operation paths.

These fields are accepted by the API and applied at sync time; excluded operations are still captured in the snapshot, but no change events are generated for them. If you re-include an operation later, its history is preserved.

Versioned APIs

If a provider uses URL-based versioning (for example, /v1 or /v2025-01-15), monitor the version that matches the one your code consumes — not necessarily the latest. Library entries for vendors such as Stripe, GitHub, and Anthropic are pre-configured with the appropriate version pattern. For custom integrations, ensure the spec URL points to the correct version.

Authenticated specifications

Most public APIs publish their OpenAPI document at an unauthenticated URL. Some providers require an API key, bearer token, or HTTP Basic credentials to fetch the specification itself.

When configuring a custom integration, the Authentication field in the dependency form supports the following options:

• None — no credentials sent.
• API Key — sent as a custom header.
• Bearer Token — sent as Authorization: Bearer <token>.
• Basic Auth — username and password sent as standard HTTP Basic.

Credentials are encrypted at rest using AES-256-GCM and are used solely to fetch the specification. Intello does not call the underlying API.