Delivery

Contents

How decisions reach the people who own them: the watched dependencies file, Slack, GitHub issues, email alerts, retries and limits. Signed webhooks have their own section below.

Watching your dependencies file

npx interfacedelta watch hands .interfacedelta/dependencies.json to InterfaceDelta. InterfaceDelta then checks every dependency continuously and routes each decision to its owner.

Create a watch token in Routing → Watch tokens and set it as INTERFACEDELTA_API_TOKEN for the CLI or the INTERFACEDELTA_WATCH_TOKEN Action secret; it is bound to the repository and branch, with the lockfiles:write scope.

Run it from CI on the default branch, after the file changes. A run on an older commit than the watched one is skipped unless --force is given. npx interfacedelta watch --off stops watching.

PlanWatched lockfiles and destinations. Pro has 3 watched lockfiles and 10 destinations; Team has 20 and 50.
After a downgradeThere is a 14-day grace period, then the newest extra files and destinations pause.
Decision historyKept for 365 days.

Slack

Slack destinations use Slack incoming webhooks, so a decision lands in the channel that owns the dependency.

  1. In Slack, create an app at api.slack.com/apps, or use an existing one.
  2. Enable Incoming Webhooks, choose Add New Webhook to Workspace, and pick the channel.
  3. Copy the URL. It has the form https://hooks.slack.com/services/T…/B…/….
  4. In InterfaceDelta, open Routing → Destinations, add a Slack destination, paste the URL, then choose Verify, which sends a test message.

The URL is stored encrypted and is never shown again. Only hooks.slack.com URLs of exactly that form are accepted.

GitHub issues

InterfaceDelta holds no GitHub credential. Your own workflow runs the InterfaceDelta Action with issues: true. It pulls the decisions waiting for its repository and branch, opens one issue for each with the workflow's own GITHUB_TOKEN, then acknowledges it.

  1. In InterfaceDelta, open Routing → Destinations and add a GitHub destination for the repository, as owner/name.
  2. In Routing → Watch tokens, create a watch token for that repository and branch with the decisions:read and decisions:ack scopes, and store it as a repository secret.
  3. Add a scheduled workflow. It needs permissions: issues: write, and it should run in one concurrency group so two runs never overlap.

InterfaceDelta queues decisions for issues only while a GitHub destination exists for the repository; decisions made before the destination was added stay email, Slack and webhook only. From Action 0.3.1, when the repository has no GitHub destination and nothing is waiting, the run shows a warning that says so and links to Routing → Destinations.

on:
  schedule:
    - cron: '*/30 * * * *'
  workflow_dispatch:
concurrency: interfacedelta-decisions
jobs:
  issues:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write
    steps:
      - uses: arto-a/interfacedelta-action@c06ddb383cbd5d4b4fe487e9af7906f155d72257 # v0.4.0
        with:
          check: false
          issues: true
          api-token: ${{ secrets.INTERFACEDELTA_DECISIONS_TOKEN }}

Each issue carries the label interfacedelta and the decision's marker, interfacedelta-decision:<id>. Before it opens anything, the Action reads every labelled issue, open or closed, so each decision gets one issue even if a run is interrupted. Keep the label on these issues. Owners from the dependencies file are mentioned, and text that comes from the services is escaped.

A run handles up to 100 decisions; the rest wait for the next run. A decision not picked up within seven days expires, and the account owner is emailed.

Retries and limits

Push delivery allows 60 attempts per destination per hour, including failed attempts. GitHub pulls do not use that push limit. Delivery makes up to five counted attempts; rate deferrals during the first 24 hours do not consume attempts. Retry-After is bounded to 5–60 minutes. After ten permanent failures, the destination is disabled and an email notice is sent.

  • Retryable failures use backoffs of 5 minutes, 30 minutes, 2 hours and 8 hours.
  • 3xx responses and 4xx responses other than 408 and 429 are permanent failures.
  • Requests time out after 5 seconds, and redirects are not followed.

Monitoring and alerts

Signed-in users can subscribe to recurring target observations through the browser product. Breaking changes notify by default; indeterminate notifications are optional. A monitor watches the target origin's homepage and, if you choose one, a single same-origin page, and both are read for declarative WebMCP tools. Each watched page is its own target and counts toward your monitor limit. A watched page path becomes part of that target’s shared history: anyone with a Passport or observation link can read it, and it stays after your account is deleted, so never watch a path that contains a token, a private share link or personal data. Paths with credentials such as token= are refused. Current limits are beta guardrails, not service-level guarantees.

An account on the Free plan can describe up to three workflows and the monitored services, endpoints and capabilities each depends on. For each named dependency InterfaceDelta reports whether a recorded change touches it, that no change was observed, or that the evidence cannot say. It is computed when you look, from recorded evidence only; it never says whether you are affected, and changes you did not name stay listed. Workflows are private to the account and are never shared, used for discovery, or sent to any model.

Programmatic access. Developer API v1 supports token-authenticated account monitor automation and, with the workflows:read scope, workflow relevance reads. Email-delivery internals remain browser-private.

Back to contents

Next: Webhooks