privy webhooks enable
Re-enable an endpoint disabled by delivery failures; does not resend past events.
privy webhooks enable [options] <endpoint-id>Arguments
Section titled “Arguments”| Argument | Description |
|---|---|
endpoint-id |
— |
Options
Section titled “Options”| Option | Description |
|---|---|
--dry-run |
Validate and print the API request without network access or credentials. |
--yes |
Confirm this mutation or export. |
--confirm-url <url> |
Confirm the exact current HTTPS receiver URL before deletion or notification actions. |
--body <json> |
JSON body, or - to read stdin. |
--file <path> |
JSON body file, or - to read stdin. |
--allow-production |
Explicitly allow this production mutation; also requires --yes. |
Global options such as --app, --account and --profile also apply. See the command reference overview.
Examples
Section titled “Examples”privy webhooks enable <endpoint-id> --confirm-url https://your-backend.example/webhook --yesBehavior
Section titled “Behavior”- Changes data: yes. Preview with
--dry-run, then run with--yesand any required confirmations. - Scope: app
- Before it runs: Check app environment and endpoint state. Delete/test/resend/enable require exact
--confirm-url. Subscriptions affect all app endpoints. - Production apps: Requires
--allow-productionand--yes. - Verification: List/status read-back for configuration; notification submissions are acknowledgements, not successful delivery.
- Retries: None.
- Caution: Callbacks can disclose user data or repeat receiver business actions. Only use authorized destinations.
Related guides
Section titled “Related guides”Inspect the full contract locally with privy schema webhooks enable.
Privy CLI is an unofficial, community project by Samarth Saxena. Not affiliated with or endorsed by Privy. The Privy name and wordmark belong to Privy. It uses undocumented dashboard APIs that can change.