hookdeck gateway connection upsert --source-webhook-secret "" succeeds. It creates a source configured to verify provider signatures against an empty secret, so it rejects every genuinely signed request while correctly rejecting forged ones. From the outside it looks configured.
How it happens
Not hypothetically. In hookdeck/evals two scenarios ask an agent to receive provider webhooks with verification. Two different models, two different providers, the same failure:
hookdeck gateway source upsert stripe --type STRIPE --webhook-secret "$STRIPE_WEBHOOK_SECRET"
hookdeck gateway connection upsert ... --source-type ELEVENLABS --source-webhook-secret "$ELEVENLABS_WEBHOOK_SECRET"
Both correct commands. Both with the variable unset in that shell: the secret was in the workspace .env, which had been read by application code but never exported. So the flag received "".
The CLI accepted it, the agent reported the integration ready, and the source rejects everything the provider sends. That is the single cause of two of the three failures in our benchmark suite, across two models and two providers, which suggests it is an easy shape to fall into rather than a one-off.
Why it deserves an error rather than documentation
An empty webhook secret has no legitimate use. It cannot verify anything, so there is no configuration it expresses. Every other outcome of this command is either valid or already rejected.
The failure it produces is the worst kind: silent, delayed, and confidence-inspiring. Nothing is wrong at creation time, the dashboard shows a verified source type, and the first symptom is a provider's webhooks quietly failing in production.
"$UNSET_VAR" expanding to empty is one of the most common shell mistakes there is, and the CLI is the last place that can catch it.
Suggested fix
Reject an empty value for --source-webhook-secret (and --webhook-secret) with a message that names the likely cause:
--source-webhook-secret was empty. If you passed a shell variable, check it is exported.
Worth applying the same rule to any other flag whose empty value cannot be meaningful.
hookdeck gateway connection upsert --source-webhook-secret ""succeeds. It creates a source configured to verify provider signatures against an empty secret, so it rejects every genuinely signed request while correctly rejecting forged ones. From the outside it looks configured.How it happens
Not hypothetically. In hookdeck/evals two scenarios ask an agent to receive provider webhooks with verification. Two different models, two different providers, the same failure:
Both correct commands. Both with the variable unset in that shell: the secret was in the workspace
.env, which had been read by application code but never exported. So the flag received"".The CLI accepted it, the agent reported the integration ready, and the source rejects everything the provider sends. That is the single cause of two of the three failures in our benchmark suite, across two models and two providers, which suggests it is an easy shape to fall into rather than a one-off.
Why it deserves an error rather than documentation
An empty webhook secret has no legitimate use. It cannot verify anything, so there is no configuration it expresses. Every other outcome of this command is either valid or already rejected.
The failure it produces is the worst kind: silent, delayed, and confidence-inspiring. Nothing is wrong at creation time, the dashboard shows a verified source type, and the first symptom is a provider's webhooks quietly failing in production.
"$UNSET_VAR"expanding to empty is one of the most common shell mistakes there is, and the CLI is the last place that can catch it.Suggested fix
Reject an empty value for
--source-webhook-secret(and--webhook-secret) with a message that names the likely cause:Worth applying the same rule to any other flag whose empty value cannot be meaningful.