How webhooks work
Webhooks are HTTP POST requests sent to your specified endpoint whenever certain events occur in your repositories. When you create a webhook subscription, Code Storage will:- Monitor Events: Watch for the events you’ve subscribed to (e.g.,
pushorrepo.sync.*events) - Generate Payloads: Create JSON payloads containing event details
- Sign Requests: Add cryptographic signatures for security verification
- Deliver Webhooks: Send HTTP POST requests to your endpoint with automatic retries
Webhook headers
Every webhook request includes the following headers:Content-Type: application/jsonUser-Agent: Pierre-Webhook/1.0X-Pierre-Event: <event_type>(e.g.,push,repo.sync.started,repo.sync.succeeded,repo.sync.failed)X-Pierre-Signature: t=1642678200,sha256=abc123...(security signature)
Custom headers
Add static headers in the webhook editor to authenticate requests or attach routing metadata, for exampleAuthorization: Bearer <token> or X-Environment: production.
- Each subscription supports up to 10 custom headers, with 8 KiB total across names, values,
and the
:and line-ending separators (4 bytes per header). - Custom headers require an HTTPS endpoint.
- Names may contain ASCII letters, digits, and hyphens. Names are case-insensitive and must be unique. Values must contain printable ASCII characters, without leading or trailing whitespace.
- Values are encrypted when stored. After saving, only names are returned; use Replace value to enter a new value, Save value to keep that edit in the form, Cancel to keep the saved value, or Remove header to delete the header. Save the webhook to apply the changes.
- Changing the webhook URL preserves its saved headers.
- If saved headers cannot be read, the editor shows a warning. You can still disable or delete the webhook, or clear or replace its saved headers. Other webhook settings preserve the saved values.
- Pierre’s own headers:
X-Pierre*andX-Git3P*. - Connection and framing headers:
Host,User-Agent,Content-*,Connection,Keep-Alive,Transfer-Encoding,TE,Trailer,Upgrade,Expect,Accept-Encoding,HTTP2-Settings, andProxy-*. - Client identity headers added by proxies and CDNs:
Forwarded,Via,X-Forwarded-*,X-Envoy-*,X-Real-IP,X-Client-IP,True-Client-IP,X-Cluster-Client-IP,CF-Connecting-IP,CF-Connecting-IPv6,CF-Ray,Fastly-Client-IP, andCDN-Loop. - Trace propagation headers:
Traceparent*,Tracestate*,Traceresponse*,Baggage*,X-Cloud-Trace-Context,X-Amzn-Trace-Id, andX-Amz-Cf-Id. - gRPC headers:
Grpc-*.
Event types
push
Triggered when commits are pushed to a repository.
repo.sync.started
Triggered when a repository sync run begins, before the upstream fetch executes. Useful for tracking
sync progress or updating status indicators in your UI.
repo.sync.succeeded
Triggered when a sync run completes successfully.
repo.sync.failed
Triggered when a sync run fails, including mirror activity failures (after retries are exhausted)
and infrastructure-level failures.
Sync event fields
Cancellations triggered internally (e.g., when a repository is detached from its upstream) do not
produce a
repo.sync.failed event.Securing webhooks
To ensure the webhooks you receive are legitimate and from Code Storage, you must verify the HMAC signature included with each webhook delivery.HMAC Signature Verification
Each webhook includes anX-Pierre-Signature header with the format:
Webhook SDK methods
The SDK provides helper methods to help you validate webhook events quickly.Advanced SDK usage
Custom Validation Options:Common verification errors
When using the SDK, these errors are automatically detected and returned in theresult.error
field:
- Missing signature components: “Invalid signature header format”
- Timestamp too old: “Webhook timestamp too old (X seconds)”
- Future timestamp: “Webhook timestamp is in the future”
- Signature mismatch: “Invalid signature”
- Invalid JSON: “Invalid JSON payload” (when using
validateWebhook) - Missing headers: “Missing or invalid X-Pierre-Signature header”