Webhooks & replay
Get every event to the right workspace.
Connect GitHub.
Configure your GitHub App or repository webhook with:
| Payload URL | https://pepe.example.com/github |
|---|---|
| Content type | application/json |
| Secret | The relay configuration's webhook_secret |
| Events | Pull requests, pull request reviews, pull request review comments, and issue comments |
The first matching PR event pins that repository and PR number to the workspace. Later PR comments and reviews keep following the pin, including after a branch rename. Forks cannot establish ownership by copying a branch prefix. Ordinary issues and unknown branches are never broadcast.
For an existing PR without the branch prefix, claim it explicitly:
pepe claim --repo 12345678 --pr 42
pepe status--repo takes GitHub’s numeric repository ID. A claim cannot steal another workspace’s PR. Claiming affects routing; use replay to dispatch an already stored event.
The agent forwards the original body and signature. If your app has a different webhook secret, set PEPE_LOCAL_WEBHOOK_SECRET; the agent re-signs the unchanged bytes using that secret.
Follow the event. Replay it.
Pepe keeps a delivery until the app accepts it. A timeout or non-2xx response leaves it queued. Explicitly replay an event using the original GitHub delivery ID:
pepe replay --delivery <github-delivery-id>Replay retains the original body and delivery ID and increments X-Pepe-Attempt. Automatic retries keep the same attempt. Consumers should deduplicate successful processing by delivery and attempt, with idempotent business operations.
For an unclaimed event, establish ownership first, then replay it. Duplicate deliveries from GitHub remain deduplicated; Pepe's replay operation is the way to request another attempt.
Events have no automatic retention yet. Monitor disk usage. Removing a workspace also removes its routing, event, and OAuth state.