Zekt Terminology

A Zekt customer adopts one or more personas that describe how they interact with the platform:

Provider — You expose your GitHub Actions workflows as Zekt services. You control which workflows are published and who can access them. When a consumer requests access, you approve or reject the request. Events dispatched from your workflows are brokered by Zekt and delivered to every approved consumer as a repository_dispatch event in their repo.

Consumer — You subscribe to services offered by providers. Once your subscription is approved, Zekt routes the provider's events directly into your repository — no tokens to manage, no infrastructure to set up. Your workflow simply listens on repository_dispatch.

Both — A persona can start as either Provider or Consumer and can be upgraded to both at any time, free of charge. This is a one-way upgrade — once you hold both roles, you cannot downgrade to a single role. The upgrade is self-serviced from within the Zekt management web console.

The Zekt Directory is the built-in marketplace where providers list their workflow services and consumers discover and request access to them.

Key properties of a Directory listing:

• 1-to-1 or 1-to-many — A service can have a single consumer or fan out the same event to many consumers simultaneously.
• Tags & descriptions — Services carry a custom description and tags to aid discoverability.
• Visibility scopes:
  • Public — Any Zekt customer can discover the service and request access.
  • Organization — Only visible to Zekt accounts that either own the service, or have at least one repository belonging to the same GitHub organization as the providing repository. Useful for internal platform teams.
  • Unlisted — Not listed in the Directory. Anyone given the service's id can still request access, and the owner approves.
• Access control — Providers approve or reject subscription requests. Access is granted automatically only where the provider has set an auto-approval rule, for a specific GitHub user or for All Consumers.

Zekt Core — shallow, 1-step depth

The majority of integration scenarios are handled with Zekt Core alone. A provider dispatches an event and one or more consumers receive it. The chain has a depth of exactly 1 — provider sends, consumer receives. Simple, cost-effective, and sufficient for most use cases.

Zekt Chainlink — deep, multi-hop business processes

When a business process requires more than one hop — where a consumer must also forward events onward to their partners, within or across different GitHub organizations — that is where Chainlink applies. Each Chainlink repository acts simultaneously as a consumer (receiving from upstream) and a provider (dispatching downstream).

Key properties of each Chainlink node:

• Fan-out — A Chainlink repo can dispatch to many downstream consumers simultaneously.
• Payload transformation — Before forwarding, a Chainlink repo can redact sensitive fields or enrich the payload for the next step.
• Independent service boundary — Each Chainlink repo must expose its own Zekt service. Every hop is an explicit, managed subscription.

Zekt provides two complementary visualizations that give you a live picture of your integration topology:

Brokering visualization

Shows the full routing graph for your account: provider repositories, their workflows, the Zekt services those workflows are exposed as, and which consumer repositories are subscribed to each service. You can trace the exact path an event travels from its origin to every recipient — across repositories and organizations.

Blast radius visualization

Answers the question: "If this service goes down or changes its payload, who is affected?" The blast radius view highlights all downstream consumers connected to a given service or provider repository, making it easy to assess the impact of a change before you make it.

Persona-aware

Both views adapt to your persona. As a provider you see who is consuming your services. As a consumer you see what you depend on. As both, you see the full picture — inbound dependencies and outbound reach in a single graph.

Relationship visualization is available in the Zekt management console at no additional cost.

Zekt uses the concept of Shepherd and Disciple accounts to support multi-user collaboration within a single Zekt estate.

Shepherd account

The Shepherd is the primary Zekt account — the account that signed up, provided payment details, and holds the billing relationship. All costs incurred within the estate are charged to the Shepherd's payment method. The Shepherd has full administrative access to every feature and configuration.

Disciple accounts

When a Shepherd needs a trusted colleague to help manage their Zekt estate, they can invite that person as a Disciple from the management console. A Disciple can perform all the same administrative tasks as the Shepherd — enabling repositories, managing subscriptions, approving access requests, and so on — with one important exception:

Disciples cannot modify rules configured with Doctrine.

Doctrine is a feature within Zekt Shield that lets the Shepherd define which providers are approved to be consumed from, and which consumers are permitted to subscribe. Because these rules govern the trust boundary of the entire estate, they are Shepherd-only.

Important: billing responsibility

The Shepherd should only invite Disciples they fully trust. Any cost generated by a Disciple's actions is billed to the Shepherd's account. Disciples are invited and managed from Profile → Flock in the Zekt management console.

By default, a Zekt Core repository is either a provider (it sends events) or a consumer (it receives events) — never both at the same time.

Chainlink removes that restriction. A single Chainlink-enabled repository can simultaneously act as a provider and a consumer — receiving events from upstream services and dispatching new events downstream, forming a link in a longer, multi-hop event chain.

Pricing comparison:

At first glance two separate Zekt Core repos appear cheaper. The difference is architectural: two Zekt Core repos can only form a chain of depth 1. Chainlink enables closed loops and deep chains — a sequence of repositories where each one transforms or enriches an event before passing it on, and where a chain can eventually route back to the same source. This pattern is common in multi-step business process flows (trigger → validate → enrich → notify → confirm) that cannot be expressed with a single provider/consumer pair.

Use Chainlink when your workflow is a link in a longer process, not just an endpoint.

At its core, Zekt is an eventing platform. Each provider repository has its own Zekt webhook that fires whenever a whitelisted workflow runs, capturing metadata about the run — the run_id, correlation ID, timestamps, and workflow identity. This metadata alone is the event.

Enriching events with a message payload

For cases where metadata isn't enough, the Zekt Action (a free GitHub Action) lets you attach an arbitrary JSON payload — up to 1 MB per dispatch — to the event. The payload is whatever you decide to send: build outputs, test results, deployment details, business data — any valid JSON structure.

How it works technically:

1. You add the Zekt Action as a step inside your provider workflow.
2. When the step runs, it sends your JSON payload along with the workflow's run_id to the Zekt backend.
3. Zekt holds the payload, waiting for the workflow to complete.
4. When the workflow finishes, Zekt's webhook fires with the run metadata. Zekt matches the run_id from the webhook to the held payload.
5. Zekt consolidates both into a single repository_dispatch payload and delivers it to all subscribed consumers.

Consumers always receive one unified event — whether or not a payload was attached. If the Zekt Action was not used, the payload field is simply absent or empty.

The Zekt Action is free — it does not add to your base fee or trigger additional billing beyond normal dynamic usage.

Zekt Shield is an optional add-on to Zekt Core. It costs $12 / repo / month on top of the Core base fee ($27 / repo / month combined, plus dynamic usage cost). The cost is associated with the provider repository.

How it works — Bring Your Own Key

The consumer generates an RSA-4096 key pair. The private key never leaves the consumer and is never shared with or known to Zekt. The public key is uploaded to Zekt so the provider action can encrypt for that consumer.

When the Zekt Action runs with shield: true, it fetches the consumer's public key from Zekt and encrypts the payload using hybrid encryption (AES-256-GCM + RSA-OAEP-SHA256) before the payload reaches Zekt. Zekt stores and routes the opaque envelope — it never possesses the decryption key.

- name: Send Shielded Payload To Zekt
  id: zekt
  uses: zekt-dev-org/zekt-action@v3
  with:
    event-type: 'your-event-name'
    payload: ${{ steps.build-payload.outputs.payload }}
    shield: true

Consumers use their own private key (never uploaded to Zekt) to decrypt the ciphertext they receive. This is true Zero-Knowledge Encryption (ZKE) — end-to-end confidentiality guaranteed even against the broker.

Shield and Time Travel (replay)

Zekt can't read encrypted payloads; archived and replayed Shield events stay encrypted. Time Travel archives the ciphertext and re-dispatches it unchanged, so only the consumer's private key can open it, and the archive cannot show its content.

Replay is part of Zekt Analytics — an optional add-on to Zekt Core at $10 / repo / month (on top of the Core base fee, plus dynamic usage cost). Analytics includes two related replay capabilities:

Time Travel — Browse the full event history for a service and re-dispatch any past event (including its associated message payload, if one was sent via the Zekt Action) to all current subscribers. Useful when a consumer workflow failed for a transient reason and needs to reprocess the event.

Webhook Replay — Re-deliver a specific webhook delivery to the provider's own endpoint. Useful for debugging the provider side.

When to use it

Replay lets you recover from failures without re-running the original provider workflow. As long as the consumer workflow is idempotent (safe to run more than once for the same event), replaying an event is a clean, low-risk recovery path.

Replay also surfaces the full JSON payload in the Zekt UI — making it easy to inspect exactly how a payload is structured so you can write or fix parsing logic on the consumer side without waiting for the provider to fire a new event.

Replay and Zekt Shield: Zekt can't read encrypted payloads; archived and replayed Shield events stay encrypted. A replay re-dispatches the same ciphertext, and Zekt never holds the decryption key.

Zekt billing has three layers:

1. Base fee (per repository)

The foundational cost. Zekt Core is $15 / repo / month, billed per repository you enable in Zekt — regardless of how many workflows or services that repository exposes.

2. Add-on features (optional)

Add-ons are layered on top of the Core base fee for a given repository. Examples include Analytics, Shield, and Chainlink. Each add-on has its own per-repo monthly rate. You only pay for the add-ons you activate, on the repos you activate them on. Full add-on pricing is listed at zekt.dev/zekt-pricing.html.

3. Dynamic usage cost

On top of any base fees and add-ons, Zekt meters actual usage — event dispatches, API calls, and similar activity. This cost scales with how much you use the platform and applies regardless of which combination of Core and add-ons you are running.

In short: base fee + add-ons = your predictable monthly commitment. Dynamic cost = what you actually consume on top.

Zekt billing has two distinct cost categories:

Base fees — Fixed, predictable monthly costs tied to the features and add-ons you have enabled per repository. These stack: enabling Core + Analytics + Shield on a single repo means paying all three base rates for that repo. Base fees do not change based on how much you use Zekt.

Dynamic usage costs — Variable costs metered on actual consumption: API calls, event dispatches, payload storage, network transfers, and compute. If you send one event per week, dynamic costs will be minimal. If you run high-frequency dispatches with large payloads to many subscribers, dynamic costs scale accordingly. The goal is fairness — you pay in proportion to what you consume.

You can monitor your current and projected dynamic costs at any time in the Billing → Current Usage tab of the Zekt management console. The breakdown shows consumption per cost dimension so you can identify which activity is driving your bill.

Zekt billing has two distinct categories: static fees and dynamic usage costs.

Static fees — predictable, pro-rated to the day

Static fees are the fixed monthly rates for each feature enabled on a repository (Core, Analytics, Shield, Chainlink, etc.). They stack per repo. Pro-rata applies — you are charged only for the days a repository or add-on was active within the billing month:

Charge = Monthly rate × (Days active / Days in month)

Concrete examples:

• Repo enabled May 15 in a 31-day month → 17 days → $8.23 (Core base only)
• Shield add-on enabled May 20 → 12 days → $4.65 (Shield portion)
• Repo disabled Feb 10 → 10 of 28 days → $5.36

Rounding uses standard half-up rules. Day boundaries are in UTC — there is no fractional-day pro-rata. Zekt never rounds up to the nearest month.

Dynamic usage costs — metered, never pro-rated

Dynamic costs cover actual consumption: event dispatches, payload storage, API calls, compute, network transfers. They are already metered per-event, so pro-rata does not apply. Any promotional or contractual discount applies to your static fee subtotal only — not to dynamic costs.

Trial conversion and offboarding

If you convert from trial mid-month, static fees begin on the day of conversion. If you offboard mid-month, billing stops on the day you leave. Both are handled automatically.

Taxes

Stripe Tax (VAT/GST) is calculated on the post-pro-rata, post-discount subtotal — the figure on your invoice already reflects all adjustments before tax is applied.

Zekt exposes its administrative capabilities through three interaction surfaces:

Web console — The primary interface. All functionality is available here first. This is the single place where every Zekt feature is exposed. New capabilities are published to the web console before any other surface.

VS Code extension (beta) — The most common administrative tasks (managing repositories, viewing delivery status, browsing the Directory) can be performed directly from VS Code. Reduces context-switching for developers who live in their editor. Built on top of the MCP layer below. Not all web console features are available here.

MCP (Model Context Protocol) — The foundational API layer that the VS Code extension is built on. Zekt is natively MCP-ready, meaning it can be integrated conversationally — through AI assistants or custom tooling built by your organization. Designed for teams or enterprises that want to automate Zekt operations or embed it into existing toolchains.

Zekt offers a free VS Code extension that lets you perform the most common Zekt administrative tasks without leaving your editor — reducing context switching for developers who live in VS Code.

Getting connected

1. Install the Zekt VS Code extension from the VS Code Marketplace.
2. Generate an API key from the Zekt management console (under your account settings).
3. Enter the API key into the extension when prompted. The key is stored securely within VS Code's built-in secret storage — it is never written to disk in plain text.

The API key is tied to your Zekt customer ID, so all usage through the extension is attributed to your account. An expiry is optional: when you create a key you choose an expiry date or "No expiration". A key that has expired stops working, and you create a new one in the management console.

How it works under the hood

The VS Code extension is built on top of MCP (Model Context Protocol). Every action you take through the extension UI translates into MCP tool calls against the Zekt backend. Token consumption from these calls is metered and billed to your account as part of normal dynamic usage costs.

Scope of the extension

The extension covers the most common tasks — managing repositories, browsing the Directory, viewing delivery status, and similar day-to-day operations. It does not expose every feature available in the full web console. For anything not available in the extension, use the web console at www.zekt.dev.

Self-trigger your own repo through Zekt — and get the same observable, replayable, auditable pipeline you'd get across repos. Unlike workflow_call, your downstream workflow runs asynchronously and is fully decoupled: replay a failed step without re-running the trigger, inspect every delivery in Zekt's dashboard, and avoid the tight coupling that makes monolithic workflow chains brittle.

Turn a single repo into a multi-stage async pipeline. Self-trigger lets your workflows hand off to each other through Zekt — so you get decoupled execution, full replay, and delivery observability, without the tight coupling of workflow_call.

Zekt Registry is the optional feature included, where providers can publish their payload schemas to their consumers. This way, the consumers can see how the payload is looking in a certain version, and choose if they want to parse more information introduced in later versions by the provider service. The Registry literally helps the consumer to not "guess" the payload structure — by having it presented to them, from within the Registry.

Visit the https://www.zekt.dev/zekt-registry.html webpage — to check out public service payloads hosted within Zekt.

A single Zekt-enabled provider repository can host as many workflows as you like. Each workflow is independently controlled:

• Disabled — The workflow exists in the repo but is not exposed through Zekt. Consumers cannot see or subscribe to it.
• Whitelisted — The workflow is exposed as a Zekt service and can be published to the Directory for consumers to discover and subscribe to.

This lets you consolidate multiple workflows into a small number of enabled repositories, getting strong value from the $15 / repo / month base fee — rather than spreading workflows across many repos and paying for each separately.

One workflow = one service (always)

The relationship between a workflow and a Zekt service is strictly 1-to-1. A single workflow can only ever be shaped into a single Zekt service. If you want to expose two distinct services, you need two distinct workflows. There is no way to map one workflow to multiple services, or combine multiple workflows into one service.

Zekt automatically manages webhooks for your enabled provider repositories — you never need to configure them manually in GitHub.

Automatic lifecycle

• When you enable a provider repository in Zekt, the webhook is created on the GitHub repository automatically.
• When you disable a repository, the webhook is removed automatically. Nothing is left behind.

Webhook Health tab

The Health → Webhook Health section of the management console gives you visibility and control over each repository's webhook:

• Ping — Send a test delivery to the webhook endpoint to confirm it is reachable and returning a healthy response. Useful after infrastructure changes or suspected delivery issues.
• Secret rotation — Cycle the HMAC signing secret of an individual webhook at any time. Zekt updates both the GitHub webhook configuration and its own backend simultaneously, so there is no window where signatures are invalid.

Webhook management is included for all enabled provider repositories at no additional cost.

Redaction Guard is included as part of Zekt Shield (the optional add-on). It acts as an additional layer of defence between the provider payload and the consumer — screening outbound payloads for sensitive content before they are dispatched.

How it works

Zekt maintains a set of built-in regex patterns covering common secret formats — GitHub tokens, API keys, and similar credential patterns. Before a payload is dispatched to consumers, Redaction Guard scans the payload content against these patterns. Any match is masked with * characters in place of the original value. The redacted payload is what consumers receive; the original sensitive value is never forwarded.

Customers can extend the built-in pattern set with their own custom regex rules — for example, to catch organisation-specific secret formats, internal reference numbers, or PII patterns unique to their data.

Why this matters

Even when providers construct payloads carefully, accidental secret leakage is a real risk — a workflow might inadvertently include an environment variable value, a token from a previous step output, or a credential embedded in a build artefact. Redaction Guard provides a safety net that operates independently of the provider's own diligence.

Redaction Guard is available on any repository with Zekt Shield enabled. No additional cost beyond the Shield add-on fee.

Zekt maintains an audit log of management and configuration events across your account. Every significant action is recorded with a timestamp and the identity of who performed it.

What is audited:

• Subscription requests from consumers — approvals and rejections
• Auto-approval rules added or removed (per individual GitHub user, or for All Consumers)
• Repository enablement and disablement
• Service publish / unpublish actions
• Access revocations
• Configuration changes to add-ons (Shield, Analytics, etc.)

Where to find it

Audit entries are surfaced in their own dedicated navigation item within the Zekt management console. Entries are listed in reverse chronological order and are filterable by event type and date range.

Export

The full audit log is exportable as .json — useful for compliance reviews, incident investigations, or feeding into your own SIEM or logging pipeline.

The audit log is available to all Zekt customers at no additional cost. It is not an optional add-on.