Support

Where to reach us

Response times

For Enterprise workspaces with a custom SLA, the agreed timing in your contract supersedes the table above.

Common gotchas

A grab-bag of "we've seen this before" — check before mailing support.

Email going to spam

There is nothing to set up in your DNS: no plan has a custom sending domain, and every invitation, reminder and completion email leaves from our own noreply sending address, authenticated on our side. Only the display name changes per workspace. If a recipient's filter still catches it, ask them to allow the sender address the invitation shows. Replies to invitations, reminders and completion emails go to your workspace's reply-to address (Settings → Branding, Branded and up), otherwise to support@wesign.now.

Several near-identical reminders to one inbox look like bulk mail, which is why POST /v1/signing-requests/{id}/remind refuses a second reminder to the same signer within 60 seconds (429 rate_limited) — don't loop on it.

A signature page was appended to a PDF that clearly has anchors

The response says "placement": "auto_append" and anchors.found: 0: we found no markers, so we appended a signature page instead (a PDF without markers is never an error). The marker has to live in the text layer — meaning the PDF was generated from text (HTML→PDF, LaTeX, Word). PDFs that are scanned images don't have a text layer, and a marker wrapped over two lines is not recognised. Workarounds:

• OCR the PDF first (e.g. ocrmypdf), THEN POST it.
• Keep each marker on one line in the source.
• Pass placement="explicit" with hand-coded coordinates.

Tenant subdomain shows "powered by" but no logo

Set the workspace logo_url in Settings → Branding. Until then the landing page falls back to the company's first letter at the same hero scale.

idempotency_in_progress on a request you didn't retry

Two systems used the same Idempotency-Key — most often when an async queue retries a job whose dispatching system already retried it. Check both layers; the deeper one needs a fresh key per delivery.

"Our webhook endpoint receives nothing"

1. Is the hook active? GET /v1/hooks lists active hooks only. A hook missing from it was deleted, switched off in the dashboard (?include_disabled=true lists those), or replaced: a re-POST of the same target_url makes a new hook with a new id and a new secret, and a receiver still verifying with the old secret rejects every delivery. (GET /v1/hooks never lists a document-scoped callback_url hook; the dashboard shows every hook.)
2. What did your endpoint answer? GET /v1/hooks/{id}/deliveries shows each delivery's status, your endpoint's response_status and the first 500 characters of its answer — or our note when no answer came: network: … (timeout or connection error) or redirect not followed: ….
3. Ping it. POST /v1/hooks/{id}/test sends a signed ping at once and returns the outcome.
4. Common causes. A 3xx is a failure: we never follow a redirect, and a trailing slash too many or too few counts. Answer 2xx within 10 seconds and do the work afterwards. A receiver whose signature check fails (the old secret of a replaced hook, a re-serialised body instead of the raw bytes) answers 401 in our snippets, and we retry that like any failure.
5. Then redeliver what gave up: POST /v1/hooks/{id}/deliveries/{delivery_id}/redeliver, or Redeliver in the dashboard.

Details: Webhooks → Retries and Delivery log and redelivery.

"The signer says no SMS code arrived"

• Subscribe to signing_request.sms_failed and .sms_sent (signer events). sms_failed names the reason at once (landline, blocked, allowance_exhausted, …); an sms_sent without a later sms_verified means Twilio accepted the code but the handset may not have received it.
• Wrong number? Correct it with PATCH /v1/signing-requests/{id} and let the signer tap "Send a new code".
• The signer's side — resend, attempts, lifetime, lockout — is on SMS verification.

"Will my documents survive losing my account?"

Most server-written documents are envelope-encrypted at rest (which ones). If you permanently lose access to your account or workspace — deletion, payment lapse beyond the grace period, legal seizure, etc. — encrypted documents stored under that account may become unrecoverable. We can't decrypt them on behalf of an account we can no longer authenticate.

Mitigation: download local copies of documents you care about before any irrecoverable account action, and keep your audit-trail PDFs in your DMS. The full security model + the at-rest encryption specifics live at /docs/security.

A 402 you didn't expect

Four different codes, four different causes — branch on code:

• tier_required — on POST /v1/signing-requests and on template instantiate: the plan's monthly document cap is reached. meta.tier, meta.cap and meta.used spell it out. Enterprise (and legacy Teams) workspaces have no cap by default, so this means the workspace is on a capped plan. A plan change that is still in flight (the payment has not updated the workspace yet) can cause it briefly: wait a minute and retry; if it persists, mail support.
• api_monthly_limit — on POST /v1/signing-requests: the plan's monthly cap on documents created through the API is reached (meta.tier, meta.cap, meta.used). Wait for the next month or upgrade; see api_monthly_limit.
• enterprise-required — the endpoint itself needs Enterprise: instantiate, generate, confirm and minting an embedded signing session. A legacy Teams key gets it there while working everywhere else, reading templates included. GET /v1/me shows it up front as capabilities.templates / capabilities.embedded_signing.
• sms_allowance_exhausted — the signers who must verify by SMS outnumber the codes left this month; see SMS verification.

API keys themselves come with every plan, once developer settings are on (Minting a key); the documents a workspace creates through the API count toward its plan's monthly cap.

Security disclosure

If you've found something exploitable:

• Email security@wesign.now. PGP key on request.
• Include reproduction steps + impact assessment + your timezone.
• We acknowledge within 24 h, ship a fix or mitigation within 7 days for high-severity, 30 days for medium.
• We don't pay bug bounties (yet) but will publicly credit you on a researchers page if you want.

We disclose post-fix in the Changelog and via the status page. Customer notifications go out for any incident with data-handling implications.

Compliance + DPA

• Standard DPA on request.
• Documents stored in the EU by default; CH / UK / US available on every plan (the workspace hosting_region, Settings → Company). Accounts and audit events are in our database in Ireland (EU).
• GDPR Art. 13 disclosure surfaces in the email footer when your workspace address is set.
• ZertES + eIDAS-aligned PAdES seal on every signed document, made with our self-signed seal certificate, and an RFC 3161 time stamp over the sealed file kept with our records; seals made from the seal-certificate change on 2026-10-22 are PAdES baseline B-T, with the time stamp inside the seal. Details: Security → Signature evidence.
• The Certificate of Completion (audit trail) is issued once at completion and stored; its SHA-256 is on document.completed.

Status

Live at www.wesign.now/status: the health of each core service and storage region, refreshed every 30 seconds, and incident summaries. The same checks as JSON: https://www.wesign.now/api/status/check.