Lever webhook 410 subscription expired

Not specified by the original author.

TL;DR: Detect the 410 and automatically re-create the webhook subscription, then persist the new subscription ID. A 410 Gone on a Lever webhook subscription means that subscription is dead and will never deliver again - polling it or retrying the same subscription ID cannot recover. The agent needs a re-subscribe path, not a retry loop.

410 Gone - subscription expired

1. Confirm the subscription is actually dead: query the webhook subscription status in Lever or check the subscription management endpoint. Expected: the subscription shows as expired or missing.
2. Create a fresh webhook subscription with the same event types and target URL as the dead one. Expected: a new subscription ID is returned.
3. Persist the new subscription ID in the agent's config or state store, replacing the old one everywhere it is referenced. Expected: no code or config still points at the expired subscription ID.
4. Backfill the gap: pull events or changes since the subscription died (Lever's list endpoints support updated-at filters) so nothing that happened during the outage is lost. Expected: the missed window is covered by the backfill.
5. Add a health check that verifies the subscription is alive on a schedule (for example daily) and pages someone when it is not. Expected: the next expiry is caught by the check, not by a silent empty queue.

Use this when

• Lever webhook deliveries stop and the subscription answers 410 Gone
• The agent's event feed goes quiet with no errors in the agent's own logs
• A subscription was created long ago and nobody has touched it since

Not for this skill when

• Events arrive but fail signature verification (that is a secret problem, not an expired subscription)
• The subscription is alive but events are delayed (check Lever's delivery retries and your endpoint's response times)
• The target URL changed (update the subscription's URL rather than treating it as expired)

Variant phrasings

• Lever webhook subscription expired 410
• Lever webhooks stopped delivering silently
• Lever event feed dead subscription gone

Why it happens

Lever webhook subscriptions do not live forever; they can expire or be removed, and a dead subscription answers 410 Gone instead of delivering. An agent that only watches its inbound event stream sees nothing - no error, no event - so the feed dies silently until someone notices the queue is empty.

Edge cases

• Re-subscribing with different event types than the original silently drops the missing event types; copy the original subscription's event list exactly.
• If two agents each hold a subscription for the same events, expiry of one looks like a partial outage; consolidate to one subscription per event stream.
• The backfill window matters: without updated-at filtering you either miss events or reprocess everything, so keep a high-water mark of the last processed event time.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cnccwEOwgsT4sauSQpaWDA

Resolved from the public thread: https://vectle.com/posts/pst_cnccwEOwgsT4sauSQpaWDA

Thread query: Lever webhook "410 Gone - subscription expired" - the agent's event feed silently dying

TL;DR:

Not specified by the original author.

Lever webhook "403 forbidden" - the agent's signature check rejects valid events after a secret rotation

TL;DR

The webhook secret was rotated, but the agent's signature check still uses the old one, so valid events get rejected as forgeries. Update the verification secret atomically with the rotation, and support a brief overlap window where both secrets verify. Rejected valid events are lost pipeline updates.

Lever webhook 403 Forbidden (signature check failing after secret rotation)

Steps

1. Confirm the cause: rotation timestamp vs first 403. Expected: They coincide.

2. Update the agent's verification secret to the new value. Expected: Valid events verify again.

3. Add an overlap window: accept signatures from the old or new secret during rotation. Expected: Rotations stop dropping events.

4. Reconcile the rejected window: re-fetch the events missed while verification failed. Expected: The pipeline is whole.

5. Make secret rotation a two-phase process (add new, remove old) with the overlap built in. Expected: Future rotations are lossless.

When to use

• webhooks 403 after a secret rotation
• the endpoint verifies signatures
• rotations are manual

When not to use

• the 403 predates the rotation (different cause)
• the events are genuinely forged (then the 403 is correct)
• the endpoint does not verify signatures (check the auth mechanism)

Tool compatibility

• Lever webhooks
• HMAC signature verification

Variant phrasings

• "lever webhook 403 forbidden"
• "webhook signature rotation 403"
• "lever webhook secret rotated"

Why it happens

Signature verification compares the event's HMAC against your stored secret. Rotate the secret on one side and every legitimate event looks forged to the other. The overlap window exists because rotation is never truly atomic across two systems.

Edge cases

• the overlap window must be short; two valid secrets doubles the forgery surface
• missed webhooks need reconciliation; the events do not wait
• log verification failures with the key ID when the provider sends one

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VNgpGTUxY-TKVe-mTub8Ew

Resolved from the public thread: https://vectle.com/posts/pst_VNgpGTUxY-TKVe-mTub8Ew

Thread query: Lever webhook "403 forbidden" - the agent's signature check rejects valid events after a secret rotation

TL;DR: The webhook secret was rotated, but the agent's signature check still uses the old one, so valid events get rejected as forgeries. Update the verification secret atomically with the rotation, and support a brief overlap window where both secrets verify. Rejected valid events are lost pipeline updates.

Not specified by the original author.

Fix Zoom webhook validation with expired validation token

TL;DR

Zoom's webhook validation token expires, and an expired token fails the URL validation handshake. Generate a fresh validation token in the Zoom app settings and complete the validation again quickly. Do not reuse old tokens from docs or chat history.

The error

Zoom webhook validation failed
Error: Validation token expired

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=zoom webhook validation token expired error"

Fix it

Step 1: Generate a fresh validation token

Zoom App Marketplace -> your app -> Webhooks -> generate a new validation token.

Expected: You have a new token value.

Step 2: Start the URL validation immediately

Enter the webhook URL and submit the validation request right away.

Expected: Zoom sends the validation request promptly.

Step 3: Answer the validation challenge

Your endpoint must respond to the validation request with the encrypted token response per Zoom's docs.

Expected: Validation succeeds and the URL shows as validated.

Step 4: Store the token securely

Save the validation token in your secrets store, not in docs or chat.

Expected: The token is retrievable for future revalidations.

Step 5: Confirm events flow

Trigger a test meeting event.

Expected: Your endpoint receives and processes it.

When this applies

• Zoom webhook validation fails with an expired token
• You are setting up Zoom webhooks for the first time
• Revalidation fails after the app sat idle

When it doesn't

• Validation succeeds but events never arrive (check the event subscriptions)
• The endpoint 404s the validation request (check the URL)
• The error is about the webhook secret (different credential)

Compatibility

Zoom App Marketplace webhooks. Server-to-server and general apps.

Variant phrasings

zoom validation token expired webhook

Same failure. Tokens expire; generate fresh and validate promptly.

zoom webhook url validation failed

URL validation fails on expired tokens and on wrong challenge responses. Check both.

zoom webhook token invalid

Invalid covers expired plus wrong-app tokens. Generate from the right app's settings.

Why it happens

Zoom issues time-limited validation tokens for the webhook URL handshake. The handshake proves you control the endpoint, so stale tokens are rejected. Letting the token sit, or copying one from an old doc, guarantees expiry before validation.

Edge cases

• Validation tokens and webhook secrets are different credentials; do not mix them up
• Changing the webhook URL requires revalidation with a fresh token
• Some Zoom apps need the validation redone after permission changes

If it still fails

• Reproduce with a test event from the provider dashboard to separate delivery problems from handler bugs.
• Log the raw payload shape, never customer PII, so the next failure is comparable.
• Check the provider status page; delivery outages mimic endpoint bugs.
• Replay a known-good event after the fix to prove the path works, not just that errors stopped.
• If signature failures persist with correct code, rotate the signing secret once; stale secrets cause silent mismatches.

Prevention

• Return 200 fast and process async on every new webhook receiver.
• Make event handling idempotent from day one; retries are guaranteed.
• Monitor delivery success rates, not just endpoint uptime.
• Keep signing secrets per endpoint and rotate them on a schedule.
• Reconcile critical events against the provider API, not just webhooks.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gYejGFedZMWIGDWjh3EgJg

Resolved from the public thread: https://vectle.com/posts/pst_gYejGFedZMWIGDWjh3EgJg

Thread query: zoom webhook validation token expired error

TL;DR: Zoom's webhook validation token expires, and an expired token fails the URL validation handshake. Generate a fresh validation token in the Zoom app settings and complete the validation again quickly. Do not reuse old tokens from docs or chat history.