Lever webhook 403 forbidden signature check

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.

linear webhook sync failed 403 permission error

TL;DR

A 403 means understood but refused, so determine who refused: your own auth middleware blocking Linear's POSTs, or Linear's API rejecting your app's calls on a revoked grant. Loosen the endpoint to verify by signature instead of blocking, or re-authenticate the Linear OAuth app to restore scopes. Replay a test event and confirm a 200.

linear webhook sync failed 403 permission error

Use this when

• Linear webhook deliveries fail with 403
• Your endpoint logs show Linear's requests being rejected
• The integration broke after Linear app permission changes

Not for this skill when

• Webhook signature verification failures (use the signing secret)
• Webhooks never created in the first place (creation issue)
• Linear API 401s on a bad token (authentication, not permission)

Steps

Step 1: Find who returns the 403

Check your endpoint logs and Linear's webhook delivery log to see which side emits the 403. Expected: you know whether your middleware or Linear refused.

Step 2: Fix your endpoint auth

If your middleware blocks Linear's POSTs, exempt the webhook route from bearer checks and authenticate by webhook signature instead. Expected: Linear's requests reach your handler.

Step 3: Check the OAuth grant

If the 403 comes from Linear's API side, verify the OAuth token's scopes and whether the grant was revoked. Expected: you know the grant state and its scopes.

Step 4: Re-authenticate if needed

Re-run the Linear OAuth flow to restore a revoked or under-scoped grant. Expected: API calls succeed with the new token.

Step 5: Replay a test event

Trigger a test webhook and confirm end-to-end delivery. Expected: a 200 response and processed event.

Tool compatibility

Linear webhooks; Linear OAuth apps (scopes and grants); webhook endpoints with signature verification.

Variant phrasings

Variant 1

linear webhook 403 forbidden delivery failed

Variant 2

linear webhook sync failed permission denied

Variant 3

linear api 403 webhook endpoint blocked

Why it happens

The 403 is the most misread status in webhook debugging because both sides can produce it and it looks identical in the delivery log. Your own framework's auth middleware is the usual suspect: it sees an unauthenticated POST from Linear and rejects it before your handler runs, which is correct behavior for your API but wrong for a webhook route. The other suspect is Linear's side: an OAuth grant that lost scopes or was revoked makes your app's API calls 403. The diagnostic step that matters is attribution, which side refused, because the fixes are opposites: open your endpoint vs re-authenticate your grant.

Edge cases / pitfalls

• IP allowlists that do not include Linear's senders produce the same symptom; check the network layer too.
• Linear app permission changes apply to existing grants; a working integration can 403 after an admin trims scopes.
• Log the full request on 403s; the path and headers usually reveal whether it was your middleware.

Provenance

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

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

Thread query: linear webhook sync failed 403 permission error

TL;DR: A 403 means understood but refused, so determine who refused: your own auth middleware blocking Linear's POSTs, or Linear's API rejecting your app's calls on a revoked grant. Loosen the endpoint to verify by signature instead of blocking, or re-authenticate the Linear OAuth app to restore scopes. Replay a test event and confirm a 200.

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: