Delete a webhook
View as MarkdownAuthorization
bearer In: header
Path Parameters
Response Body
application/json
application/json
application/json
application/json
curl -X DELETE "https://example.com/v1/webhooks/string"Update a webhook
Change the URL or event filter, or toggle active (re-enabling resets the failure count).
Signing session
The recipient's view of the document: metadata, a presigned file URL (final artifact once completed), all fields (own fields flagged "mine"), redacted co-recipients, and whether it is their turn. The first open marks the recipient viewed and fires document.viewed (it is not written to the audit trail). Unauthenticated — the token is the credential. IP rate-limited (60/min). When the recipient has an access code, the session is LOCKED until the X-Access-Code header carries the right code: the response is {locked: true, codeIncorrect, document: {status}, recipient: {name}} — 200 with no code supplied, 401 with a wrong one. The document name is NOT in this payload (nor in the lockedOut one): anyone holding the link can read it, and it only appears once the code is accepted. Once any wrong code has been used the response also carries attemptsRemaining, the tries left before the lockout. After five wrong codes the slot is locked out for a cooldown: 429 with {locked: true, lockedOut: true, retryAfterSeconds, document, recipient, security}, where retryAfterSeconds is how long is left. Repeat lockouts last longer: 15 minutes, then 1 hour, then 24 hours from then on, so retryAfterSeconds can be as large as 86400. A new run of five wrong codes made after a lock has ended starts the next one, and a guess made while locked is refused without lengthening the lock. The count resets after a correct code, or after 7 days with no wrong code. All /public/signing action endpoints then require the same header (401 with {locked: true} otherwise). A recipient can ALSO require verification — a code by text message or voice call, or a Government ID check run by Persona — independent of the access code: both must pass, access code first. The sender only chooses the method; the SIGNER enters their own phone number, or completes Persona's flow. Once the access code is accepted, an unverified session is still LOCKED: 200 with {locked: true, verificationRequired: true, document: {name, status}, recipient: {name, declinedAt}, security}. This GET never sends a text or places a call — the signer starts verification explicitly with POST .../verification/start. Verification is proven by an HttpOnly session cookie set by POST .../verification/verify, not by anything the page reports; send credentials (fetch credentials: "include") on every /public/signing request. Every action endpoint re-checks it server-side (403 verification_required).