Core concepts

You need about a dozen terms to use Zekt. Every guide uses them as defined here. For the full glossary, see zekt.dev/zekt-terminology.

Account

Your Zekt account is the customer: whoever signed up, holds the subscription and pays the bill. You sign in with your GitHub identity and manage everything in the web console at www.zekt.dev.

The account is created when you sign in with GitHub and submit Complete Your Profile. That GitHub login is the account owner. Colleagues can be added as members.

An account enables repositories, and those repositories can live under several GitHub owners: organizations, your personal GitHub account, or both. A repository can be enabled by only one Zekt account at a time.

An account is not a GitHub organization

A GitHub organization is only a scope where repositories live. It doesn’t own a Zekt account. Several Zekt accounts can each enable repositories under the same GitHub organization, and each account pays for its own repositories.

Persona

When you sign up, you choose the account’s persona: Provider, Consumer or Both. The persona decides which parts of the console you see and which repository roles you can use.

You can add the other role later, under Profile → Persona & Access. Upgrading to Both is one-way: you can’t downgrade afterwards.

Provider repository

A repository enabled as a provider sends events. Each workflow in it is either:

• Disabled: Zekt ignores it. This is the default.
• Whitelisted: the workflow is allowed to become a service. It becomes one when you save a service description for it, and other repositories can then subscribe to it.

When a run of a whitelisted workflow completes, Zekt delivers an event to every approved subscriber.

Consumer repository

A repository enabled as a consumer receives events. Zekt delivers each one as a GitHub repository_dispatch event, which a workflow in the consumer repository listens for.

Plan for duplicates

Zekt delivers at least once, so a receiving workflow may occasionally get the same event twice. Make consumer workflows safe to run twice for the same event.

Provider services and consumer services

Most services are provider services: a provider’s workflow runs and its subscribers are notified.

An account with the Both persona can also offer a consumer service. Here the service sits on a consumer repository, and other accounts send events into it, typically to ask for work to be done (“create a resource group”, “scan this image”). Consumer services are commonly called from orchestration.

Event and payload

An event tells subscribers that a provider workflow run has completed. It carries the run’s name, conclusion, branch and timestamps, and a correlation ID, but never the provider’s repository name or owner. On its own, that’s enough to trigger a consumer.

If consumers need more context, add the Zekt Action to the provider workflow to set the event type and attach a JSON payload. Consumers receive the event and the payload together. The event reference shows the exact shape.

Directory and visibility

The Directory is where signed-in accounts find services and request access. Each service has one of three visibility levels:

Visibility	Who can find it
Unlisted	Nobody can browse to it. Anyone given its service ID can still request it through the API or MCP; the console has no field for entering an ID.
Organization	Your own account, plus accounts with an active repository under the same GitHub organization that owns the service, plus accounts that joined through a Shepherd invitation. A service in a personal GitHub account’s repository reaches only your own account.
Public	Every signed-in Zekt account, plus visitors to the public Zekt Registry, who don’t need to sign in.

A new provider service starts unlisted. A new consumer service starts at Organization. See Publish to the Directory.

Access requests and connections

A consumer requests access to a service. The service owner approves or denies the request. Approval creates a subscription, which the console calls a connection, and events start flowing.

To skip the manual step, owners can set up auto-approval rules for a specific GitHub user or for all consumers. See Handle access requests.

Schemas

A service can publish versioned JSON schemas for its payload, so subscribers know what they’ll receive. Consumer services can also publish the shape of the outputs they return. See Payload schemas.