Dependencies, providers, and subscriptions

This page disambiguates the three ways Intello represents “an API we track.” Picking the right model keeps alerting accurate and reduces duplicate monitoring.

Monitored dependency (BYO)

A monitored dependency is your org-owned integration record.

Field (conceptual)	Purpose
`name`	Human label in dashboard and alerts.
`spec_source`	Usually `url` for customer-hosted OpenAPI.
`spec_url`	HTTPS location of the OpenAPI document.
`base_url`	Service root for context and domain mapping.
`sync_frequency_hrs`	Hours between scheduled sync attempts.
`enabled`	When `false`, scheduler skips automatic sync (manual may still run).
`monitoring_mode`	`full` vs `partial` (filtered domains/endpoints) to limit scope.
`is_catalog_managed`	`true` when created from catalog flows—controls product behaviors.

When to use: you have a stable URL Intello can fetch (public spec, or authenticated via supported auth_config patterns).

Deep dive: Add a dependency.

Provider (catalog entry)

A provider is a row in Intello’s catalog describing a vendor API Intello maintains (metadata, icons, links). Providers own one or more provider specs (versioned or alternate surfaces such as REST vs MCP).

When to care: you want Intello to host the canonical spec copy and broadcast updates to many customers consistently.

Provider subscription

A provider subscription links your org to a catalog provider. Instead of duplicating BYO dependencies per vendor, you:

Subscribe to the provider.
Enable the provider spec slices you care about (specific documents or surfaces).
Receive provider change events and optional alert prefs scoped to that subscription.

When to use: you standardize on Intello’s curated spec for a vendor and want automatic updates without managing the upstream URL yourself.

Deep dive: Integration library.

Spec overlap: avoid double-monitoring

Running both a BYO dependency and a subscription to the same vendor can duplicate noise if both track identical documents. Prefer:

Subscription only for catalog-covered vendors.
BYO only when you must track a non-canonical spec (forked, transformed, or behind your edge).

In the app

BYO dependencies: Dependencies → add or edit a row; see Add a dependency.
Library: Dependency library / catalog → subscribe; see Integration library.

Developers: HTTP routes (orientation)

Intent	Typical routes
List/create BYO deps	`GET/POST /api/dependencies`
Mutate BYO dep	`GET/PUT/DELETE /api/dependencies/:id`
List catalog providers	`GET /api/providers` (authenticated) + `GET /public/providers` (marketing/rate-limited)
Subscriptions	`GET/POST /api/provider-subscriptions`, `DELETE /api/provider-subscriptions/:id`

Full tables: Core resources.