Skip to content
Sigvane Docs

Concepts

Sigvane introduces a few terms that show up in every guide. This page defines them once, so the rest of the docs can stay short.

How the pieces fit together

Section titled “How the pieces fit together”

GitHub sends webhook deliveries to a Sigvane inbox. Each inbox has its own webhook URL and signing secret. When a delivery arrives, Sigvane checks the signature using the secret. If accepted, it is stored as an inbox item.

In practice, the setup flow looks like this:

  1. Create an inbox in Sigvane.
  2. Copy its webhook URL and signing secret.
  3. Paste those values into GitHub’s webhook settings.
  4. Check recent items in Sigvane after GitHub sends a delivery.
  5. Use the API or CLI when your agent, worker, or workflow is ready to process inbox items.

Inbox

Section titled “Inbox”

An inbox is the webhook destination you manage in Sigvane. Each inbox owns:

  • one webhook URL
  • one signing secret
  • one stream of stored inbox items

A good default is one inbox per GitHub repository. That keeps each repository’s secret separate and gives your automation a focused stream of events.

If you want one stream for an entire GitHub organization, you can point an organization-level webhook at one inbox instead.

An inbox also has a slug, such as my-repo. The slug is a readable name in Sigvane and in CLI configuration. The webhook URL uses the inbox ID, so renaming the slug does not change the URL that GitHub calls.

Webhook URL

Section titled “Webhook URL”

The webhook URL is the full URL you paste into GitHub’s Payload URL field.

Use the exact URL shown by Sigvane. It identifies the inbox that should receive the delivery.

Signing secret

Section titled “Signing secret”

The signing secret (or simply secret) is the shared secret for one inbox.

Paste it into GitHub’s Secret field when creating the webhook. GitHub uses it to sign each delivery, and Sigvane uses it to verify authenticity.

Treat the signing secret like a password. If you rotate it in Sigvane, update the corresponding webhook in GitHub.

Provider

Section titled “Provider”

A provider is the service that sends webhook deliveries to Sigvane. Sigvane currently supports GitHub.

Signing in with GitHub only grants access to Sigvane. To send events, configure a webhook in the GitHub repository or organization you want to connect.

Inbox item

Section titled “Inbox item”

An inbox item is the stored record of one accepted webhook delivery.

A delivery is accepted when it reaches Sigvane, matches an inbox, passes signature verification, and is stored for later use. Rejected deliveries are not stored.

Inbox items include the delivery body and selected headers. Sigvane does not interpret GitHub events. Your agent, worker, or workflow decides what a push, ping, or pull_request delivery means.

Provider retries can create duplicate inbox items. Design your workflow to handle duplicates safely.

API

Section titled “API”

The API is the authenticated interface used to read inbox items.

You do not need it for the quick start. Use it when your agent, worker, script, or service needs to consume inbox items outside the browser.

CLI

Section titled “CLI”

The CLI is the Sigvane command-line worker.

It polls one or more inboxes via the API and runs a local command for each inbox item. The command is yours: it can log the item, decode the body, call another service, trigger a workflow, or ignore events you do not need.

The CLI reads inbox items from Sigvane; it does not create GitHub webhooks for you.

Section titled “Related guides”