/api-webhooks

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select api-webhooks from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv api-webhooks, /just-vibe api-webhooks and /jv:api-webhooks in Claude. See shortcut setup and context examples.

What the agent does

1. Verify signatures over the provider-specified raw bytes and time rules, comparing in constant time and accepting current and previous secrets during a bounded rotation period.
2. Persist receipt identity before acknowledgment, and separate durable deduplication from business processing.
3. Test invalid, duplicate, delayed and reordered messages.

Inputs

• inbound/outbound direction, provider contract, signing method, events, and environment.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Verification, delivery/retry, replay handling, event ordering, and tracking for the specified integration.

Writes

Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.

Mode

Apply; inbound/outbound direction, provider contract, signing method, events, and environment.

Prerequisites

Interface definitions, producer/consumer source, authentication model, versioning constraints, and isolated test endpoints. External API calls must respect environment, credentials, rate limits, and side-effect scope.

Expected output

• Webhook implementation and configuration names, a receipt/processing state machine, and invalid, replayed, duplicate and reordered checks.

How the work is checked

• Invalid signatures cause no business effect; retried events do not duplicate the intended effect.

When to stop or clarify

• Never log signing secrets or send real business events without authorization. Provider uncertainty must be resolved before relying on delivery guarantees.

Handling missing context

Infer

Read producer/consumer schemas, error contracts, auth conventions and known supported client versions.

Assume

Keep compatible response and pagination semantics where the brief does not request a breaking change.

Ask

Ask when contract sources disagree or an unknown consumer changes compatibility; do not require live credentials to write or test an isolated client.

Technical guidance

Evidence

Read the provider's signature contract, raw-body handling, timestamp tolerance, event IDs and retry/order semantics.

Method

Verify authentic bytes before side effects with a constant-time comparison (for example crypto.timingSafeEqual or hmac.compare_digest), accepting current and previous secrets during a bounded rotation period; durably deduplicate delivery and business effects, and handle out-of-order versions deliberately.

Pitfall

Re-serialized JSON changes signed bytes; a valid signature does not prevent replay or duplicate processing.

Check

Test altered body, invalid/stale signature, a delivery signed with the previous secret during rotation, concurrent duplicate, reversed event order and a crash before acknowledgment with synthetic fixtures.

Situational decisions

When valid events arrive out of order or concurrently: Apply version/ordering policy and durable effect deduplication rather than assuming arrival order.

When sending webhooks to customer-supplied URLs: Validate destinations after DNS resolution (block private, loopback and link-local ranges; limit redirects), sign id.timestamp.body with a per-endpoint rotatable secret, give each event a stable ID, retry with bounded exponential backoff and jitter, record every attempt, and disable persistently failing endpoints. Test against a private-IP target and a redirecting endpoint.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring