How Intello works

This page describes the conceptual model behind Intello: what gets stored, what runs on a schedule, and how raw OpenAPI documents become change events you can alert on. You’ll see these ideas reflected in the Dependencies, Dashboard, and Changes screens—no API calls required for day-to-day use.

Architecture at a glance

flowchart LR
  subgraph tenant [Your org]
    Dep[Monitored dependency]
    Sub[Provider subscription]
  end
  Job[Sync job]
  Snap[Spec snapshot]
  Diff[Diff engine]
  CE[Change events]
  Alert[Alert dispatch]
  Dep --> Job
  Sub --> Job
  Job --> Snap
  Snap --> Diff
  Diff --> CE
  CE --> Alert

You define what to watch: a dependency (your OpenAPI URL) and/or a provider subscription (catalog specs).
The sync pipeline claims a sync job, fetches the spec, parses and normalizes it, materializes a snapshot, diffs against the previous snapshot, persists new change events, then runs alert logic.
Jobs are durable: each stage checkpoints. A crashed worker resumes from the last completed stage.

Monitored dependencies (bring your own)

A monitored dependency is the primary object for BYO monitoring:

Spec source — typically url with an HTTPS OpenAPI document.
Base URL — logical service root (used for display and domain mapping context).
Sync frequency — how often to enqueue checks (hours), subject to plan limits.
Health — circuit-breaker style status after consecutive failures (healthy → degraded → unhealthy → paused automatic scheduling).

Manual “Sync now” still enqueues work even when automatic scheduling pauses—useful to recover after fixing a bad URL.

Details: Add a dependency, What gets monitored.

Provider catalog and subscriptions

The provider catalog is a curated set of vendor APIs Intello maintains as provider specs. Your org creates a provider subscription to receive updates when those specs change—similar pipeline, but fan-out is scoped to subscribers.

When to prefer subscriptions vs BYO dependencies:

Subscription — you want Intello to track the canonical vendor document Intello already hosts.
BYO dependency — you point at your fork, gateway-exposed spec, or a URL with auth Intello can reach.

Details: Integration library.

Snapshots

A snapshot is an immutable, normalized representation of a spec after a successful sync. Intello compares current vs baseline snapshots to emit change events.

You can inspect:

Metadata — timing, dependency linkage.
Operations list — resolved HTTP methods and paths.
Raw document — the normalized spec body for debugging (can be large).

Details: Sync jobs and snapshots.

Diffing and change events

The diff engine compares normalized OpenAPI structures and emits change events with:

kind — e.g. endpoint_removed, response_schema_changed, parameter_type_changed.
severity — safe, risky, or breaking.
breaking — boolean flag for contract-breaking interpretations.
operation_path — affected operation when applicable.
cause_key — groups fan-out from a single root change (e.g., one shared schema touching many routes) so UIs and alerts deduplicate.

Details: How diffs are generated, Changes and classification.

Alerts and notifications

Alerts are policy-driven:

Org-level destinations — Slack / Teams OAuth or webhooks, email, PagerDuty routing keys.
Per-dependency (or per-subscription) preferences — scope, minimum severity, breaking-only toggles, optional channel allow-lists.

Details: Alert channels, Alert preferences.

Who can see what

You sign in to the app with your org’s normal account; Intello only loads your organization’s data. For how roles and invitations work in Settings, see Organizations and access. Direct HTTP API access (automation) uses the same identity model—Authentication.