Offer a consumer service

A consumer service turns the usual direction around. Other accounts send events into one of your repositories, typically to ask for work to be done (“scan this image”, “create a resource group”). Consumer services are commonly called from orchestration, and can return outputs to the caller.

Requirements

• Your account has the Both persona. The Consumer Services sub-tab is shown only to accounts with Both. Upgrade under Profile → Persona & Access.
• The repository behind the service is an active consumer repository with Track Completion on.
• The service is enabled.

Create the service

1. Go to Provider → Service Descriptions → Consumer Services.
2. Fill in the form (see below).
3. Choose Create Consumer Service. Use Reset to clear the form.

Field	What it’s for
Consumer Repository *	The repository that receives the requests. Only active consumer repositories are listed.
Service Name *	Up to 100 characters.
Publisher Name	Up to 50 characters.
Description	What the service does, for people browsing the Directory.
Event Direction *	Subscribers fire events to me.
Dispatch Event Type	The event type your workflow listens for.
Service Slug (Optional)	The slug orchestration plans use. Lowercase kebab-case, 2–64 characters. Immutable once set.
Supports Orchestration	Declares that the service is meant to be orchestrated. It’s a declaration, not a gate: an undeclared service can still be orchestrated, and the requester gets a warning.
Service Tags	Help people find the service.
Publish to Directory	Choose Public or Organization. A new consumer service starts at Organization, and Zekt asks you to confirm before making one Public. See visibility.

After the service is created, you can add an avatar. In edit mode, you can publish an input and output schema so callers know what to send and what they’ll get back.

What your workflow receives

• event_type: the service’s event type, or zekt-workflow-completed if it has none.
• client_payload.input: the input the caller sent.
• client_payload._zekt: orchestration context (orchestration.executionId, orchestration.stepId, orchestration.requestorRepository) and dispatch_id.

Note

As the service owner, you see the name of the repository that called you.

Report outputs

Call the Zekt Action without event-type. It detects the orchestration context by itself, and its payload (a JSON object) becomes the step’s outputs.

name: security-scan service
on:
  repository_dispatch:
    types: [security-scan]
permissions:
  id-token: write
  contents: read
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - id: scan
        env:
          IMAGE: ${{ github.event.client_payload.input.image }}
        run: echo "verdict=pass" >> "$GITHUB_OUTPUT"
      - uses: zekt-dev-org/zekt-action@v3
        with:
          payload: |
            {"verdict":"${{ steps.scan.outputs.verdict }}","findings":0}

• Only the run Zekt dispatched can report outputs. If it calls the action several times, the last call wins.
• Return scalar values (strings, numbers, booleans): the Zekt Action exposes outputs as strings.
• The step’s result follows the GitHub run’s conclusion. A run that reports outputs and then fails still fails the step.

Subscribers

Subscribers to a consumer service name the provider repository they fire from and the workflow that fires. You approve them in Provider → Access, where these requests are badged Consumer service. Approving one needs the Both persona.

Disabling the service

Disabling a consumer service hides it, refuses new requests, and drops subscriber events: they aren’t held for later. Subscriptions are kept, and re-enabling the service restores everything.