Compare commits

...

269 Commits

Author SHA1 Message Date
copilot-swe-agent[bot] 46d712f4cc Initial plan 2026-02-12 04:07:09 +00:00
David Nguyen 62c609f105 fix: completed audit logs 2026-02-12 15:04:16 +11:00
Copilot 4babe9b192 fix: use rejection audit log for IP/Device fields on rejected certificates (#2479) 2026-02-12 13:01:55 +11:00
David Nguyen 7e422bc3fd fix: highlight rejected certificate text 2026-02-12 12:23:00 +11:00
Catalin Pit f1c91c4951 fix: bulk actions improvements (#2440) 2026-02-10 20:13:03 +11:00
Lucas Smith a5ef1d23e6 feat: add team memberships section to admin user detail page (#2457) 2026-02-09 17:35:22 +11:00
github-actions[bot] d91414697d chore: extract translations (#2429) 2026-02-09 17:30:46 +11:00
Konrad e222a872d2 fix(i18n): rewrite audit log messages to support correct grammar (#2455) 2026-02-09 13:20:12 +11:00
Ephraim Duncan e3b0087be6 feat: create plain customer (#2442)
Co-authored-by: Catalin Pit <catalinpit@gmail.com>
2026-02-09 11:24:45 +11:00
Konrad da89ce7c9a fix(i18n): add localization context to dialog messages (#2452) 2026-02-09 10:52:50 +11:00
Konrad b762561f11 chore(i18n): add context to ambiguous message (#2454) 2026-02-09 10:52:00 +11:00
Catalin Pit 9b190ef582 docs: add info callout for enterprise-only embedded authoring (#2443) 2026-02-04 12:41:46 +11:00
Lucas Smith 1669216a91 fix: flatten pdf-lib form fields before sealing document (#2441)
- Fixes checkbox fields not displaying correctly in sealed documents by
calling `flatten()` on the pdf-lib form before saving
2026-02-03 14:24:23 +11:00
Lucas Smith 594a0f0c3f fix: store formValues in database when creating document from template (#2437) 2026-02-02 11:36:06 +11:00
Konrad 39ebc8184a fix(i18n): add pluralization to envelopes-bulk-delete-dialog.tsx (#2428) 2026-01-30 12:43:27 +11:00
Konrad 2df41b9f01 feat(ui): rename sign up button for better clarity (#2427) 2026-01-30 12:30:33 +11:00
Lucas Smith 8704c731c0 chore: upgrade libpdf (#2435) 2026-01-29 23:34:46 +11:00
Lucas Smith eaee0d4bc6 v2.6.0 2026-01-29 18:44:58 +11:00
Lucas Smith 0f8b7670f4 fix: correct path prefix check for static assets caching (#2433) 2026-01-29 16:05:08 +11:00
Catalin Pit 25e148d459 feat: update team member creation dialog with invite functionality (#2366) 2026-01-29 15:15:06 +11:00
David Nguyen 97ceb317a8 fix: license banner not correctly showing (#2432) 2026-01-29 15:09:23 +11:00
David Nguyen c83109628d fix: add license logging (#2431) 2026-01-29 14:08:36 +11:00
David Nguyen a4d0e3e873 fix: resolve safari cert download issues (#2430) 2026-01-29 14:08:07 +11:00
Catalin Pit 59a514c238 feat: allow non-team members as default recipients (#2404) 2026-01-29 13:32:18 +11:00
David Nguyen 1b0df2d082 feat: add license integration (#2346)
Changes:
- Adds integration for the license server.
- Prevent adding flags that the instance is not allowed to add
2026-01-29 13:30:48 +11:00
Catalin Pit d18dcb4d60 feat: autoplace fields from placeholders (#2111)
This PR introduces automatic detection and placement of fields and
recipients based on PDF placeholders.

The placeholders have the following structure:
- `{{fieldType,recipientPosition,fieldMeta}}` 
- `{{text,r1,required=true,textAlign=right,fontSize=50}}`

When the user uploads a PDF document containing such placeholders, they
get converted automatically to Documenso fields and assigned to
recipients.
2026-01-29 13:13:45 +11:00
Konrad d77f81163b fix(i18n): mark missing strings for translation in card components (#2308) 2026-01-29 12:22:07 +11:00
Lahiru Dahampath 62fb9e5248 fix: correct webhook event name in documentation (#2424) 2026-01-29 11:52:36 +11:00
github-actions[bot] 53b0131740 chore: extract translations (#2418) 2026-01-28 21:25:23 +11:00
Catalin Pit 155310b028 feat: add bulk document selection and move functionality (#2387)
This PR introduces bulk actions for documents, allowing users to select
multiple envelopes and perform actions such as moving or deleting 1 or
more documents simultaneously.
2026-01-28 18:27:32 +11:00
Catalin Pit 28bc2dc975 fix: send organisation member removal email to correct user (#2405) 2026-01-28 09:18:58 +02:00
David Nguyen eb3b3b18ce chore: add v1 deprecated docs (#2423) 2026-01-28 14:09:13 +11:00
misha 8bc4f1a713 fix: exclude soft-deleted documents from folder count (#2410) 2026-01-28 13:07:57 +11:00
Timur Ercan d3c898e317 chore: update fair policy with support (#2422)
updated fair policy and added fair self-host support
2026-01-27 17:34:07 +01:00
Lucas Smith d08049ed3b v2.5.1 2026-01-27 20:25:31 +11:00
Lucas Smith 7a583aa7af fix: preserve prompt parameter in OAuth authorize URL builder (#2421)
The prompt option was being discarded for OAuth authorize URLs after
adding support for the NEXT_PRIVATE_OIDC_PROMPT env var. This meant
select_account (used elsewhere) was not being passed through.

Now defaults prompt to the provided option (or 'login'), and only
overwrites it when a valid OIDC prompt env var is set. Also adds a
type guard to validate the env var value.
2026-01-27 20:25:16 +11:00
David Nguyen b590076d85 fix: allow past due subscriptions (#2420)
Allow plans with past_due subscriptions to continue to use the platform
until the subscription becomes inactive.
2026-01-27 18:45:58 +11:00
Lucas Smith 65e30b88be fix: persist formValues in document creation endpoints (#2419) 2026-01-27 16:21:09 +11:00
Ted Liang 9c6ee88cc4 fix: security CVE-2026-23527 (#2399) 2026-01-27 15:52:34 +11:00
Lucas Smith 6028ad9158 chore: add translations (#2412)
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
2026-01-27 15:44:01 +11:00
Lucas Smith 7fc6f5bb6e fix: make teamId optional in support form validation (#2417)
The contact form accepts teamId as an optional param based on
where the user clicks "Support" from. Previously, when opened
from a non-team context, the null teamId would be parsed to NaN
and fail validation, causing the form to error out. Now the
validation only runs when a teamId is actually provided.
2026-01-27 15:00:53 +11:00
Jorge Ramirez 17b261df1f fix(api): add take parameter to template search query for pagination (#2396)
This PR fixes a bug in the `/api/v2/template` endpoint where the
pagination parameter `perPage` was being ignored. Previously, the
endpoint would return all matching templates regardless of the requested
limit, which could lead to performance issues and incorrect API
behavior.
2026-01-27 15:00:37 +11:00
Lucas Smith c732c85082 chore: add manual dispatch to publish workflow and remove chromium builds (#2415) 2026-01-27 14:15:04 +11:00
Lucas Smith 7d38e18f93 v2.5.0 2026-01-26 15:59:30 +11:00
Lucas Smith 0a3e0b8727 feat: validate signers have signature fields before distribution (#2411)
API users were inadvertently sending documents without signature fields,
causing confusion for recipients and breaking their signing flows.

- Add getRecipientsWithMissingFields helper in recipients.ts
- Add server-side validation in sendDocument to block distribution
- Fix v1 API to return 400 instead of 500 for validation errors
- Consolidate UI signature field checks to use isSignatureFieldType
- Add E2E tests for both v1 and v2 APIs
2026-01-26 15:22:12 +11:00
github-actions[bot] b538580a1e chore: extract translations (#2380) 2026-01-26 12:21:02 +11:00
Lucas Smith 42d6e1cbbd chore: upgrade libpdf (#2409) 2026-01-26 12:20:33 +11:00
Lucas Smith 67da488f63 chore: upgrade libpdf (#2408) 2026-01-23 21:38:48 +11:00
Lucas Smith fd3ebc08ec chore: upgrade libpdf (#2406) 2026-01-22 12:45:20 +11:00
Catalin Pit a7963b385a docs: add default recipients section (#2400) 2026-01-21 09:45:34 +02:00
Lucas Smith 9035240b4d refactor: replace pdf-sign with libpdf/core for PDF operations (#2403)
Migrate from @documenso/pdf-sign and @cantoo/pdf-lib to @libpdf/core
for all PDF manipulation and signing operations. This includes:

- New signing transports for Google Cloud KMS and local certificates
- Consolidated PDF operations using libpdf API
- Added TSA (timestamp authority) helper for digital signatures
- Removed deprecated flatten and insert utilities
- Updated tests to use new PDF library
2026-01-21 15:16:23 +11:00
Ephraim Duncan ed7a0011c7 fix: sync envelope state after direct link changes (#2257) 2026-01-21 14:43:24 +11:00
Ted Liang 158b36a9b7 fix: security CVE-2026-22817 CVE-2026-22818 (#2390) 2026-01-15 18:27:04 +11:00
Lucas Smith fabd69bd62 build: upgrade simplewebauthn packages from v9 to v13 (#2389)
The v9 packages are deprecated. This updates to v13 which includes
breaking API changes: optionsJSON wrapper for auth functions,
renamed properties (authenticator→credential), and base64 encoding
for credential IDs via isoBase64URL helper.
2026-01-15 14:22:37 +11:00
Lucas Smith c976e747e3 fix: dont flatten forms for templates (#2386)
Templates shouldn't have their form flattened until they're
converted to a document.
2026-01-14 12:06:28 +11:00
Lucas Smith 34f512bd55 docs: add OpenCode AI-assisted development guide (#2384)
Adds OpenCode support for AI-assisted development, including custom
commands and skills to help contributors maintain consistency and
streamline common workflows.

#### Changes
- Added "AI-Assisted Development with OpenCode" section to
CONTRIBUTING.md with:
  - Installation instructions and provider configuration
- Documentation for 8 custom commands (/implement, /continue,
/interview, /document, /commit, /create-plan, /create-scratch,
/create-justification)
  - Typical workflow guide
- Clear policy that AI-generated code must be reviewed before submission
- Added .agents/ directory for plans, scratches, and justifications
- Added .opencode/ commands and skills for the agent
- Added helper scripts for creating agent files
2026-01-14 10:10:20 +11:00
Karlo db913e95b6 fix: downgrade pdfjs-dist to version 5.4.296 and update react-pdf to version 10.3.0 (#2383) 2026-01-13 21:01:29 +11:00
Catalin Pit bb3e9583e4 feat: add default recipients for teams and orgs (#2248) 2026-01-13 20:32:00 +11:00
Lucas Smith 5bc73a7471 chore: npm audit fix (#2367) 2026-01-13 16:39:10 +11:00
Lucas Smith 06d7849146 chore: add translations (#2373) 2026-01-13 14:34:26 +11:00
Lucas Smith cef7987a72 feat: add audit logs to document details page (#2379)
- Add collapsible audit logs section with paginated table
- Add View JSON button to inspect raw audit log entries
- Display legacy document ID and recipient roles
- Add admin TRPC endpoint for fetching audit logs
- Add database index on envelopeId for DocumentAuditLog table

<img width="887" height="724" alt="image"
src="https://github.com/user-attachments/assets/aeb904c9-515f-49e1-9f8f-513aef455678"
/>
2026-01-13 14:18:10 +11:00
github-actions[bot] cf6f6bcea0 chore: extract translations (#2363) 2026-01-13 12:49:05 +11:00
Catalin Pit 2f27304750 refactor: simplify field dialog component (#2369) 2026-01-13 12:38:10 +11:00
Konrad 912530ca17 fix: mark document visibility options for translation (#2330) 2026-01-12 10:17:03 +11:00
Konrad a995961c4e fix: mark document auth types for translation (#2331) 2026-01-12 09:28:16 +11:00
Lucas Smith 6b041c23b4 v2.4.0 2026-01-08 15:16:57 +11:00
Ted Liang 7b6e948aa2 refactor: reuse svgToPng function (#2365) 2026-01-08 11:30:45 +11:00
Catalin Pit f6d81b22bd docs: update field coordinates documentation and improve devmode (#2359) 2026-01-06 10:29:21 +02:00
Lucas Smith c861dd2ee2 chore: add translations (#2362) 2026-01-06 15:54:54 +11:00
github-actions[bot] 7eabae4b4b chore: extract translations (#2351) 2026-01-06 15:36:46 +11:00
Lucas Smith ae4272a6b6 fix: remove logo from embedded signing v2 page (#2361) 2026-01-06 15:10:58 +11:00
Dylan Tarre fd672943d1 fix: replace hardcoded #7AC455 with text-documenso-700 token (#2358)
Standardizes navigation link colors by replacing hardcoded `#7AC455` hex
values with the existing `text-documenso-700` design token.
2026-01-06 14:58:45 +11:00
David Nguyen c2ea5e5859 fix: migrate certificate generation (#2251)
Generate certificates and audit logs using Konva instead of browserless.

This should:
- Reduce the changes of generations failing
- Improve sealing speed
2026-01-06 14:26:19 +11:00
Grégoire Bécue c1217c5a58 docs: ensure cert directory exists before generating PKCS12 (#2354) 2026-01-03 11:43:55 +11:00
Ted Liang 27eb2d65d4 feat: upgrade alpine and support chromium path (#2353)
Upgrade alpine to 3.22
Support chromium executable path
2026-01-03 11:31:56 +11:00
Catalin Pit ef407cb0b4 refactor: simplify form validation and enhance recipient handling (#2317) 2026-01-02 13:16:45 +11:00
Lucas Smith 1e20561e91 v2.3.2 2025-12-24 16:20:23 +11:00
Lucas Smith a2ec5f0fa1 fix: cleanup konva stages during field insertion (#2347) 2025-12-24 16:09:09 +11:00
Ted Liang de8d13a4c1 fix: hide branding logo in audit log (#2342) 2025-12-24 15:10:13 +11:00
github-actions[bot] 495d61a11d chore: extract translations (#2327) 2025-12-24 13:51:40 +11:00
Catalin Pit 90fdba8000 feat: get many endpoints (#2226)
Co-authored-by: Lucas Smith <me@lucasjamessmith.me>
2025-12-24 11:02:02 +11:00
Ephraim Duncan aa1cada79b feat: add find envelopes endpoint (#2244) 2025-12-23 22:51:51 +11:00
Lucas Smith 790b385849 chore: add bundled chromium docker container (#2344)
We use playwright + chromium for certificate generation
and other things.

Self-hosters often have an issue with generating certificates
due to the base image not coming with chromium for size purposes.

This adds a new `-chromium` tag to our docker images for downloading
the larger bundled chromium containers.
2025-12-23 22:09:12 +11:00
Catalin Pit baa2c51123 feat: add delegate document ownership option (#2272)
When using an API key created in a team context, the
documents/templates’ owner always defaults to the team API token
creator, rather than the actual uploader.

For example, John creates the API key for the team "Lawyers". Tom and
Maria use the API key to upload documents. All the uploaded documents
are attributed to John.

This makes it impossible to see who actually uploaded a document.

The new feature allows users to enable document ownership delegation
from the organization/team settings.
2025-12-23 22:08:54 +11:00
Catalin Pit 1e585e06e6 docs: update documentation (#2339) 2025-12-22 15:07:28 +02:00
Ted Liang 5624484631 fix: security CVE-2025-68130 (#2343)
## Description

Fix security
[CVE-2025-68130](https://github.com/advisories/GHSA-43p4-m455-4f4j)
2025-12-22 21:53:49 +11:00
Catalin Pit 810e00da03 feat: add new features to the FEATURES list (#2338) 2025-12-19 10:38:56 +11:00
Lucas Smith eeeee2fa0e v2.3.1 2025-12-18 12:02:04 +11:00
Lucas Smith c50a31a503 fix: use cpu for field rendering (#2337) 2025-12-18 10:48:46 +11:00
Lucas Smith 7360709795 fix: use gemimi 3 flash preview (#2336) 2025-12-18 10:48:16 +11:00
Lucas Smith df678d7d69 v2.3.0 2025-12-17 22:10:47 +11:00
Lucas Smith 6739242554 fix: use cpu for skia-canvas rendering (#2334)
Seems there's a memory leak in gpu rendering with skia canvas
where contexts can live for much longer than expected escaping gc
cleanup

CPU rendering seems better albeit a bit slower.

Synthetic tests were ran with `--expose-gc` to simulate load over time.
2025-12-17 14:48:21 +11:00
Konrad a5e5eecf8b fix: mark links for translation (#2333) 2025-12-17 12:02:12 +11:00
Lucas Smith b0248c20eb v2.2.8 2025-12-16 16:04:07 +11:00
Lucas Smith f129968968 fix: ensure PDF form appearance streams have required /Subtype /Form entry (#2328)
When flattening PDF forms, some appearance streams lack the required
/Subtype /Form dictionary entry needed when used as XObjects. This
causes
corruption in Adobe Reader which fails to render these flattened fields.

Per PDF spec, Form XObject streams require:
- /Subtype /Form (required)
- /FormType 1 (optional)

The normalizeAppearanceStream function ensures these entries exist
before
adding appearance streams as XObjects to the page content stream.

Fixes rendering issues where flattened fields don't display in PDF
viewers.
2025-12-16 16:00:11 +11:00
Lucas Smith c5c87e3fd1 v2.2.7 2025-12-16 12:38:53 +11:00
Lucas Smith 24a74c7b57 chore: add translations (#2321)
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
2025-12-16 12:06:58 +11:00
Lucas Smith f0a5a7e816 feat: prefill typed signature with user's full name (#2324)
Add fullName prop to signature pad components to automatically populate
typed signature
field with signer's name. Updates signature dialog, type component, and
all signing forms
across embed, document, template, and envelope flows to pass through the
user's full
name for better user experience.
2025-12-16 12:06:04 +11:00
Catalin Pit 8462cd13fd fix: assignment operator for directRecipientName (#2323) 2025-12-16 12:04:19 +11:00
Lucas Smith 576846de32 fix: fallback for certficate sent date when using link distribution (#2316) 2025-12-16 11:40:16 +11:00
Lucas Smith 06071ea035 fix: memory leak in PDF to images conversion (#2325)
Add proper cleanup for PDF.js pages and loading task to prevent memory
leaks when
processing multiple PDF pages. Ensure page cleanup is called after each
page is
rendered and both PDF document and loading task are properly destroyed
with error
handling.
2025-12-16 11:34:30 +11:00
dzhou777 b45a2691ba fix: Unhide text field scrollbar (#2277) 2025-12-15 15:52:39 +11:00
Ted Liang f31cc575d0 fix: white-label for next-button, progress-bar, and steps (#2319) 2025-12-15 15:51:11 +11:00
github-actions[bot] 05d7015ef0 chore: extract translations (#2320) 2025-12-15 13:06:08 +11:00
Chenyang Gao 2ca5d6cfaa fix: local job retry loop for webhook calls (#2295) 2025-12-15 13:04:35 +11:00
Ryan Wagoner 04814ca14e fix: on error job should resubmit with isRetry (#2072) 2025-12-15 13:03:04 +11:00
Ryan Wagoner dd1dccdb6a fix: organisation invite member should be case insensitive (#2068) 2025-12-15 12:50:27 +11:00
Valentin Cocaud df4316ac5c fix: log unknown errors in the auth error handler (#2014) 2025-12-15 12:44:03 +11:00
Catalin Pit 02f1264eea feat: unlink documents from deleted organization (#2006) 2025-12-15 12:17:13 +11:00
github-actions[bot] 928edb8645 chore: extract translations (#2302) 2025-12-15 12:11:55 +11:00
Konrad 54b0e4964e chore(i18n): improve punctuation (#2307) 2025-12-15 12:00:51 +11:00
Konrad 68e6ccdd19 fix(i18n): mark sr-only strings for translation (#2309) 2025-12-15 11:51:02 +11:00
Konrad 09ab7e9a09 fix(i18n): mark "(Optional)" strings for translation (#2310) 2025-12-15 11:50:06 +11:00
Konrad 3bb0777914 fix(i18n): mark field content for translation (#2306) 2025-12-15 11:49:23 +11:00
Catalin Pit 4d6389e901 fix(api): replace generic errors with AppError in getApiTokenByToken (#2315) 2025-12-15 11:47:38 +11:00
Vincent Vu 51e3d5030d fix(security): CVE-2025-55184, CVE-2025-55183 (#2314) 2025-12-12 16:50:00 +11:00
David Nguyen 0cebdec637 fix: remove legacy envelope uploads (#2303) 2025-12-11 14:09:38 +11:00
Lucas Smith 43486d8448 v2.2.6 2025-12-09 21:11:01 +11:00
Lucas Smith 4d3d1b8d14 fix: make ai features more discoverable (#2305)
Previously you had to have explicit knowledge of the
feature and enable it in order to use AI assisted field
detection.

This surfaces it by having a secondary dialog prompting
for enablement.

Also includes a fix for CC recipients not getting marked
as signed in weird edge cases.
2025-12-09 15:30:48 +11:00
David Nguyen 0387f3c20a chore: add missing dropdown image (#2304)
## Description

Add missing dropdown image in the docs.
2025-12-09 12:37:45 +11:00
Ted Liang c5032d0c43 refactor: extract image-helpers (#2261) 2025-12-09 09:19:49 +11:00
Konrad 3bd34964cd fix(i18n): add pluralization to ai features (#2301) 2025-12-09 09:18:38 +11:00
Dailson Allves fe93b11a2c chore: update existing pt-BR translations after commit #2289 (#2300) 2025-12-09 09:17:22 +11:00
github-actions[bot] 7638faf27b chore: extract translations (#2289)
Automated translation extraction

Co-authored-by: github-actions <github-actions@documenso.com>
2025-12-08 19:20:21 +11:00
Ephraim Duncan 8fca029d96 fix: invalidate sessions on password reset and update (#2076) 2025-12-08 19:17:23 +11:00
Lucas Smith bac2bf11f4 v2.2.5 2025-12-08 14:33:00 +11:00
Lucas Smith d93b2a70a7 fix: upgrade react-email/render (#2297)
Upgrade the `@react-email/render` package to handle
suspense during renders.

We could have just swapped to `renderAsync` for the 0.0.x
version of the package but it's better to upgrade as part
of this change.

CI has been run locally and emails have been verified to
work and render as expected in our local mail trap.
2025-12-08 13:08:34 +11:00
Lucas Smith 5da915da38 fix: update server only urls to use private internal web app url (#2290)
Replaced instances of NEXT_PUBLIC_WEBAPP_URL with
NEXT_PRIVATE_INTERNAL_WEBAPP_URL
2025-12-08 12:56:41 +11:00
Ted Liang dcaecf1fc5 feat: resource restriction in presign token (#2150) 2025-12-08 12:55:54 +11:00
Ephraim Duncan f70b76d8b8 feat: add envelope audit logs endpoint (#2232) 2025-12-08 12:34:03 +11:00
David Nguyen 93137c6396 fix: translation extraction job (#2288)
## Description

Workaround until we can commit directly to main for translation
extractions

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2025-12-06 16:19:35 +11:00
Catalin Pit d058b7c705 feat: include CC role in removed recipient email check (#2285) 2025-12-06 14:20:25 +11:00
David Nguyen b51f562224 feat: add empty emails for envelopes (#2267) 2025-12-06 13:38:10 +11:00
David Nguyen f80aa4bf72 chore: optimize tests (#2280) 2025-12-06 12:59:53 +11:00
Lucas Smith 9238f759a6 v2.2.4 2025-12-05 12:23:23 +11:00
Lucas Smith 74ad6af47d chore: add docs for ai features (#2284)
Adds documentation for the recently added AI features

Includes details for how users can enable AI features for their team or
organisation

Also includes details for how self-hosters can setup their instance to
allow for AI features
2025-12-05 11:47:53 +11:00
Lucas Smith 18902ed59d fix: export loader for personal document preferences (#2283) 2025-12-05 11:22:29 +11:00
Lucas Smith 3f70082146 v2.2.3 2025-12-05 09:53:40 +11:00
Lucas Smith 31ba6d5f00 fix: polyfill promise.withResolvers (#2282)
Co-authored-by: Catalin Pit <catalinpit@gmail.com>
2025-12-04 23:33:31 +11:00
Lucas Smith c4f89a87a2 fix: use skia-canvas with pdfjs to avoid N-API errors (#2281)
Use custom CanvasFactory for pdfjs so we can continue to use
skia-canvas.
2025-12-04 23:26:08 +11:00
Ted Liang 89d6dd5b0e fix: embed authoring permission issue (#2279) 2025-12-04 15:02:50 +11:00
Lucas Smith 08a9ab3aaf v2.2.2 2025-12-04 14:50:09 +11:00
Lucas Smith e66bd422e3 chore: upgrade dependencies (#2278) 2025-12-04 14:31:30 +11:00
Lucas Smith 0f5814ff89 chore: add translations (#2259) 2025-12-04 14:01:35 +11:00
Konrad 1275a15571 fix(i18n): mark missing toast messages for translation (#2274) 2025-12-04 14:00:25 +11:00
Lucas Smith 22d99c7410 v2.2.1 2025-12-04 11:39:19 +11:00
Lucas Smith 26a36487d4 fix: pass canvas context to napi-rs/canvas (#2276) 2025-12-04 11:19:44 +11:00
Lucas Smith 2ee6b90c99 fix: add debug logging for ai streaming (#2275) 2025-12-04 10:03:29 +11:00
Lucas Smith f70e6ac50a v2.2.0 2025-12-04 00:31:11 +11:00
Lucas Smith 7a94ee3b83 feat: add ai detection for recipients and fields (#2271)
Use Gemini to handle detection of recipients and fields within
documents.

Opt in using organisation or team settings.

Replaces #2128 since the branch was cursed and would include
dependencies that weren't even in the lock file.



https://github.com/user-attachments/assets/e6cbb58f-62b9-4079-a9ae-7af5c4f2e4ec
2025-12-03 23:39:41 +11:00
Filbert Wijaya e39924714a fix: invalid email display bug when recipient suggestions on select (#2198) 2025-12-03 12:10:38 +11:00
Konrad c9604fee64 chore(i18n): change recipient invitation messages (#2172) 2025-12-03 11:55:53 +11:00
Konrad 90f8340af4 fix(i18n): add pluralization to envelope items (#2183) 2025-12-03 11:30:43 +11:00
Eesh Midha 28b8d2d415 fix: disable browser autocomplete in typed signature input (#2269) 2025-12-03 11:22:35 +11:00
Timur Ercan 978a2047d4 chore: update readme 2025-12-03 11:20:15 +11:00
Catalin Pit 0dfa953f54 feat: add external ID to use template (#2264) 2025-12-02 18:53:42 +11:00
David Nguyen 4774324e07 fix: prevent client side distribution when missing signatures (#2260) 2025-12-02 11:29:48 +11:00
David Nguyen bc19699a58 feat: add dutch language (#2255) 2025-12-02 11:28:04 +11:00
Harishraju04 55480826de docs: add missing translate:compile step to setup guid 2025-12-01 12:05:51 +11:00
Konrad 327b0eaf86 fix(i18n): add pluralization to pagination (#2217) 2025-12-01 11:38:57 +11:00
Konrad 2de5c1992f chore(i18n): add message context to subscription status (#2220) 2025-12-01 11:34:43 +11:00
Konrad df0c03816e chore(i18n): add message context for "Free" and "Paid" (#2222) 2025-12-01 11:30:07 +11:00
Konrad a610a06372 fix(i18n): mark table headers for translation (#2174) 2025-12-01 11:20:18 +11:00
Konrad d5e085d7ee fix(i18n): mark document visibility strings for translation (#2263) 2025-12-01 11:02:55 +11:00
Timur Ercan c322356654 chore: remove cummulative mau (#2250) 2025-11-28 18:07:30 +11:00
Lucas Smith b16862b480 chore: update embed authoring docs (#2254) 2025-11-27 23:29:06 +11:00
Lucas Smith 7065b0dd88 chore: add translations (#2253)
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
2025-11-27 21:36:48 +11:00
Lucas Smith dff9cfec05 chore: add translations (#2228) 2025-11-27 16:40:18 +11:00
David Nguyen d84cf0e58d chore: extract translations (#2252) 2025-11-27 16:04:22 +11:00
Ephraim Duncan 5d8b147199 fix: delay field tooltip scroll on envelope item switch (#2246) 2025-11-27 13:37:33 +11:00
Filbert Wijaya 7d28295d42 build: remove unsupported auto-install-peers from .npmrc (#2199) 2025-11-27 13:35:23 +11:00
Ephraim Duncan 94646cd48a perf: add database indexes for insights queries (#2211) 2025-11-26 21:21:01 +11:00
Ephraim Duncan 14db9b8203 feat: add navigation links between admin org pages (#2243) 2025-11-26 15:15:29 +11:00
Lucas Smith 6ae672c16b v2.1.0 2025-11-25 16:38:06 +11:00
Lucas Smith e9a9d65937 chore: telemetry (#2241) 2025-11-25 16:35:26 +11:00
David Nguyen d857dfdb38 feat: add webhook logs (#2237) 2025-11-25 16:03:52 +11:00
Lucas Smith 11a56f3228 chore: telemetry (#2240) 2025-11-25 16:01:31 +11:00
Lucas Smith 91642ddf0b fix: add missing properties for template/use (#2234)
Adds the `override` and `attachments` properties to the
`api/v2/templates/use` endpoint that were previously missing.
2025-11-25 11:44:47 +11:00
David Nguyen e364b08b6a fix: optimize webhook routing (#2236) 2025-11-25 11:43:23 +11:00
Catalin Pit 5df3932958 fix: update branding logic (#2238)
Update branding logic to ensure company details are displayed only when
branding is enabled
2025-11-24 21:45:31 +11:00
Lucas Smith ae31860b16 fix: USE_INTERNAL_URL_BROWSERLESS breaks builds (#2233) 2025-11-23 23:49:08 +11:00
Timur Ercan 16ee6b7a6d fix: give the possibility to use internal webapp url in browserless requests (get-certificate-pdf and get-audit-logs-pdf) (#2127) (#2230) 2025-11-22 20:49:34 +11:00
Matteo Sillitti 921c3d1ff3 fix: give the possibility to use internal webapp url in browserless requests (get-certificate-pdf and get-audit-logs-pdf) (#2127) 2025-11-22 20:36:24 +11:00
Ephraim Duncan 2d7a4d0dde docs: add missing environment variables to self-hosting guide (#2225) 2025-11-22 20:28:51 +11:00
Lucas Smith d2176627ca chore: dependency updates (#2229) 2025-11-22 20:28:20 +11:00
Lucas Smith 17c6098638 v2.0.14 2025-11-20 15:12:40 +11:00
Lucas Smith e5bde53ee4 chore: add translations (#2223) 2025-11-20 15:09:13 +11:00
Lucas Smith 0663605ffd fix: handle loading files in embedded authoring update flows (#2218) 2025-11-20 15:07:41 +11:00
Lucas Smith 1bbe561162 chore: add pending ui to signing completion page (#2224)
Adds a pending UI state to the signing completion page for when all
recipients have finished signing but the document hasn't completed the
sealing background job.

<img width="695" height="562" alt="image"
src="https://github.com/user-attachments/assets/b015bc38-9489-4baa-ac0a-07cb1ac24b25"
/>
2025-11-20 15:07:26 +11:00
Dailson Allves fbc156722a feat: add Portuguese (Brazil) translation support version 2.0.6 (#2165)
Portuguese (Brazil) Translation Support for Documenso
2025-11-20 14:14:47 +11:00
Karlo f5d63fb76c feat: add option to change or disable OIDC login prompt parameter (#2037) 2025-11-20 13:08:36 +11:00
Catalin Pit 374477e692 refactor: improve layout of completed signing page (#2209) 2025-11-20 11:04:41 +11:00
David Nguyen 11d9bde8f8 fix: improve sealing speed (#2210) 2025-11-19 14:15:12 +11:00
Lucas Smith fa1680aaf1 v2.0.13 2025-11-18 16:59:02 +11:00
David Nguyen 798b6bd750 feat: add japanese chinese and korean support (#2202)
## Description

Adds the following languages since we updated our PDF sealing to support
special characters
- Japanese
- Korean
- Chinese (Simplified)

## Tests

Ran through the signing process in these new languages.
2025-11-18 16:57:38 +11:00
Lucas Smith 8fbace0f61 fix: viewed webhook had stale data (#2208) 2025-11-18 16:57:14 +11:00
David Nguyen 1bbd04be9b feat: add field dev mode (#2203) 2025-11-18 16:57:06 +11:00
Lucas Smith 6aa56fe7e0 chore: add translations (#2182) 2025-11-17 15:48:02 +11:00
Lucas Smith a07f3090cf v2.0.12 2025-11-15 00:48:27 +11:00
Lucas Smith de3e6d2115 fix: embed editing updates (#2197)
Allows empty recipients for embed template authoring.

Also allows fixing the step to editing fields only for embedded
authoring updates.
2025-11-15 00:47:50 +11:00
David Nguyen dabd2564cd feat: add ability to change field recipient (#2194)
## Description

Add ability to change recipients for a given field.

<img width="336" height="224" alt="image"
src="https://github.com/user-attachments/assets/c122672d-68ab-4652-9c76-1a1bc874c16a"
/>

<img width="716" height="465" alt="image"
src="https://github.com/user-attachments/assets/a8e8636c-c780-4d56-910b-5522161b12d3"
/>
2025-11-15 00:46:33 +11:00
Tanushree Ahir 5811716d12 fix(email): preserve word wrap and line breaks in email body (#2139) (#2159) 2025-11-14 15:12:36 +11:00
David Nguyen 56526f9448 feat: extend use envelope response (#2192) 2025-11-14 13:52:19 +11:00
Lucas Smith 6ec1c3a3fb fix: hide overflow on envelope download dialog (#2193) 2025-11-14 13:17:55 +11:00
Timur Ercan 47466a2db9 chore: Update README.md (#2188)
We are launching Documenso 2.0 on Product Hunt, come say hi!
2025-11-13 20:52:34 +11:00
Ephraim Duncan e4e04cdddc feat: simplify billing ux (#2117) 2025-11-13 15:58:16 +11:00
samuel-cglg 74a03077b7 fix: placeholders translations (#2020) 2025-11-13 14:26:19 +11:00
samuel-cglg 58bff33275 fix: add context to signature pad translations (#2051) 2025-11-13 13:35:23 +11:00
Konrad 0cb23be27a chore: add question mark to message (#2176) 2025-11-13 12:08:39 +11:00
David Nguyen 4304fc1d35 chore: add envelope docs (#2186) 2025-11-13 11:50:06 +11:00
Lucas Smith ce53bcea8c v2.0.11 2025-11-13 10:56:58 +11:00
Lucas Smith 5a3d5b8b4a fix: persist missed meta values for envelopes (#2185) 2025-11-13 10:44:59 +11:00
Lucas Smith 3d1fe85d62 fix: add foreign key indexes (#2184)
Can't believe we missed some of these ☠️
2025-11-13 10:43:11 +11:00
Lucas Smith 1772c3ee36 v2.0.10 2025-11-12 18:57:24 +11:00
Lucas Smith f55b902a01 fix: openapi path for envelope item download 2025-11-12 18:57:03 +11:00
Lucas Smith 50db4e39be v2.0.9 2025-11-12 18:22:46 +11:00
David Nguyen 2802813c76 fix: add default values for envelope field meta (#2181)
🙏
2025-11-12 18:22:30 +11:00
Lucas Smith 29d40f1cca v2.0.8 2025-11-12 17:19:53 +11:00
Lucas Smith d67f32eae2 chore: add translations (#2166)
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
2025-11-12 17:17:44 +11:00
David Nguyen a33233443b chore: extract translations (#2179) 2025-11-12 17:09:50 +11:00
Lucas Smith 68a3608aee fix: handle bracket notation arrays (#2178)
Co-authored-by: David Nguyen <davidngu28@gmail.com>
2025-11-12 16:38:06 +11:00
Lucas Smith 378dd605b9 v2.0.7 2025-11-12 13:09:18 +11:00
Lucas Smith 211ae6c9e9 fix: prefill arcoforms with formdata endpoints (#2169) 2025-11-12 12:41:10 +11:00
David Nguyen f931885a95 fix: remove redundant endpoint (#2170)
Remove duplicate redundant endpoint
2025-11-12 11:01:15 +11:00
Lucas Smith 4ade408001 fix: include cmaps for pdf viewer (#2177)
We were previously omitting cmaps meaning that
when signing documents with certain UTF-8 characters or CJK characters
they would appear as outlined squares in the pdf viewer despite the
actual pdf looking as expected with the characters displaying correctly.
2025-11-12 11:00:44 +11:00
David Nguyen 3d0e3c6e8e fix: update dropzone to create envelopes (#2168) 2025-11-11 20:49:42 +11:00
David Nguyen 936d8d90b3 fix: envelope auth not being passed (#2167) 2025-11-11 13:05:05 +11:00
Ephraim Duncan c6b08d8594 feat: org insights (#1937) 2025-11-11 12:09:58 +11:00
Konrad 575634e326 fix: add pluralization to document details (#2130) 2025-11-11 10:54:12 +11:00
Konrad c66eda4aae chore: add message context in user organisation table (#2138) 2025-11-11 10:44:20 +11:00
Konrad ef52b35f79 chore: change message in dropzone wrappers (#2137) 2025-11-11 10:43:22 +11:00
Konrad 95a647034a chore: add message context in envelope download dialog (#2136) 2025-11-11 10:42:30 +11:00
Konrad 34dba0b6ff chore: fix message formatting (#2135) 2025-11-11 10:41:54 +11:00
Konrad fccd97e124 fix: add pluralization to 2fa code template (#2131) 2025-11-11 10:39:05 +11:00
Konrad 3dbbcefddf fix: add pluralization to passkey page (#2129) 2025-11-11 10:37:54 +11:00
David Nguyen 2aea3c4de0 fix: rename envelope buttons (#2161) 2025-11-10 22:21:34 +11:00
Lucas Smith ff44ffbc03 v2.0.6 2025-11-10 19:08:43 +11:00
Lucas Smith 441842d2bd fix: use correct token for embeded template files (#2160) 2025-11-10 19:08:08 +11:00
David Nguyen ca0b83579f fix: auto insert prefilled text and number fields (#2157) 2025-11-10 18:04:21 +11:00
Eesh Midha 6c0d1da91e fix(input): prevent mobile zoom on input focus (#2079) 2025-11-10 12:43:06 +11:00
David Nguyen 805982f3e8 fix: envelope cc issues (#2158) 2025-11-10 11:42:57 +11:00
David Nguyen e2f5e570cf fix: envelope direct template (#2156) 2025-11-09 22:23:13 +11:00
David Nguyen 9fd9613076 feat: add additional field options (#2154) 2025-11-08 23:40:03 +11:00
Lucas Smith 0977c16e33 v2.0.5 2025-11-08 16:03:59 +11:00
Lucas Smith 88d5a636c3 fix: show legacy ids on template and document view page (#2153)
<img width="557" height="455" alt="image"
src="https://github.com/user-attachments/assets/7b669f4a-c6c5-4fdc-bf10-da0def7b0b3f"
/>
2025-11-08 16:03:26 +11:00
Lucas Smith 1e6292b1d9 v2.0.4 2025-11-08 13:58:11 +11:00
Lucas Smith d65866156d fix: remove parallel steps (#2152) 2025-11-08 13:57:26 +11:00
Lucas Smith fe8915162f v2.0.3 2025-11-08 12:53:50 +11:00
Lucas Smith 37a2634aca feat: support optimizeParallelism for inngest jobs (#2151) 2025-11-08 12:53:13 +11:00
Lucas Smith eff7d90f43 v2.0.2 2025-11-08 00:48:31 +11:00
Lucas Smith db5524f8ce fix: resolve issue with sealing task on inngest (#2146)
Currently on inngest the sealing task fails during decoration stating
that it can not find the step "xxx"

My running theory is that this was due to it being a
Promise.all(map(...)) even though that isn't explicitly disallowed.

This change turns it into a for loop collecting promises to be awaited
after the fact.

Local inngest testing looks promising.
2025-11-08 00:48:13 +11:00
Lucas Smith 3d539b20ad v2.0.1 2025-11-07 23:42:03 +11:00
Lucas Smith 48626b9169 fix: support utf8 filenames download (#2145) 2025-11-07 23:41:31 +11:00
David Nguyen 88371b665a fix: set correct envelope item cache url (#2144) 2025-11-07 16:50:58 +11:00
Lucas Smith 1650c55b19 v2.0.0 2025-11-07 15:40:24 +11:00
Lucas Smith 60d73e0921 chore: add translations (#2143)
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
2025-11-07 14:45:21 +11:00
Lucas Smith 4a779ec81e fix: handle custom org limits with member invite 2025-11-07 14:24:05 +11:00
Lucas Smith 7f19ec1265 fix: embedded direct template recipient auth 2025-11-07 14:23:46 +11:00
Lucas Smith d6a2f5a4c9 chore: extract translations (#2070) 2025-11-07 14:20:53 +11:00
David Nguyen d05bfa9fed feat: add envelopes api (#2105) 2025-11-07 14:17:52 +11:00
David Nguyen d2a009d52e fix: allow direct template recipient dictation (#2108) 2025-11-01 12:44:34 +11:00
Lucas Smith 9350c53c7d chore: add code styleguide (#2089)
Co-authored-by: Ephraim Atta-Duncan <ephraimduncan68@gmail.com>
2025-10-28 22:25:27 +11:00
Ephraim Duncan ffce7a2c81 fix: filter document stats by folder (#2083)
This pull request refactors the filtering logic in the `getTeamCounts`
function within `get-stats.ts` to improve consistency and
maintainability. The main change is the consolidation of multiple filter
conditions into a single `AND` clause, which now includes search
filters, folder filters, and visibility filters. This ensures that all
relevant filters are applied in a unified way for document count
queries.
2025-10-28 21:16:12 +11:00
Ephraim Duncan 353bdce86b feat: admin member role updates (#2093) 2025-10-28 21:09:38 +11:00
David Nguyen e13b9f7c84 fix: hide banner for envelope editor (#2109) 2025-10-28 16:55:44 +11:00
David Nguyen 9908580bf1 fix: add envelopes flag (#2104)
## Description

Add a global flag override for envelopes
2025-10-28 11:42:03 +11:00
David Nguyen b0b07106b4 fix: envelope autosave (#2103) 2025-10-27 19:53:35 +11:00
Ephraim Duncan 35250fa308 feat: server port configurable via PORT env (#2097) 2025-10-27 17:24:24 +11:00
David Nguyen 5cdd7f8623 fix: envelope styling (#2102) 2025-10-27 16:11:10 +11:00
989 changed files with 130733 additions and 102100 deletions
View File
View File
@@ -0,0 +1,161 @@
---
date: 2026-01-28
title: Pdf Placeholder Field Positioning
---
## Overview
This feature enables automatic field placement in PDFs using placeholder text, eliminating the need for manual coordinate-based positioning. It supports two complementary workflows:
1. **Automatic detection on upload** - PDFs containing structured placeholders like `{{signature, r1}}` have fields created automatically when uploaded
2. **API placeholder positioning** - Developers can reference any text in a PDF to position fields instead of calculating coordinates
## Goals
- Allow users to prepare documents in Word/Google Docs with placeholders that become signature fields
- Reduce friction for document preparation workflows
- Provide API developers with a simpler alternative to coordinate-based field positioning
- Support documents with repeated placeholders (e.g., initials on every page)
## Placeholder Format (Automatic Detection)
```
{{FIELD_TYPE, RECIPIENT, option1=value1, option2=value2}}
```
### Components
- **FIELD_TYPE** (required): One of `signature`, `initials`, `name`, `email`, `date`, `text`, `number`, `radio`, `checkbox`, `dropdown`
- **RECIPIENT** (required): `r1`, `r2`, `r3`, etc. - identifies which recipient the field belongs to
- **OPTIONS** (optional): Key-value pairs like `required=true`, `fontSize=14`, `readOnly=true`
### Examples
- `{{signature, r1}}` - Signature field for first recipient
- `{{text, r1, required=true, label=Company Name}}` - Required text field with label
- `{{number, r2, minValue=0, maxValue=100}}` - Number field with validation
### Behavior
- Placeholders without recipient identifiers (e.g., `{{signature}}`) are skipped during automatic detection - reserved for API use
- Invalid field types are silently skipped
- Placeholder text is covered with white rectangles after field creation
## API Placeholder Positioning
The `/api/v2/envelope/field/create-many` endpoint accepts `placeholder` as an alternative to coordinates:
```json
{
"recipientId": 123,
"type": "SIGNATURE",
"placeholder": "{{signature}}"
}
```
### Parameters
| Parameter | Type | Description |
| ------------- | ------- | -------------------------------------------- |
| `placeholder` | string | Text to search for in the PDF |
| `width` | number | Optional override (percentage) |
| `height` | number | Optional override (percentage) |
| `matchAll` | boolean | When true, creates fields at ALL occurrences |
### matchAll Behavior
- Default (`false`): Only first occurrence gets a field
- `true`: Creates a field at every occurrence of the placeholder text
This is useful for documents requiring initials on every page.
## Implementation Components
### Core Functions
- `extractPlaceholdersFromPDF()` - Scans PDF for `{{...}}` patterns with recipient identifiers
- `removePlaceholdersFromPDF()` - Covers placeholder text with white rectangles
- `whiteoutRegions()` - Low-level helper for drawing white boxes on PDF pages
- `parseFieldTypeFromPlaceholder()` - Converts placeholder field type to FieldType enum
- `parseFieldMetaFromPlaceholder()` - Parses options into fieldMeta format
### Integration Points
1. **Upload flow** (`create-envelope.ts`, `create-envelope-items.ts`)
- Extract placeholders at upload time (before saving to storage)
- Pass placeholders in-memory to envelope creation
- Create placeholder recipients if none provided
- Create fields within the same transaction
2. **API field creation** (`create-envelope-fields.ts`)
- Accept `placeholder` as alternative to coordinates
- Search PDF for placeholder text
- Resolve position from bounding box
- Support `matchAll` for multiple occurrences
### Field Meta Parsing
The following properties are explicitly parsed:
- `required`, `readOnly` → boolean
- `fontSize`, `minValue`, `maxValue`, `characterLimit` → number
- Other properties pass through as strings
Note: Signature fields do not support fieldMeta options.
## Testing
### E2E Tests
**UI Tests** (`e2e/auto-placing-fields/`):
- Single recipient placeholder detection
- Multiple recipient placeholder detection
- Field configuration from placeholder options
- Skipping placeholders without recipient identifiers
- Skipping invalid field types
**API Tests** (`e2e/api/v2/placeholder-fields-api.spec.ts`):
- Placeholder-based field positioning
- Width/height overrides
- Error on placeholder not found
- Mixed coordinate and placeholder positioning
- First occurrence only (default)
- All occurrences with `matchAll: true`
## Documentation
### User Documentation
`/users/documents/pdf-placeholders` - Explains:
- Placeholder format and syntax
- Supported field types
- Recipient identifiers
- Available options per field type
- Troubleshooting
### Developer Documentation
`/developers/public-api/reference` - Documents:
- Coordinate-based positioning (existing)
- Placeholder-based positioning (new)
- matchAll parameter
- Mixing both methods
## Edge Cases Handled
1. **No placeholders found** - Original PDF returned unchanged
2. **Placeholder not found (API)** - Returns error with placeholder text
3. **Multiple occurrences** - First only by default, all with `matchAll: true`
4. **No recipient identifier** - Skipped during auto-detection, works for API
5. **Invalid field type** - Skipped during auto-detection
6. **Signature field with options** - Options ignored (signature doesn't support fieldMeta)
## Future Considerations
- Support for placeholder text styles (bold, underline) to indicate field properties
- Template-level placeholder mapping for reusable configurations
- Placeholder validation in document editor before sending
@@ -0,0 +1,76 @@
---
date: 2026-01-26
title: Validate Signer Fields On Distribute
---
## Summary
Validate that signers have at least one signature field before allowing document/envelope distribution via API, matching the existing UI behavior.
## Background
The API originally allowed distributing documents/envelopes without validating that signers had signature fields assigned. This was intentional - we thought API users might have specific flows where this flexibility was needed.
However, after running it this way for a while, we've observed that more often than not, API users inadvertently send documents without fields assigned. This causes confusion for their recipients (who receive a document with nothing to sign) and breaks their own systems expecting a completed signing flow.
## Problem
The API allowed distributing documents/envelopes even when signers had no signature fields assigned. This was inconsistent with the UI which validates this condition before allowing distribution.
## Solution
### 1. Create centralized validation helper
**File**: `packages/lib/utils/recipients.ts`
- Added `RECIPIENT_ROLES_THAT_REQUIRE_FIELDS` constant (currently only `SIGNER`)
- Added `getRecipientsWithMissingFields()` function that returns recipients missing required fields
- Uses existing `isSignatureFieldType` guard from `packages/prisma/guards/is-signature-field.ts`
### 2. Add server-side validation
**File**: `packages/lib/server-only/document/send-document.ts`
- Added validation check that throws `AppError` with `INVALID_REQUEST` code when signers are missing signature fields
- This blocks both v1 and v2 API distribution endpoints since they both use `sendDocument()`
### 3. Fix v1 API error handling
**File**: `packages/api/v1/implementation.ts`
- Changed `sendDocument` endpoint to use `AppError.toRestAPIError(err)` instead of always returning 500
- Now returns 400 for validation errors
### 4. Update UI to use shared helper
**Files**:
- `apps/remix/app/components/dialogs/envelope-distribute-dialog.tsx`
- `packages/ui/primitives/document-flow/add-fields.tsx`
### 5. Consolidate `hasSignatureField` checks
Updated to use `isSignatureFieldType` guard (checks both `SIGNATURE` and `FREE_SIGNATURE`):
- `apps/remix/app/components/general/document-signing/document-signing-form.tsx`
- `apps/remix/app/components/general/envelope-signing/envelope-signer-form.tsx`
- `apps/remix/app/components/embed/multisign/multi-sign-document-signing-view.tsx`
- `apps/remix/app/components/embed/embed-direct-template-client-page.tsx`
- `apps/remix/app/components/embed/embed-document-signing-page-v1.tsx`
### 6. Add E2E tests
**Files**:
- `packages/app-tests/e2e/api/v1/document-sending.spec.ts` - 5 new tests
- `packages/app-tests/e2e/api/v2/distribute-validation.spec.ts` - 8 new tests
## Test Coverage
- Distribution fails when signer has no fields
- Distribution fails when signer has only non-signature fields
- Distribution succeeds with SIGNATURE field
- Distribution succeeds with FREE_SIGNATURE field (v1 only via Prisma)
- Distribution succeeds when VIEWER/CC/APPROVER have no fields
- Distribution fails when one of multiple signers is missing signature field
- Distribution succeeds when all signers have signature fields
@@ -0,0 +1,186 @@
---
date: 2026-01-14
title: Simplewebauthn V13 Upgrade
---
## Overview
Upgrade SimpleWebAuthn packages from v9.x to v13.x to address the deprecation of `@simplewebauthn/types` and take advantage of new features and improvements.
## Current State
The codebase currently uses:
- `@simplewebauthn/browser@9.x`
- `@simplewebauthn/server@9.x`
- `@simplewebauthn/types@9.x`
## Breaking Changes Summary (v9 → v13)
### v10.0.0 Breaking Changes
1. **Minimum Node version raised to Node v20**
2. **`generateRegistrationOptions()` now expects `Base64URLString` for `excludeCredentials` IDs** (no more `type: 'public-key'` needed)
3. **`generateAuthenticationOptions()` now expects `Base64URLString` for `allowCredentials` IDs**
4. **`credentialID` returned from verification methods is now `Base64URLString`** instead of `Uint8Array`
5. **`AuthenticatorDevice.credentialID` is now `Base64URLString`**
6. **`rpID` is now required when calling `generateAuthenticationOptions()`**
7. **`generateRegistrationOptions()` will generate random user IDs** if not provided
8. **`user.id` is treated as base64url string in `startRegistration()`**
9. **`userHandle` is treated as base64url string in `startAuthentication()`**
### v11.0.0 Breaking Changes
1. **Positional arguments in `startRegistration()` and `startAuthentication()` replaced by object**
- Before: `startRegistration(options)`
- After: `startRegistration({ optionsJSON: options })`
- Before: `startAuthentication(options)`
- After: `startAuthentication({ optionsJSON: options })`
2. **`AuthenticatorDevice` type renamed to `WebAuthnCredential`**
- `credentialID``credential.id`
- `credentialPublicKey``credential.publicKey`
3. **`verifyRegistrationResponse()` returns `registrationInfo.credential` instead of individual properties**
- `credentialID``credential.id`
- `credentialPublicKey``credential.publicKey`
- `counter``credential.counter`
- `transports` are now in `credential.transports`
4. **`verifyAuthenticationResponse()` uses `credential` argument instead of `authenticator`**
### v13.0.0 Breaking Changes
1. **`@simplewebauthn/types` package is retired**
- Types are now exported from `@simplewebauthn/browser` and `@simplewebauthn/server`
- Import types from `@simplewebauthn/server` instead
## Files to Update
### Package Changes
1. Remove `@simplewebauthn/types` dependency
2. Update `@simplewebauthn/browser` to `^13.2.2`
3. Update `@simplewebauthn/server` to `^13.2.2`
### Server-side Files
#### 1. `packages/lib/server-only/auth/create-passkey-registration-options.ts`
- Change import from `@simplewebauthn/types` to `@simplewebauthn/server`
- Remove `type: 'public-key'` from `excludeCredentials` items
- Update `userID` to use `isoUint8Array.fromUTF8String()` for proper encoding
#### 2. `packages/lib/server-only/auth/create-passkey-authentication-options.ts`
- Change import from `@simplewebauthn/types` to `@simplewebauthn/server`
- Remove `type: 'public-key'` from `allowCredentials` items
#### 3. `packages/lib/server-only/auth/create-passkey-signin-options.ts`
- No changes needed (already using correct options)
#### 4. `packages/lib/server-only/auth/create-passkey.ts`
- Change import from `@simplewebauthn/types` to `@simplewebauthn/server`
- Update to use new `registrationInfo.credential` structure:
- `credentialID``credential.id`
- `credentialPublicKey``credential.publicKey`
- `counter``credential.counter`
- Note: `credential.id` is now a `Base64URLString`, so `Buffer.from(credentialID)` needs updating
#### 5. `packages/lib/server-only/document/is-recipient-authorized.ts`
- Update `verifyAuthenticationResponse()` to use `credential` instead of `authenticator`:
- Change `authenticator: { credentialID, credentialPublicKey, counter }` to `credential: { id, publicKey, counter }`
- Since `credential.id` is now base64url string, convert stored `credentialId` buffer to base64url
#### 6. `packages/auth/server/routes/passkey.ts`
- Update `verifyAuthenticationResponse()` to use `credential` instead of `authenticator`
- Same changes as `is-recipient-authorized.ts`
#### 7. `packages/trpc/server/auth-router/create-passkey.ts`
- Change import from `@simplewebauthn/types` to `@simplewebauthn/server`
### Browser-side Files
#### 8. `apps/remix/app/components/dialogs/passkey-create-dialog.tsx`
- Update `startRegistration()` call:
- Before: `startRegistration(passkeyRegistrationOptions)`
- After: `startRegistration({ optionsJSON: passkeyRegistrationOptions })`
#### 9. `apps/remix/app/components/forms/signin.tsx`
- Update `startAuthentication()` call:
- Before: `startAuthentication(options)`
- After: `startAuthentication({ optionsJSON: options })`
#### 10. `apps/remix/app/components/general/document-signing/document-signing-auth-passkey.tsx`
- Update `startAuthentication()` call:
- Before: `startAuthentication(options)`
- After: `startAuthentication({ optionsJSON: options })`
### Database/Schema Considerations
The database stores `credentialId` as `Bytes`. The new API returns `credential.id` as `Base64URLString`. We need to:
1. When **storing** a new passkey: Convert from `Base64URLString` to `Buffer`
2. When **passing to verification**: Convert from `Buffer` to `Base64URLString`
Use `isoBase64URL` helper from `@simplewebauthn/server/helpers` for these conversions.
## Implementation Steps
### Step 1: Update package.json dependencies
```bash
npm uninstall @simplewebauthn/types
npm install @simplewebauthn/browser@^13.2.2 @simplewebauthn/server@^13.2.2
```
### Step 2: Update type imports
Replace all `@simplewebauthn/types` imports with `@simplewebauthn/server`
### Step 3: Update browser-side API calls
- `startRegistration(options)``startRegistration({ optionsJSON: options })`
- `startAuthentication(options)``startAuthentication({ optionsJSON: options })`
### Step 4: Update server-side registration
- Update `excludeCredentials` format (remove `type: 'public-key'`)
- Update `userID` encoding if needed
- Update `verifyRegistrationResponse()` result handling for new `credential` structure
### Step 5: Update server-side authentication
- Update `allowCredentials` format (remove `type: 'public-key'`)
- Update `verifyAuthenticationResponse()` to use `credential` instead of `authenticator`
- Handle `Base64URLString` for `credential.id`
### Step 6: Update credential storage/retrieval
- When storing: Convert `Base64URLString` to `Buffer`
- When reading: Convert `Buffer` to `Base64URLString`
### Step 7: Test passkey flows
1. Test passkey creation
2. Test passkey sign-in
3. Test passkey authentication for document signing
4. Test passkey deletion
## Code Examples
### Converting stored Buffer to Base64URLString for verification
```typescript
import { isoBase64URL } from '@simplewebauthn/server/helpers';
// When reading from database (Buffer) and passing to verification
const credential = {
id: isoBase64URL.fromBuffer(passkey.credentialId),
publicKey: new Uint8Array(passkey.credentialPublicKey),
counter: Number(passkey.counter),
transports: passkey.transports,
};
```
### Converting Base64URLString to Buffer for storage
```typescript
import { isoBase64URL } from '@simplewebauthn/server/helpers';
// When storing from registration response
const credentialIdBuffer = Buffer.from(
isoBase64URL.toBuffer(registrationInfo.credential.id)
);
```
## Risks and Mitigations
1. **Database compatibility**: The `credentialId` is stored as `Bytes` in the database. The new API uses `Base64URLString`. We need proper conversion functions.
- **Mitigation**: Use `isoBase64URL.fromBuffer()` and `isoBase64URL.toBuffer()` for conversions
2. **Existing passkeys**: Existing passkeys should continue to work as long as conversion is done correctly.
- **Mitigation**: Test with existing passkeys after upgrade
3. **Browser compatibility**: v10+ requires newer browser APIs.
- **Mitigation**: `browserSupportsWebAuthn()` already handles this check
View File
+40
View File
@@ -1,3 +1,6 @@
# The license key to enable enterprise features for self hosters
NEXT_PRIVATE_DOCUMENSO_LICENSE_KEY=
# [[AUTH]]
NEXTAUTH_SECRET="secret"
@@ -23,12 +26,20 @@ NEXT_PRIVATE_OIDC_CLIENT_ID=""
NEXT_PRIVATE_OIDC_CLIENT_SECRET=""
NEXT_PRIVATE_OIDC_PROVIDER_LABEL="OIDC"
NEXT_PRIVATE_OIDC_SKIP_VERIFY=""
# Specifies the prompt to use for OIDC signin, explicitly setting
# an empty string will omit the prompt parameter.
# See: https://www.cerberauth.com/blog/openid-connect-oauth2-prompts/
NEXT_PRIVATE_OIDC_PROMPT="login"
# [[URLS]]
NEXT_PUBLIC_WEBAPP_URL="http://localhost:3000"
# URL used by the web app to request itself (e.g. local background jobs)
NEXT_PRIVATE_INTERNAL_WEBAPP_URL="http://localhost:3000"
# [[SERVER]]
# OPTIONAL: The port the server will listen on. Defaults to 3000.
PORT=3000
# [[DATABASE]]
NEXT_PRIVATE_DATABASE_URL="postgres://documenso:password@127.0.0.1:54320/documenso"
# Defines the URL to use for the database when running migrations and other commands that won't work with a connection pool.
@@ -51,6 +62,18 @@ NEXT_PRIVATE_SIGNING_GCLOUD_HSM_PUBLIC_CRT_FILE_PATH=
NEXT_PRIVATE_SIGNING_GCLOUD_HSM_PUBLIC_CRT_FILE_CONTENTS=
# OPTIONAL: The path to the Google Cloud Credentials file to use for the gcloud-hsm signing transport.
NEXT_PRIVATE_SIGNING_GCLOUD_APPLICATION_CREDENTIALS_CONTENTS=
# OPTIONAL: The path to the certificate chain file for the gcloud-hsm signing transport.
NEXT_PRIVATE_SIGNING_GCLOUD_HSM_CERT_CHAIN_FILE_PATH=
# OPTIONAL: The base64-encoded contents of the certificate chain for the gcloud-hsm signing transport.
NEXT_PRIVATE_SIGNING_GCLOUD_HSM_CERT_CHAIN_CONTENTS=
# OPTIONAL: The Google Secret Manager path to retrieve the certificate for the gcloud-hsm signing transport.
NEXT_PRIVATE_SIGNING_GCLOUD_HSM_SECRET_MANAGER_CERT_PATH=
# OPTIONAL: Comma-separated list of timestamp authority URLs for PDF signing (enables LTV and archival timestamps).
NEXT_PRIVATE_SIGNING_TIMESTAMP_AUTHORITY=
# OPTIONAL: Contact info to embed in PDF signatures. Defaults to the webapp URL.
NEXT_PUBLIC_SIGNING_CONTACT_INFO=
# OPTIONAL: Set to "true" to use the legacy adbe.pkcs7.detached subfilter instead of ETSI.CAdES.detached.
NEXT_PRIVATE_USE_LEGACY_SIGNING_SUBFILTER=
# [[STORAGE]]
# OPTIONAL: Defines the storage transport to use. Available options: database (default) | s3
@@ -130,6 +153,23 @@ NEXT_PUBLIC_POSTHOG_KEY=""
NEXT_PUBLIC_FEATURE_BILLING_ENABLED=
# OPTIONAL: Leave blank to allow users to signup through /signup page.
NEXT_PUBLIC_DISABLE_SIGNUP=
# OPTIONAL: Set to true to use internal webapp url in browserless requests.
NEXT_PUBLIC_USE_INTERNAL_URL_BROWSERLESS=false
# [[TELEMETRY]]
# OPTIONAL: Set to "true" to disable anonymous telemetry for self-hosted instances.
# Telemetry helps us understand how Documenso is being used and improve the product.
# We only collect: app version, installation ID, and node ID. No personal data is collected.
DOCUMENSO_DISABLE_TELEMETRY=
# [[AI]]
# OPTIONAL: Google Cloud Project ID for Vertex AI.
GOOGLE_VERTEX_PROJECT_ID=""
# OPTIONAL: Google Cloud region for Vertex AI. Defaults to "global".
GOOGLE_VERTEX_LOCATION="global"
# OPTIONAL: API key for Google Vertex AI (Gemini). Get your key from:
# https://console.cloud.google.com/vertex-ai/studio/settings/api-keys
GOOGLE_VERTEX_API_KEY=""
# [[E2E Tests]]
E2E_TEST_AUTHENTICATE_USERNAME="Test User"
+8 -6
View File
@@ -1,14 +1,19 @@
name: Playwright Tests
on:
push:
branches: ['main', 'feat/rr7']
branches: ['main']
pull_request:
branches: ['main']
concurrency:
group: ci-${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
jobs:
e2e_tests:
name: 'E2E Tests'
timeout-minutes: 60
runs-on: warp-ubuntu-2204-x64-16x
runs-on: warp-ubuntu-2204-x64-8x
steps:
- uses: actions/checkout@v4
@@ -28,9 +33,6 @@ jobs:
- name: Seed the database
run: npm run prisma:seed
- name: Build app
run: npm run build
- name: Install playwright browsers
run: npx playwright install --with-deps
@@ -45,7 +47,7 @@ jobs:
with:
name: test-results
path: 'packages/app-tests/**/test-results/*'
retention-days: 30
retention-days: 7
env:
TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
TURBO_TEAM: ${{ vars.TURBO_TEAM }}
+26 -3
View File
@@ -3,6 +3,12 @@ name: Publish Docker
on:
push:
branches: ['release']
workflow_dispatch:
inputs:
tag:
description: 'Git tag to build and publish (e.g., v1.0.0)'
required: true
type: string
jobs:
build_and_publish_platform_containers:
@@ -18,6 +24,7 @@ jobs:
steps:
- uses: actions/checkout@v4
with:
ref: ${{ inputs.tag || github.ref }}
fetch-tags: true
- name: Login to DockerHub
@@ -36,13 +43,20 @@ jobs:
- name: Build the docker image
env:
BUILD_PLATFORM: ${{ matrix.os == 'warp-ubuntu-latest-arm64-4x' && 'arm64' || 'amd64' }}
NEXT_PRIVATE_TELEMETRY_KEY: ${{ secrets.NEXT_PRIVATE_TELEMETRY_KEY }}
NEXT_PRIVATE_TELEMETRY_HOST: ${{ secrets.NEXT_PRIVATE_TELEMETRY_HOST }}
APP_VERSION: ${{ inputs.tag || '' }}
run: |
APP_VERSION="$(git name-rev --tags --name-only $(git rev-parse HEAD) | head -n 1 | sed 's/\^0//')"
if [ -z "$APP_VERSION" ]; then
APP_VERSION="$(git name-rev --tags --name-only $(git rev-parse HEAD) | head -n 1 | sed 's/\^0//')"
fi
GIT_SHA="$(git rev-parse HEAD)"
docker build \
-f ./docker/Dockerfile \
--progress=plain \
--build-arg NEXT_PRIVATE_TELEMETRY_KEY="${NEXT_PRIVATE_TELEMETRY_KEY:-}" \
--build-arg NEXT_PRIVATE_TELEMETRY_HOST="${NEXT_PRIVATE_TELEMETRY_HOST:-}" \
-t "documenso/documenso-$BUILD_PLATFORM:latest" \
-t "documenso/documenso-$BUILD_PLATFORM:$GIT_SHA" \
-t "documenso/documenso-$BUILD_PLATFORM:$APP_VERSION" \
@@ -69,6 +83,7 @@ jobs:
- name: Checkout
uses: actions/checkout@v4
with:
ref: ${{ inputs.tag || github.ref }}
fetch-tags: true
- name: Login to DockerHub
@@ -85,8 +100,12 @@ jobs:
password: ${{ secrets.GH_TOKEN }}
- name: Create and push DockerHub manifest
env:
APP_VERSION: ${{ inputs.tag || '' }}
run: |
APP_VERSION="$(git name-rev --tags --name-only $(git rev-parse HEAD) | head -n 1 | sed 's/\^0//')"
if [ -z "$APP_VERSION" ]; then
APP_VERSION="$(git name-rev --tags --name-only $(git rev-parse HEAD) | head -n 1 | sed 's/\^0//')"
fi
GIT_SHA="$(git rev-parse HEAD)"
# Check if the version is stable (no rc or beta in the version)
@@ -122,8 +141,12 @@ jobs:
docker manifest push documenso/documenso:$APP_VERSION
- name: Create and push Github Container Registry manifest
env:
APP_VERSION: ${{ inputs.tag || '' }}
run: |
APP_VERSION="$(git name-rev --tags --name-only $(git rev-parse HEAD) | head -n 1 | sed 's/\^0//')"
if [ -z "$APP_VERSION" ]; then
APP_VERSION="$(git name-rev --tags --name-only $(git rev-parse HEAD) | head -n 1 | sed 's/\^0//')"
fi
GIT_SHA="$(git rev-parse HEAD)"
# Check if the version is stable (no rc or beta in the version)
+45 -2
View File
@@ -17,6 +17,7 @@ jobs:
environment: Translations
permissions:
contents: write
pull-requests: write
steps:
- name: Checkout
uses: actions/checkout@v4
@@ -26,12 +27,54 @@ jobs:
- name: Extract translations
run: npm run translate:extract
- name: Check and commit any files created
- name: Commit changes and push to reserved branch
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
set -euo pipefail
BRANCH="chore/extract-translations"
git config --global user.name 'github-actions'
git config --global user.email 'github-actions@documenso.com'
git fetch origin
# Create branch locally (always reset to main)
git checkout -B "$BRANCH" origin/main
# Stage translation output
git add packages/lib/translations
git diff --staged --quiet --exit-code || (git commit -m "chore: extract translations" && git push)
# If no changes, exit early
if git diff --staged --quiet; then
echo "No translation changes found."
exit 0
fi
# Commit fresh snapshot
git commit -m "chore: extract translations"
# Force push reserved branch
git push origin "$BRANCH" --force
# Does a PR already exist?
EXISTING_PR=$(gh pr list \
--state open \
--head "$BRANCH" \
--json number \
--jq '.[0].number // empty')
if [ -z "$EXISTING_PR" ]; then
echo "No existing PR — creating new one."
gh pr create \
--title "chore: extract translations" \
--body "Automated translation extraction" \
--base main \
--head "$BRANCH"
else
echo "PR #$EXISTING_PR already exists — not creating a new one."
fi
- name: Compile translations
id: compile_translations
+7
View File
@@ -60,3 +60,10 @@ CLAUDE.md
# agents
.specs
# scripts
scripts/output*
# license
.documenso-license.json
.documenso-license-backup.json
-1
View File
@@ -1,3 +1,2 @@
auto-install-peers = true
legacy-peer-deps = true
prefer-dedupe = true
+80
View File
@@ -0,0 +1,80 @@
---
description: Add and commit changes using conventional commits
allowed-tools: Bash, Read, Glob, Grep
---
Create a git commit for the current changes using the Conventional Commits standard.
## Process
1. **Analyze the changes** by running:
- `git status` to see all modified/untracked files
- `git diff` to see unstaged changes
- `git diff --staged` to see already-staged changes
- `git log --oneline -5` to see recent commit style
2. **Stage appropriate files**:
- Stage all related changes with `git add`
- Do NOT stage files that appear to contain secrets (.env, credentials, API keys, tokens)
- If you detect potential secrets, warn the user and skip those files
3. **Determine the commit type** based on the changes:
- `feat`: New feature or capability
- `fix`: Bug fix
- `docs`: Documentation only
- `style`: Formatting, whitespace (not CSS)
- `refactor`: Code restructuring without behavior change
- `perf`: Performance improvement
- `test`: Adding or updating tests
- `build`: Build system or dependencies
- `ci`: CI/CD configuration
- `chore`: Maintenance tasks, tooling, config
NOTE: Do not use a scope for commits
4. **Write the commit message**:
- **Subject line**: `<type>: <description>`
- Use imperative mood ("add" not "added")
- Lowercase, no period at end
- Max 50 characters if possible, 72 hard limit
- **Body** (if needed): Explain _why_, not _what_
- Wrap at 72 characters
- Separate from subject with blank line
## Commit Format
```
<type>[scope]: <subject>
[optional body explaining WHY this change was made]
```
## Examples
Simple change:
```
fix: handle empty input in parser without throwing
```
With body:
```
feat: add streaming response support
Large responses were causing memory issues in production.
Streaming allows processing chunks incrementally.
```
## Rules
- NEVER commit files that may contain secrets
- NEVER use `git commit --amend` unless the user explicitly requests it
- NEVER use `--no-verify` to skip hooks
- If the pre-commit hook fails, fix the issues and create a NEW commit
- If there are no changes to commit, inform the user and stop
- Use a HEREDOC to pass the commit message to ensure proper formatting
## Execute
Run the git commands to analyze, stage, and commit the changes now.
+112
View File
@@ -0,0 +1,112 @@
---
description: Continue implementing a spec from a previous session
argument-hint: <spec-file-path>
---
You are continuing implementation of a specification that was started in a previous session. Work autonomously until the feature is complete and tests pass.
## Your Task
1. **Read the spec** at `$ARGUMENTS`
2. **Read CODE_STYLE.md** for formatting conventions
3. **Assess current state**:
- Check git status for uncommitted changes
- Run tests to see what's passing/failing (if E2E tests exist)
- Review any existing implementation
4. **Determine what remains** by comparing the spec to the current state
5. **Plan remaining work** using TodoWrite
6. **Continue implementing** until complete
## Assessing Current State
Run these commands to understand where the previous session left off:
```bash
git status # See uncommitted changes
git log --oneline -10 # See recent commits
npm run typecheck -w @documenso/remix # Check for type errors
npm run lint:fix # Check for linting issues
```
Review the code that's already been written to understand:
- What's already implemented
- What's partially done
- What's not started yet
## Implementation Guidelines
### During Implementation
- Follow CODE_STYLE.md strictly (2-space indent, double quotes, braces always, etc.)
- Follow workspace rules for TypeScript, React, TRPC patterns, and Remix conventions
- Mark todos complete as you finish each task
- Commit logical chunks of work
### Code Quality
- No stubbed implementations
- Handle edge cases and error conditions
- Include descriptive error messages with context
- Use async/await for all I/O operations
- Use AppError class when throwing errors
- Use Zod for validation and react-hook-form for forms
### Testing
**Important**: E2E tests are time-consuming. Only write tests for non-trivial functionality.
- Write E2E tests in `packages/app-tests/e2e/` using Playwright
- Test critical user flows and edge cases
- Follow existing E2E test patterns in the codebase
- Use descriptive test names that explain what is being tested
- Skip tests for trivial changes (simple UI tweaks, minor refactors, etc.)
## Autonomous Workflow
Work continuously through these steps:
1. **Implement** - Write the code for the current task
2. **Typecheck** - Run `npm run typecheck -w @documenso/remix` to verify types
3. **Lint** - Run `npm run lint:fix` to fix linting issues
4. **Test** - If non-trivial, run E2E tests: `npm run test:dev -w @documenso/app-tests`
5. **Fix** - If tests fail, fix and re-run
6. **Repeat** - Move to next task
## Stopping Conditions
**Stop and report success when:**
- All spec requirements are implemented
- Typecheck passes
- Lint passes
- E2E tests pass (if written for non-trivial functionality)
**Stop and ask for help when:**
- The spec is ambiguous and you need clarification
- You encounter a blocking issue you cannot resolve
- You need to make a decision that significantly deviates from the spec
- External dependencies are missing
## Commands
```bash
# Type checking
npm run typecheck -w @documenso/remix
# Linting
npm run lint:fix
# E2E Tests (only for non-trivial work)
npm run test:dev -w @documenso/app-tests # Run E2E tests in dev mode
npm run test-ui:dev -w @documenso/app-tests # Run E2E tests with UI
npm run test:e2e # Run full E2E test suite
# Development
npm run dev # Start dev server
```
## Begin
Read the spec file and CODE_STYLE.md, assess the current implementation state, then continue where the previous session left off. Use TodoWrite to track your progress throughout.
@@ -0,0 +1,75 @@
---
description: Create a new justification file in .agents/justifications/
argument-hint: <justification-slug> [content]
---
You are creating a new justification file in the `.agents/justifications/` directory.
## Your Task
1. **Determine the slug** - Use `$ARGUMENTS` as the file slug (kebab-case recommended)
2. **Gather content** - Collect or generate the justification content
3. **Create the file** - Use the create-justification script to generate the file
## Usage
The script will automatically:
- Generate a unique three-word ID (e.g., `swift-emerald-river`)
- Create frontmatter with current date and formatted title
- Save the file as `{id}-{slug}.md` in `.agents/justifications/`
## Creating the File
### Option 1: Direct Content
If you have the content ready, run:
```bash
npx tsx scripts/create-justification.ts "$ARGUMENTS" "Your justification content here"
```
### Option 2: Multi-line Content (Heredoc)
For multi-line content, use heredoc:
```bash
npx tsx scripts/create-justification.ts "$ARGUMENTS" << HEREDOC
Your multi-line
justification content
goes here
HEREDOC
```
### Option 3: Pipe Content
You can also pipe content:
```bash
echo "Your content" | npx tsx scripts/create-justification.ts "$ARGUMENTS"
```
## File Format
The created file will have:
```markdown
---
date: 2026-01-13
title: Justification Title
---
Your content here
```
The title is automatically formatted from the slug (e.g., `architecture-decision``Architecture Decision`).
## Guidelines
- Use descriptive slugs in kebab-case (e.g., `tech-stack-choice`, `api-design-rationale`)
- Include clear reasoning and context for the decision
- The unique ID ensures no filename conflicts
- Files are automatically dated for organization
## Begin
Create a justification file using the slug from `$ARGUMENTS` and appropriate content documenting the reasoning or justification.
+76
View File
@@ -0,0 +1,76 @@
---
description: Create a new plan file in .agents/plans/
argument-hint: <plan-slug> [content]
---
You are creating a new plan file in the `.agents/plans/` directory.
## Your Task
1. **Determine the slug** - Use `$ARGUMENTS` as the file slug (kebab-case recommended)
2. **Gather content** - Collect or generate the plan content
3. **Create the file** - Use the create-plan script to generate the file
## Usage
The script will automatically:
- Generate a unique three-word ID (e.g., `happy-blue-moon`)
- Create frontmatter with current date and formatted title
- Save the file as `{id}-{slug}.md` in `.agents/plans/`
## Creating the File
### Option 1: Direct Content
If you have the content ready, run:
```bash
npx tsx scripts/create-plan.ts "$ARGUMENTS" "Your plan content here"
```
### Option 2: Multi-line Content (Heredoc)
For multi-line content, use heredoc:
```bash
npx tsx scripts/create-plan.ts "$ARGUMENTS" << HEREDOC
Your multi-line
plan content
goes here
HEREDOC
```
### Option 3: Pipe Content
You can also pipe content:
```bash
echo "Your content" | npx tsx scripts/create-plan.ts "$ARGUMENTS"
```
## File Format
The created file will have:
```markdown
---
date: 2026-01-13
title: Plan Title
---
Your content here
```
The title is automatically formatted from the slug (e.g., `my-feature``My Feature`).
## Guidelines
- Use descriptive slugs in kebab-case (e.g., `user-authentication`, `api-integration`)
- Include clear, actionable plan content
- The unique ID ensures no filename conflicts
- Files are automatically dated for organization
## Begin
Create a plan file using the slug from `$ARGUMENTS` and appropriate content for the planning task.
+75
View File
@@ -0,0 +1,75 @@
---
description: Create a new scratch file in .agents/scratches/
argument-hint: <scratch-slug> [content]
---
You are creating a new scratch file in the `.agents/scratches/` directory.
## Your Task
1. **Determine the slug** - Use `$ARGUMENTS` as the file slug (kebab-case recommended)
2. **Gather content** - Collect or generate the scratch content
3. **Create the file** - Use the create-scratch script to generate the file
## Usage
The script will automatically:
- Generate a unique three-word ID (e.g., `calm-teal-cloud`)
- Create frontmatter with current date and formatted title
- Save the file as `{id}-{slug}.md` in `.agents/scratches/`
## Creating the File
### Option 1: Direct Content
If you have the content ready, run:
```bash
npx tsx scripts/create-scratch.ts "$ARGUMENTS" "Your scratch content here"
```
### Option 2: Multi-line Content (Heredoc)
For multi-line content, use heredoc:
```bash
npx tsx scripts/create-scratch.ts "$ARGUMENTS" << HEREDOC
Your multi-line
scratch content
goes here
HEREDOC
```
### Option 3: Pipe Content
You can also pipe content:
```bash
echo "Your content" | npx tsx scripts/create-scratch.ts "$ARGUMENTS"
```
## File Format
The created file will have:
```markdown
---
date: 2026-01-13
title: Scratch Title
---
Your content here
```
The title is automatically formatted from the slug (e.g., `quick-notes``Quick Notes`).
## Guidelines
- Use descriptive slugs in kebab-case (e.g., `exploration-ideas`, `temporary-notes`)
- Scratch files are for temporary notes, explorations, or ideas
- The unique ID ensures no filename conflicts
- Files are automatically dated for organization
## Begin
Create a scratch file using the slug from `$ARGUMENTS` and appropriate content for notes or exploration.
+201
View File
@@ -0,0 +1,201 @@
---
description: Generate MDX documentation for a module or feature
argument-hint: <module-path-or-feature>
---
You are creating proper MDX documentation for a module or feature in Documenso using Nextra.
## Your Task
1. **Identify the scope** - What does `$ARGUMENTS` refer to? (file, directory, or feature name)
2. **Read the source code** - Understand the public API, types, and behavior
3. **Read existing docs** - Check if there's documentation to update or reference
4. **Write comprehensive documentation** - Create or update MDX docs in the appropriate location
5. **Update navigation** - Add entry to `_meta.js` if creating a new page
## Documentation Structure
Create documentation in the appropriate location:
- **Developer docs**: `apps/documentation/pages/developers/`
- **User docs**: `apps/documentation/pages/users/`
### File Format
All documentation files must be `.mdx` files with frontmatter:
```mdx
---
title: Page Title
description: Brief description for SEO and meta tags
---
# Page Title
Content starts here...
```
### Navigation
Each directory should have a `_meta.js` file that defines the navigation structure:
```javascript
export default {
index: 'Introduction',
'feature-name': 'Feature Name',
'another-feature': 'Another Feature',
};
```
If creating a new page, add it to the appropriate `_meta.js` file.
### Documentation Format
````mdx
---
title: <Module|Feature Name>
description: Brief description of what this does and when to use it
---
# <Module|Feature Name>
Brief description of what this module/feature does and when to use it.
## Installation
If there are specific packages or imports needed:
```bash
npm install @documenso/package-name
```
## Quick Start
```jsx
// Minimal working example
import { Component } from '@documenso/package';
const Example = () => {
return <Component />;
};
```
## API Reference
### Component/Function Name
Description of what it does.
#### Props/Parameters
| Prop/Param | Type | Description |
| ---------- | -------------------- | ------------------------- |
| prop | `string` | Description of the prop |
| optional | `boolean` (optional) | Optional prop description |
#### Example
```jsx
import { Component } from '@documenso/package';
<Component prop="value" optional={true} />;
```
### Types
#### `TypeName`
```typescript
type TypeName = {
property: string;
optional?: boolean;
};
```
## Examples
### Common Use Case
```jsx
// Full working example
```
### Advanced Usage
```jsx
// More complex example
```
## Related
- [Link to related documentation](/developers/path)
- [Another related page](/users/path)
````
## Guidelines
### Content Quality
- **Be accurate** - Verify behavior by reading the code
- **Be complete** - Document all public API surface
- **Be practical** - Include real, working examples
- **Be concise** - Don't over-explain obvious things
- **Be user-focused** - Write for the target audience (developers or users)
### Code Examples
- Use appropriate language tags: `jsx`, `tsx`, `typescript`, `bash`, `json`
- Show imports when not obvious
- Include expected output in comments where helpful
- Progress from simple to complex
- Use real examples from the codebase when possible
### Formatting
- Always include frontmatter with `title` and `description`
- Use proper markdown headers (h1 for title, h2 for sections)
- Use tables for props/parameters documentation (matching existing style)
- Use code fences with appropriate language tags
- Use Nextra components when appropriate:
- `<Callout type="info">` for notes
- `<Steps>` for step-by-step instructions
- Use relative links for internal documentation (e.g., `/developers/embedding/react`)
### Nextra Components
You can import and use Nextra components:
```jsx
import { Callout, Steps } from 'nextra/components';
<Callout type="info">
This is an informational note.
</Callout>
<Steps>
<Steps.Step>First step</Steps.Step>
<Steps.Step>Second step</Steps.Step>
</Steps>
```
### Maintenance
- Include types inline so docs don't get stale
- Reference source file locations for complex behavior
- Keep examples up-to-date with the codebase
- Update `_meta.js` when adding new pages
## Process
1. **Explore the code** - Read source files to understand the API
2. **Identify the audience** - Is this for developers or users?
3. **Check existing docs** - Look for similar pages to match style
4. **Draft the structure** - Outline sections before writing
5. **Write content** - Fill in each section with frontmatter
6. **Add examples** - Create working code samples
7. **Update navigation** - Add to `_meta.js` if needed
8. **Review** - Read through for clarity and accuracy
## Begin
Analyze `$ARGUMENTS`, read the relevant source code, check existing documentation patterns, and create comprehensive MDX documentation following the Documenso documentation style.
+100
View File
@@ -0,0 +1,100 @@
---
description: Implement a spec from the plans directory
argument-hint: <spec-file-path>
---
You are implementing a specification from the `.agents/plans/` directory. Work autonomously until the feature is complete and tests pass.
## Your Task
1. **Read the spec** at `$ARGUMENTS`
2. **Read CODE_STYLE.md** for formatting conventions
3. **Plan the implementation** using the TodoWrite tool to break down the work
4. **Implement the feature** following the spec and code style
5. **Write E2E tests** only for non-trivial functionality (E2E tests are time-consuming)
6. **Run tests** and fix any failures
7. **Run typecheck and lint** and fix any issues
## Implementation Guidelines
### Before Coding
- Understand the spec's goals and scope
- Identify the desired API from usage examples in the spec
- Review related existing code to understand patterns
- Break the work into discrete tasks using TodoWrite
### During Implementation
- Follow CODE_STYLE.md strictly (2-space indent, double quotes, braces always, etc.)
- Follow workspace rules for TypeScript, React, TRPC patterns, and Remix conventions
- Mark todos complete as you finish each task
- Commit logical chunks of work
### Code Quality
- No stubbed implementations
- Handle edge cases and error conditions
- Include descriptive error messages with context
- Use async/await for all I/O operations
- Use AppError class when throwing errors
- Use Zod for validation and react-hook-form for forms
### Testing
**Important**: E2E tests are time-consuming. Only write tests for non-trivial functionality.
- Write E2E tests in `packages/app-tests/e2e/` using Playwright
- Test critical user flows and edge cases
- Follow existing E2E test patterns in the codebase
- Use descriptive test names that explain what is being tested
- Skip tests for trivial changes (simple UI tweaks, minor refactors, etc.)
## Autonomous Workflow
Work continuously through these steps:
1. **Implement** - Write the code for the current task
2. **Typecheck** - Run `npm run typecheck -w @documenso/remix` to verify types
3. **Lint** - Run `npm run lint:fix` to fix linting issues
4. **Test** - If non-trivial, run E2E tests: `npm run test:dev -w @documenso/app-tests`
5. **Fix** - If tests fail, fix and re-run
6. **Repeat** - Move to next task
## Stopping Conditions
**Stop and report success when:**
- All spec requirements are implemented
- Typecheck passes
- Lint passes
- E2E tests pass (if written for non-trivial functionality)
**Stop and ask for help when:**
- The spec is ambiguous and you need clarification
- You encounter a blocking issue you cannot resolve
- You need to make a decision that significantly deviates from the spec
- External dependencies are missing
## Commands
```bash
# Type checking
npm run typecheck -w @documenso/remix
# Linting
npm run lint:fix
# E2E Tests (only for non-trivial work)
npm run test:dev -w @documenso/app-tests # Run E2E tests in dev mode
npm run test-ui:dev -w @documenso/app-tests # Run E2E tests with UI
npm run test:e2e # Run full E2E test suite
# Development
npm run dev # Start dev server
```
## Begin
Read the spec file and CODE_STYLE.md, then start implementing. Use TodoWrite to track your progress throughout.
+57
View File
@@ -0,0 +1,57 @@
---
description: Deep-dive interview to flesh out a spec or design document
agent: build
argument-hint: <file-path>
---
You are conducting a thorough interview to help flesh out and complete a specification or design document.
## Your Task
1. **Read the document** at `$ARGUMENTS`
2. **Analyze it deeply** - identify gaps, ambiguities, unexplored edge cases, and areas needing clarification
3. **Interview the user** by providing a question with some pre-determined options
4. **Write the completed spec** back to the file when the interview is complete
## Interview Guidelines
### Question Quality
- Ask **non-obvious, insightful questions** - avoid surface-level queries
- Focus on: technical implementation details, architectural decisions, edge cases, error handling, UX implications, security considerations, performance tradeoffs, integration points, migration strategies, rollback plans
- Each question should reveal something that would otherwise be missed
- Challenge assumptions embedded in the document
- Explore second and third-order consequences of design decisions
- Use the Web Search and other tools where required to ground questions (e.g. package recommendations)
### Question Strategy
- Start by identifying the 3-5 most critical unknowns or ambiguities
- Use the AskUserQuestion tool with well-crafted options that represent real tradeoffs
- When appropriate, offer multiple valid approaches with their pros/cons as options
- Don't ask about things that are already clearly specified
- Probe deeper when answers reveal new areas of uncertainty
### Topics to Explore (as relevant)
- **Technical**: Data models, API contracts, state management, concurrency, caching, validation
- **UX**: Error states, loading states, empty states, edge cases, accessibility, mobile considerations
- **Operations**: Deployment, monitoring, alerting, debugging, logging, feature flags
- **Security**: Auth, authz, input validation, rate limiting, audit trails
- **Scale**: Performance bottlenecks, data growth, traffic spikes, graceful degradation
- **Integration**: Dependencies, backwards compatibility, versioning, migration path
- **Failure modes**: What happens when X fails? How do we recover? What's the blast radius?
### Interview Flow
1. Ask 2-4 questions at a time (use multiple questions in one when they're related)
2. After each round, incorporate answers and identify follow-up questions
3. Continue until all critical areas are addressed
4. Signal when you believe the interview is complete, but offer to go deeper
## Output
When the interview is complete:
1. Synthesize all gathered information
2. Rewrite/expand the original document with the new details
3. Preserve the document's original structure where sensible, but reorganize if needed
4. Add new sections for areas that weren't originally covered
5. Write the completed spec back to `$ARGUMENTS`
Begin by reading the file and identifying your first set of deep questions.
@@ -0,0 +1,56 @@
---
name: create-justification
description: Create a new justification file in .agents/justifications/ with a unique three-word ID, frontmatter, and formatted title
license: MIT
compatibility: opencode
metadata:
audience: agents
workflow: decision-making
---
## What I do
I help you create new justification files in the `.agents/justifications/` directory. Each justification file gets:
- A unique three-word identifier (e.g., `swift-emerald-river`)
- Frontmatter with the current date and formatted title
- Content you provide
## How to use
Run the script with a slug and content:
```bash
npx tsx scripts/create-justification.ts "decision-name" "Justification content here"
```
Or use heredoc for multi-line content:
```bash
npx tsx scripts/create-justification.ts "decision-name" << HEREDOC
Multi-line
justification content
goes here
HEREDOC
```
## File format
Files are created as: `{three-word-id}-{slug}.md`
Example: `swift-emerald-river-decision-name.md`
The file includes frontmatter:
```markdown
---
date: 2026-01-13
title: Decision Name
---
Your content here
```
## When to use me
Use this skill when you need to document the reasoning or justification for a decision, approach, or architectural choice. The unique ID ensures no filename conflicts, and the frontmatter provides metadata for organization.
+56
View File
@@ -0,0 +1,56 @@
---
name: create-plan
description: Create a new plan file in .agents/plans/ with a unique three-word ID, frontmatter, and formatted title
license: MIT
compatibility: opencode
metadata:
audience: agents
workflow: planning
---
## What I do
I help you create new plan files in the `.agents/plans/` directory. Each plan file gets:
- A unique three-word identifier (e.g., `happy-blue-moon`)
- Frontmatter with the current date and formatted title
- Content you provide
## How to use
Run the script with a slug and content:
```bash
npx tsx scripts/create-plan.ts "feature-name" "Plan content here"
```
Or use heredoc for multi-line content:
```bash
npx tsx scripts/create-plan.ts "feature-name" << HEREDOC
Multi-line
plan content
goes here
HEREDOC
```
## File format
Files are created as: `{three-word-id}-{slug}.md`
Example: `happy-blue-moon-feature-name.md`
The file includes frontmatter:
```markdown
---
date: 2026-01-13
title: Feature Name
---
Your content here
```
## When to use me
Use this skill when you need to create a new plan document for a feature, task, or project. The unique ID ensures no filename conflicts, and the frontmatter provides metadata for organization.
+56
View File
@@ -0,0 +1,56 @@
---
name: create-scratch
description: Create a new scratch file in .agents/scratches/ with a unique three-word ID, frontmatter, and formatted title
license: MIT
compatibility: opencode
metadata:
audience: agents
workflow: exploration
---
## What I do
I help you create new scratch files in the `.agents/scratches/` directory. Each scratch file gets:
- A unique three-word identifier (e.g., `calm-teal-cloud`)
- Frontmatter with the current date and formatted title
- Content you provide
## How to use
Run the script with a slug and content:
```bash
npx tsx scripts/create-scratch.ts "note-name" "Scratch content here"
```
Or use heredoc for multi-line content:
```bash
npx tsx scripts/create-scratch.ts "note-name" << HEREDOC
Multi-line
scratch content
goes here
HEREDOC
```
## File format
Files are created as: `{three-word-id}-{slug}.md`
Example: `calm-teal-cloud-note-name.md`
The file includes frontmatter:
```markdown
---
date: 2026-01-13
title: Note Name
---
Your content here
```
## When to use me
Use this skill when you need to create a temporary note, exploration document, or scratch pad for ideas. The unique ID ensures no filename conflicts, and the frontmatter provides metadata for organization.
+2 -1
View File
@@ -17,5 +17,6 @@
},
"[typescriptreact]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
},
"prisma.pinToPrisma6": true
}
+2
View File
@@ -11,6 +11,8 @@
- `npm run format` - Format code with Prettier
- `npm run dev` - Start development server for Remix app
**Important:** Do not run `npm run build` to verify changes unless explicitly asked. Builds take a long time (~2 minutes). Use `npx tsc --noEmit` for type checking specific packages if needed.
## Code Style Guidelines
- Use TypeScript for all code; prefer `type` over `interface`
+692
View File
@@ -0,0 +1,692 @@
# Documenso Code Style Guide
This document captures the code style, patterns, and conventions used in the Documenso codebase. It covers both enforceable rules and subjective "taste" elements that make our code consistent and maintainable.
## Table of Contents
1. [General Principles](#general-principles)
2. [TypeScript Conventions](#typescript-conventions)
3. [Imports & Dependencies](#imports--dependencies)
4. [Functions & Methods](#functions--methods)
5. [React & Components](#react--components)
6. [Error Handling](#error-handling)
7. [Async/Await Patterns](#asyncawait-patterns)
8. [Whitespace & Formatting](#whitespace--formatting)
9. [Naming Conventions](#naming-conventions)
10. [Pattern Matching](#pattern-matching)
11. [Database & Prisma](#database--prisma)
12. [TRPC Patterns](#trpc-patterns)
---
## General Principles
- **Functional over Object-Oriented**: Prefer functional programming patterns over classes
- **Explicit over Implicit**: Be explicit about types, return values, and error cases
- **Early Returns**: Use guard clauses and early returns to reduce nesting
- **Immutability**: Favor `const` over `let`; avoid mutation where possible
---
## TypeScript Conventions
### Type Definitions
```typescript
// ✅ Prefer `type` over `interface`
type CreateDocumentOptions = {
templateId: number;
userId: number;
recipients: Recipient[];
};
// ❌ Avoid interfaces unless absolutely necessary
interface CreateDocumentOptions {
templateId: number;
}
```
### Type Imports
```typescript
// ✅ Use `type` keyword for type-only imports
import type { Document, Recipient } from '@prisma/client';
import { DocumentStatus } from '@prisma/client';
// Types in function signatures
export const findDocuments = async ({ userId, teamId }: FindDocumentsOptions) => {
// ...
};
```
### Inline Types for Function Parameters
```typescript
// ✅ Extract inline types to named types
type FinalRecipient = Pick<Recipient, 'name' | 'email' | 'role' | 'authOptions'> & {
templateRecipientId: number;
fields: Field[];
};
const finalRecipients: FinalRecipient[] = [];
```
---
## Imports & Dependencies
### Import Organization
Imports should be organized in the following order with blank lines between groups:
```typescript
// 1. React imports
import { useCallback, useEffect, useMemo } from 'react';
// 2. Third-party library imports (alphabetically)
import { zodResolver } from '@hookform/resolvers/zod';
import { Trans } from '@lingui/react/macro';
import type { Document, Recipient } from '@prisma/client';
import { DocumentStatus, RecipientRole } from '@prisma/client';
import { match } from 'ts-pattern';
// 3. Internal package imports (from @documenso/*)
import { AppError } from '@documenso/lib/errors/app-error';
import { prisma } from '@documenso/prisma';
import { Button } from '@documenso/ui/primitives/button';
// 4. Relative imports
import { getTeamById } from '../team/get-team';
import type { FindResultResponse } from './types';
```
### Destructuring Imports
```typescript
// ✅ Destructure specific exports
// ✅ Use type imports for types
import type { Document } from '@prisma/client';
import { Button } from '@documenso/ui/primitives/button';
import { Input } from '@documenso/ui/primitives/input';
```
---
## Functions & Methods
### Arrow Functions
```typescript
// ✅ Always use arrow functions for functions
export const createDocument = async ({
userId,
title,
}: CreateDocumentOptions) => {
// ...
};
// ✅ Callbacks and handlers
const onSubmit = useCallback(async () => {
// ...
}, [dependencies]);
// ❌ Avoid regular function declarations
function createDocument() {
// ...
}
```
### Function Parameters
```typescript
// ✅ Use destructured object parameters for multiple params
export const findDocuments = async ({
userId,
teamId,
status = ExtendedDocumentStatus.ALL,
page = 1,
perPage = 10,
}: FindDocumentsOptions) => {
// ...
};
// ✅ Destructure on separate line when needed
const onFormSubmit = form.handleSubmit(onSubmit);
// ✅ Deconstruct nested properties explicitly
const { user } = ctx;
const { templateId } = input;
```
---
## React & Components
### Component Definition
```typescript
// ✅ Use const with arrow function
export const AddSignersFormPartial = ({
documentFlow,
recipients,
fields,
onSubmit,
}: AddSignersFormProps) => {
// ...
};
// ❌ Never use classes
class MyComponent extends React.Component {
// ...
}
```
### Hooks
```typescript
// ✅ Group related hooks together with blank line separation
const { _ } = useLingui();
const { toast } = useToast();
const { currentStep, totalSteps, previousStep } = useStep();
const form = useForm<TFormSchema>({
resolver: zodResolver(ZFormSchema),
defaultValues: {
// ...
},
});
```
### Event Handlers
```typescript
// ✅ Use arrow functions with descriptive names
const onFormSubmit = async () => {
await form.trigger();
// ...
};
const onFieldCopy = useCallback(
(event?: KeyboardEvent | null) => {
event?.preventDefault();
// ...
},
[dependencies],
);
// ✅ Inline handlers for simple operations
<Button onClick={() => setOpen(false)}>Close</Button>
```
### State Management
```typescript
// ✅ Descriptive state names with auxiliary verbs
const [isLoading, setIsLoading] = useState(false);
const [hasError, setHasError] = useState(false);
const [showAdvancedSettings, setShowAdvancedSettings] = useState(false);
// ✅ Complex state in single useState when related
const [coords, setCoords] = useState({
x: 0,
y: 0,
});
```
---
## Error Handling
### Try-Catch Blocks
```typescript
// ✅ Use try-catch for operations that might fail
try {
const document = await getDocumentById({
documentId: Number(documentId),
userId: user.id,
});
return {
status: 200,
body: document,
};
} catch (err) {
return {
status: 404,
body: {
message: 'Document not found',
},
};
}
```
### Throwing Errors
```typescript
// ✅ Use AppError for application errors
throw new AppError(AppErrorCode.NOT_FOUND, {
message: 'Template not found',
});
// ✅ Use descriptive error messages
if (!template) {
throw new AppError(AppErrorCode.NOT_FOUND, {
message: `Template with ID ${templateId} not found`,
});
}
```
### Error Parsing on Frontend
```typescript
// ✅ Parse errors on the frontend
try {
await updateOrganisation({ organisationId, data });
} catch (err) {
const error = AppError.parseError(err);
console.error(error);
toast({
title: t`An error occurred`,
description: error.message,
variant: 'destructive',
});
}
```
---
## Async/Await Patterns
### Async Function Definitions
```typescript
// ✅ Mark async functions clearly
export const createDocument = async ({
userId,
title,
}: Options): Promise<Document> => {
// ...
};
// ✅ Use await for promises
const document = await prisma.document.create({ data });
// ✅ Use Promise.all for parallel operations
const [document, recipients] = await Promise.all([
getDocumentById({ documentId }),
getRecipientsForDocument({ documentId }),
]);
```
### Void for Fire-and-Forget
```typescript
// ✅ Use void for intentionally unwaited promises
void handleAutoSave();
// ✅ Or in event handlers
onClick={() => void onFormSubmit()}
```
---
## Whitespace & Formatting
### Blank Lines Between Concepts
```typescript
// ✅ Blank line after imports
import { prisma } from '@documenso/prisma';
export const findDocuments = async () => {
// ...
};
// ✅ Blank line between logical sections
const user = await prisma.user.findFirst({ where: { id: userId } });
let team = null;
if (teamId !== undefined) {
team = await getTeamById({ userId, teamId });
}
// ✅ Blank line before return statements
const result = await someOperation();
return result;
```
### Function/Method Spacing
```typescript
// ✅ No blank lines between chained methods in same operation
const documents = await prisma.document
.findMany({ where: { userId } })
.then((docs) => docs.map(maskTokens));
// ✅ Blank line between different operations
const document = await createDocument({ userId });
await sendDocument({ documentId: document.id });
return document;
```
### Object and Array Formatting
```typescript
// ✅ Multi-line when complex
const options = {
userId,
teamId,
status: ExtendedDocumentStatus.ALL,
page: 1,
};
// ✅ Single line when simple
const coords = { x: 0, y: 0 };
// ✅ Array items on separate lines when objects
const recipients = [
{
name: 'John',
email: 'john@example.com',
},
{
name: 'Jane',
email: 'jane@example.com',
},
];
```
---
## Naming Conventions
### Variables
```typescript
// ✅ camelCase for variables and functions
const documentId = 123;
const onSubmit = () => {};
// ✅ Descriptive names with auxiliary verbs for booleans
const isLoading = false;
const hasError = false;
const canEdit = true;
const shouldRender = true;
// ✅ Prefix with $ for DOM elements
const $page = document.querySelector('.page');
const $inputRef = useRef<HTMLInputElement>(null);
```
### Types and Schemas
```typescript
// ✅ PascalCase for types
type CreateDocumentOptions = {
userId: number;
};
// ✅ Prefix Zod schemas with Z
const ZCreateDocumentSchema = z.object({
title: z.string(),
});
// ✅ Prefix type from Zod schema with T
type TCreateDocumentSchema = z.infer<typeof ZCreateDocumentSchema>;
```
### Constants
```typescript
// ✅ UPPER_SNAKE_CASE for true constants
const DEFAULT_DOCUMENT_DATE_FORMAT = 'dd/MM/yyyy';
const MAX_FILE_SIZE = 1024 * 1024 * 5;
// ✅ camelCase for const variables that aren't "constants"
const userId = await getUserId();
```
### Functions
```typescript
// ✅ Verb-based names for functions
const createDocument = async () => {};
const findDocuments = async () => {};
const updateDocument = async () => {};
const deleteDocument = async () => {};
// ✅ On prefix for event handlers
const onSubmit = () => {};
const onClick = () => {};
const onFieldCopy = () => {}; // 'on' is also acceptable
```
### Clarity Over Brevity
```typescript
// ✅ Prefer descriptive names over abbreviations
const superLongMethodThatIsCorrect = () => {};
const recipientAuthenticationOptions = {};
const documentMetadata = {};
// ❌ Avoid abbreviations that sacrifice clarity
const supLongMethThatIsCorrect = () => {};
const recipAuthOpts = {};
const docMeta = {};
// ✅ Common abbreviations that are widely understood are acceptable
const userId = 123;
const htmlElement = document.querySelector('div');
const apiResponse = await fetch('/api');
```
---
## Pattern Matching
### Using ts-pattern
```typescript
import { match } from 'ts-pattern';
// ✅ Use match for complex conditionals
const result = match(status)
.with(ExtendedDocumentStatus.DRAFT, () => ({
status: 'draft',
}))
.with(ExtendedDocumentStatus.PENDING, () => ({
status: 'pending',
}))
.with(ExtendedDocumentStatus.COMPLETED, () => ({
status: 'completed',
}))
.exhaustive();
// ✅ Use .otherwise() for default case when not exhaustive
const value = match(type)
.with('text', () => 'Text field')
.with('number', () => 'Number field')
.otherwise(() => 'Unknown field');
```
---
## Database & Prisma
### Query Structure
```typescript
// ✅ Destructure commonly used fields
const { id, email, name } = user;
// ✅ Use select to limit returned fields
const user = await prisma.user.findFirst({
where: { id: userId },
select: {
id: true,
email: true,
name: true,
},
});
// ✅ Use include for relations
const document = await prisma.document.findFirst({
where: { id: documentId },
include: {
recipients: true,
fields: true,
},
});
```
### Transactions
```typescript
// ✅ Use transactions for related operations
return await prisma.$transaction(async (tx) => {
const document = await tx.document.create({ data });
await tx.field.createMany({ data: fieldsData });
await tx.documentAuditLog.create({ data: auditData });
return document;
});
```
### Where Clauses
```typescript
// ✅ Build complex where clauses separately
const whereClause: Prisma.DocumentWhereInput = {
AND: [
{ userId: user.id },
{ deletedAt: null },
{ status: { in: [DocumentStatus.DRAFT, DocumentStatus.PENDING] } },
],
};
const documents = await prisma.document.findMany({
where: whereClause,
});
```
---
## TRPC Patterns
### Router Structure
```typescript
// ✅ Destructure context and input at start
.query(async ({ input, ctx }) => {
const { teamId } = ctx;
const { templateId } = input;
ctx.logger.info({
input: { templateId },
});
return await getTemplateById({
id: templateId,
userId: ctx.user.id,
teamId,
});
});
```
### Request/Response Schemas
```typescript
// ✅ Name schemas clearly
const ZCreateDocumentRequestSchema = z.object({
title: z.string(),
recipients: z.array(ZRecipientSchema),
});
const ZCreateDocumentResponseSchema = z.object({
documentId: z.number(),
status: z.string(),
});
```
### Error Handling in TRPC
```typescript
// ✅ Catch and transform errors appropriately
try {
const result = await createDocument({ userId, data });
return result;
} catch (err) {
return AppError.toRestAPIError(err);
}
// ✅ Or throw AppError directly
if (!template) {
throw new AppError(AppErrorCode.NOT_FOUND, {
message: 'Template not found',
});
}
```
---
## Additional Patterns
### Optional Chaining
```typescript
// ✅ Use optional chaining for potentially undefined values
const email = user?.email;
const recipientToken = recipient?.token ?? '';
// ✅ Use nullish coalescing for defaults
const pageSize = perPage ?? 10;
const status = documentStatus ?? DocumentStatus.DRAFT;
```
### Array Operations
```typescript
// ✅ Use functional array methods
const activeRecipients = recipients.filter((r) => r.signingStatus === 'SIGNED');
const recipientEmails = recipients.map((r) => r.email);
const hasSignedRecipients = recipients.some((r) => r.signingStatus === 'SIGNED');
// ✅ Use find instead of filter + [0]
const recipient = recipients.find((r) => r.id === recipientId);
```
### Conditional Rendering
```typescript
// ✅ Use && for conditional rendering
{isLoading && <Loader />}
// ✅ Use ternary for either/or
{isLoading ? <Loader /> : <Content />}
// ✅ Extract complex conditions to variables
const shouldShowAdvanced = isAdmin && hasPermission && !isDisabled;
{shouldShowAdvanced && <AdvancedSettings />}
```
---
## When in Doubt
- **Consistency**: Follow the patterns you see in similar files
- **Readability**: Favor code that's easy to read over clever one-liners
- **Explicitness**: Be explicit rather than implicit
- **Whitespace**: Use blank lines to separate logical sections
- **Early Returns**: Use guard clauses to reduce nesting
- **Functional**: Prefer functional patterns over imperative ones
+50
View File
@@ -52,3 +52,53 @@ You can build the project with:
```bash
npm run build
```
## AI-Assisted Development with OpenCode
We use [OpenCode](https://opencode.ai) for AI-assisted development. OpenCode provides custom commands and skills to help maintain consistency and streamline common workflows.
OpenCode works with most major AI providers (Anthropic, OpenAI, Google, etc.) or you can use [Zen](https://opencode.ai/zen) for optimized coding models. Configure your preferred provider in the OpenCode settings.
> **Important**: All AI-generated code must be thoroughly reviewed by the contributor before submitting a PR. You are responsible for understanding and validating every line of code you submit. If we detect that contributors are simply throwing AI-generated code over the wall without proper review, they will be blocked from the repository.
### Getting Started
1. Install OpenCode (see [opencode.ai](https://opencode.ai) for other install methods):
```bash
curl -fsSL https://opencode.ai/install | bash
```
2. Configure your AI provider (or use Zen for optimized models)
3. Run `opencode` in the project root
### Available Commands
Use these commands in OpenCode by typing the command name:
| Command | Description |
| ------------------------------ | -------------------------------------------------------- |
| `/implement <spec-path>` | Implement a spec from `.agents/plans/` autonomously |
| `/continue <spec-path>` | Continue implementing a spec from a previous session |
| `/interview <file-path>` | Deep-dive interview to flesh out a spec or design |
| `/document <module-path>` | Generate MDX documentation for a module or feature |
| `/commit` | Create a conventional commit for staged changes |
| `/create-plan <slug>` | Create a new plan file in `.agents/plans/` |
| `/create-scratch <slug>` | Create a scratch file for notes in `.agents/scratches/` |
| `/create-justification <slug>` | Create a justification file in `.agents/justifications/` |
### Typical Workflow
1. **Create a plan**: Use `/create-plan my-feature` to draft a spec for a new feature
2. **Flesh out the spec**: Use `/interview .agents/plans/<file>.md` to refine requirements
3. **Implement**: Use `/implement .agents/plans/<file>.md` to build the feature
4. **Continue if needed**: Use `/continue .agents/plans/<file>.md` to pick up where you left off
5. **Commit**: Use `/commit` to create a conventional commit
### Agent Files
The `.agents/` directory stores AI-generated artifacts:
- **`.agents/plans/`** - Feature specs and implementation plans
- **`.agents/scratches/`** - Temporary notes and explorations
- **`.agents/justifications/`** - Decision rationale and technical justifications
These files use a unique ID format (`{word}-{word}-{word}-{slug}.md`) to prevent conflicts.
+4 -2
View File
@@ -171,9 +171,11 @@ git clone https://github.com/<your-username>/documenso
5. Create the database schema by running `npm run prisma:migrate-dev`
6. Run `npm run dev` in the root directory to start
6. Run `npm run translate:compile` in the root directory to compile lingui
7. Register a new user at http://localhost:3000/signup
7. Run `npm run dev` in the root directory to start
8. Register a new user at http://localhost:3000/signup
---
@@ -1,7 +1,8 @@
import type { NextConfig } from 'next';
import nextra from 'nextra';
/** @type {import('next').NextConfig} */
const nextConfig = {
const nextConfig: NextConfig = {
transpilePackages: [
'@documenso/assets',
'@documenso/lib',
+7 -7
View File
@@ -4,7 +4,7 @@
"private": true,
"scripts": {
"dev": "next dev -p 3002",
"build": "next build && next-sitemap",
"build": "next build",
"start": "next start -p 3002",
"lint:fix": "next lint --fix",
"clean": "rimraf .next && rimraf node_modules"
@@ -15,18 +15,18 @@
"@documenso/tailwind-config": "*",
"@documenso/trpc": "*",
"@documenso/ui": "*",
"next": "14.2.28",
"next-plausible": "^3.12.0",
"nextra": "^2.13.4",
"nextra-theme-docs": "^2.13.4",
"next": "15.5.9",
"next-plausible": "^3.12.5",
"nextra": "^3",
"nextra-theme-docs": "^3",
"react": "^18",
"react-dom": "^18"
},
"devDependencies": {
"@types/node": "^20",
"@types/react": "^18",
"@types/react": "18.3.27",
"@types/react-dom": "^18",
"next-sitemap": "^4.2.3",
"pagefind": "^1.2.0",
"typescript": "5.6.2"
}
}
-10
View File
@@ -1,10 +0,0 @@
import { PlausibleProvider } from '../providers/plausible.tsx';
import '../styles.css';
export default function App({ Component, pageProps }) {
return (
<PlausibleProvider>
<Component {...pageProps} />
</PlausibleProvider>
);
}
+18
View File
@@ -0,0 +1,18 @@
/* eslint-disable @typescript-eslint/no-explicit-any */
import React from 'react';
import { PlausibleProvider } from '../providers/plausible';
import '../styles.css';
export type AppProps = {
Component: React.ComponentType<any>;
pageProps: any;
};
export default function App({ Component, pageProps }: AppProps) {
return (
<PlausibleProvider>
<Component {...pageProps} />
</PlausibleProvider>
);
}
+34
View File
@@ -0,0 +1,34 @@
export default {
index: {
type: 'page',
title: 'Home',
display: 'hidden',
theme: {
timestamp: false,
},
},
users: {
type: 'page',
title: 'Users',
},
developers: {
type: 'page',
title: 'Developers',
},
updates: {
title: "What's New",
type: 'menu',
items: {
changelog: {
title: 'Changelog',
href: 'https://documenso.com/changelog',
newWindow: true,
},
blog: {
title: 'Blog',
href: 'https://documenso.com/blog',
newWindow: true,
},
},
},
};
-34
View File
@@ -1,34 +0,0 @@
{
"index": {
"type": "page",
"title": "Home",
"display": "hidden",
"theme": {
"timestamp": false
}
},
"users": {
"type": "page",
"title": "Users"
},
"developers": {
"type": "page",
"title": "Developers"
},
"updates": {
"title": "What's New",
"type": "menu",
"items": {
"changelog": {
"title": "Changelog",
"href": "https://documenso.com/changelog",
"newWindow": true
},
"blog": {
"title": "Blog",
"href": "https://documenso.com/blog",
"newWindow": true
}
}
}
}
@@ -0,0 +1,19 @@
export default {
index: 'Introduction',
'-- Development & Deployment': {
type: 'separator',
title: 'Development & Deployment',
},
'local-development': 'Local Development',
'developer-mode': 'Developer Mode',
'self-hosting': 'Self Hosting',
contributing: 'Contributing',
'-- API & Integration Guides': {
type: 'separator',
title: 'API & Integration Guides',
},
'public-api': 'Public API',
embedding: 'Embedded Signing',
'embedded-authoring': 'Embedded Authoring',
webhooks: 'Webhooks',
};
@@ -1,18 +0,0 @@
{
"index": "Introduction",
"-- Development & Deployment": {
"type": "separator",
"title": "Development & Deployment"
},
"local-development": "Local Development",
"developer-mode": "Developer Mode",
"self-hosting": "Self Hosting",
"contributing": "Contributing",
"-- API & Integration Guides": {
"type": "separator",
"title": "API & Integration Guides"
},
"public-api": "Public API",
"embedding": "Embedding",
"webhooks": "Webhooks"
}
@@ -0,0 +1,4 @@
export default {
index: 'Getting Started',
'contributing-translations': 'Contributing Translations',
};
@@ -1,4 +0,0 @@
{
"index": "Getting Started",
"contributing-translations": "Contributing Translations"
}
@@ -5,14 +5,22 @@ description: Learn how to get the coordinates of a field in a document.
## Field Coordinates
Field coordinates represent the position of a field in a document. They are returned in the `pageX` and `pageY` properties of the field.
Field coordinates represent the position of a field in a document. They are returned in the `pageX`, `pageY`, `width` and `height` properties of the field.
To enable field coordinates, you can use the `devmode` query parameter.
```bash
https://app.documenso.com/documents/<document-id>/edit?devmode=true
# Legacy editor
https://app.documenso.com/t/<team-url>/documents/<envelope-id>/legacy_editor?devmode=true
```
You should then see the coordinates on top of each field.
![Field Coordinates Legacy Editor](/developer-mode/field-coordinates-legacy-editor.webp)
![Field Coordinates](/developer-mode/field-coordinates.webp)
```bash
# New editor
https://app.documenso.com/t/<team-url>/documents/<envelope-id>/edit?step=addFields&devmode=true
```
![Field Coordinates New Editor](/developer-mode/field-coordinates-new-editor.webp)
@@ -0,0 +1,396 @@
---
title: Embedded Authoring
description: Learn how to use embedded authoring to create documents and templates in your application
---
import { Callout } from 'nextra/components';
<Callout type="info">
The embedded authoring feature is an enterprise only feature. Please contact us if you are
interested in using it.
</Callout>
# Embedded Authoring
In addition to embedding signing experiences, Documenso now supports embedded authoring, allowing you to integrate document and template creation and editing directly within your application.
## Embedded Signing vs Embedded Authoring
Embedded signing allows you to embed your Documenso documents into your application for signing. Your users will be able to sign the document directly in your application.
Embedded authoring allows you to integrate Documenso's document and template creation and editing into your application. You will be able to create and edit documents and templates directly in your application.
## How Embedded Authoring Works
The embedded authoring feature enables your users to create and edit documents and templates without leaving your application. This process works through secure presign tokens that authenticate the embedding session and manage permissions.
## Available Components
The SDK provides four authoring components:
- **`EmbedCreateDocumentV1`** - Create new documents
- **`EmbedCreateTemplateV1`** - Create new templates
- **`EmbedUpdateDocumentV1`** - Edit existing documents
- **`EmbedUpdateTemplateV1`** - Edit existing templates
React Example:
```jsx
import {
EmbedCreateDocumentV1,
EmbedCreateTemplateV1,
EmbedUpdateDocumentV1,
EmbedUpdateTemplateV1,
} from '@documenso/embed-react';
```
## Creating Documents
To implement document creation in your application, use the `EmbedCreateDocumentV1` component:
```jsx
import { EmbedCreateDocumentV1 } from '@documenso/embed-react';
const DocumentCreator = () => {
// You'll need to obtain a presign token using your API key
const presignToken = 'YOUR_PRESIGN_TOKEN';
return (
<div style={{ height: '800px', width: '100%' }}>
<EmbedCreateDocument
presignToken={presignToken}
externalId="order-12345"
onDocumentCreated={(data) => {
console.log('Document created with ID:', data.documentId);
console.log('External reference ID:', data.externalId);
}}
/>
</div>
);
};
```
## Creating Templates
To create templates, use the `EmbedCreateTemplateV1` component:
```jsx
import { EmbedCreateTemplateV1 } from '@documenso/embed-react';
const TemplateCreator = () => {
const presignToken = 'YOUR_PRESIGN_TOKEN';
return (
<div style={{ height: '800px', width: '100%' }}>
<EmbedCreateTemplate
presignToken={presignToken}
externalId="template-12345"
onTemplateCreated={(data) => {
console.log('Template created with ID:', data.templateId);
console.log('External reference ID:', data.externalId);
}}
/>
</div>
);
};
```
## Updating Documents
To edit existing documents, use the `EmbedUpdateDocumentV1` component:
```jsx
import { EmbedUpdateDocumentV1 } from '@documenso/embed-react';
const DocumentEditor = () => {
const presignToken = 'YOUR_PRESIGN_TOKEN';
const documentId = 123; // The ID of the document to edit
return (
<div style={{ height: '800px', width: '100%' }}>
<EmbedUpdateDocument
presignToken={presignToken}
documentId={documentId}
externalId="order-12345"
onlyEditFields={false}
onDocumentUpdated={(data) => {
console.log('Document updated:', data.documentId);
}}
/>
</div>
);
};
```
## Updating Templates
To edit existing templates, use the `EmbedUpdateTemplateV1` component:
```jsx
import { EmbedUpdateTemplateV1 } from '@documenso/embed-react';
const TemplateEditor = () => {
const presignToken = 'YOUR_PRESIGN_TOKEN';
const templateId = 456; // The ID of the template to edit
return (
<div style={{ height: '800px', width: '100%' }}>
<EmbedUpdateTemplate
presignToken={presignToken}
templateId={templateId}
externalId="template-12345"
onlyEditFields={false}
onTemplateUpdated={(data) => {
console.log('Template updated:', data.templateId);
}}
/>
</div>
);
};
```
## Obtaining a Presign Token
Before using any of the authoring components, you'll need to obtain a presign token from your backend. This token authorizes the embedding session.
You can create a presign token by making a request to:
```
POST /api/v2/embedding/create-presign-token
```
This API endpoint requires authentication with your Documenso API key. The token has a default expiration of 1 hour, but you can customize this duration based on your security requirements.
You can find more details on this request at our [API Documentation](https://openapi.documenso.com/reference#tag/embedding)
## Configuration Options
All authoring components accept the following configuration options:
| Option | Type | Description |
| ------------------ | ------- | -------------------------------------------------------------------------- |
| `presignToken` | string | **Required**. The authentication token for the embedding session. |
| `externalId` | string | Optional reference ID from your system to link with the document/template. |
| `host` | string | Optional custom host URL. Defaults to `https://app.documenso.com`. |
| `css` | string | Optional custom CSS to style the embedded component. |
| `cssVars` | object | Optional CSS variables for colors, spacing, and more. |
| `darkModeDisabled` | boolean | Optional flag to disable dark mode. |
| `className` | string | Optional CSS class name for the iframe. |
| `additionalProps` | object | Optional additional props to pass to the iframe (for testing features). |
| `features` | object | Optional feature toggles to customize the authoring experience. |
### Update Component Specific Props
The `EmbedUpdateDocument` and `EmbedUpdateTemplate` components also accept:
| Option | Type | Description |
| ---------------- | ------- | -------------------------------------------------------------------------------------------------------------- |
| `documentId` | number | **Required for EmbedUpdateDocument**. The ID of the document to edit. |
| `templateId` | number | **Required for EmbedUpdateTemplate**. The ID of the template to edit. |
| `onlyEditFields` | boolean | Optional flag to restrict editing to fields only skipping the recipient configuration step (default: `false`). |
## Feature Toggles
You can customize the authoring experience by enabling or disabling specific features:
```jsx
<EmbedCreateDocument
presignToken="YOUR_PRESIGN_TOKEN"
features={{
allowConfigureSignatureTypes: true,
allowConfigureLanguage: true,
allowConfigureDateFormat: true,
allowConfigureTimezone: true,
allowConfigureRedirectUrl: true,
allowConfigureCommunication: true,
}}
/>
```
## Handling Events
Each component provides callbacks for handling completion events:
### Document Events
```jsx
<EmbedCreateDocument
presignToken="YOUR_PRESIGN_TOKEN"
externalId="order-12345"
onDocumentCreated={(data) => {
// Navigate to a success page
navigate(`/documents/success?id=${data.documentId}`);
// Or update your database with the document ID
updateOrderDocument(data.externalId, data.documentId);
}}
/>
<EmbedUpdateDocument
presignToken="YOUR_PRESIGN_TOKEN"
documentId={123}
onDocumentUpdated={(data) => {
console.log('Document updated:', data.documentId);
// Handle document update
}}
/>
```
### Template Events
```jsx
<EmbedCreateTemplate
presignToken="YOUR_PRESIGN_TOKEN"
externalId="template-12345"
onTemplateCreated={(data) => {
console.log('Template created:', data.templateId);
// Handle template creation
}}
/>
<EmbedUpdateTemplate
presignToken="YOUR_PRESIGN_TOKEN"
templateId={456}
onTemplateUpdated={(data) => {
console.log('Template updated:', data.templateId);
// Handle template update
}}
/>
```
All event callbacks receive an object with:
- `documentId` or `templateId` - The ID of the created/updated document or template
- `externalId` - Your external reference ID (if provided)
## Styling the Embedded Component
You can customize the appearance of the embedded component using standard CSS classes, custom CSS, and CSS variables:
```jsx
<EmbedCreateDocument
className="h-screen w-full rounded-lg border-none shadow-md"
presignToken="YOUR_PRESIGN_TOKEN"
css={`
.documenso-embed {
border-radius: 8px;
box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
}
`}
cssVars={{
primary: '#0000FF',
background: '#F5F5F5',
radius: '8px',
}}
/>
```
## Complete Integration Example
Here's a complete example of integrating document creation in a React application:
```tsx
import { useState } from 'react';
import { EmbedCreateDocumentV1, EmbedUpdateDocumentV1 } from '@documenso/embed-react';
function DocumentManager() {
// In a real application, you would fetch this token from your backend
// using your API key at /api/v2/embedding/create-presign-token
const presignToken = 'YOUR_PRESIGN_TOKEN';
const [documentId, setDocumentId] = useState<number | null>(null);
const [mode, setMode] = useState<'create' | 'edit'>('create');
if (documentId && mode === 'create') {
return (
<div>
<h2>Document Created Successfully!</h2>
<p>Document ID: {documentId}</p>
<div>
<button onClick={() => setMode('edit')}>Edit Document</button>
<button
onClick={() => {
setDocumentId(null);
setMode('create');
}}
>
Create Another Document
</button>
</div>
</div>
);
}
if (mode === 'edit' && documentId) {
return (
<div style={{ height: '800px', width: '100%' }}>
<button onClick={() => setMode('create')}>Back to Create</button>
<EmbedUpdateDocument
presignToken={presignToken}
documentId={documentId}
externalId="order-12345"
onDocumentUpdated={(data) => {
console.log('Document updated:', data.documentId);
setMode('create');
}}
/>
</div>
);
}
return (
<div style={{ height: '800px', width: '100%' }}>
<EmbedCreateDocument
presignToken={presignToken}
externalId="order-12345"
features={{
allowConfigureSignatureTypes: true,
allowConfigureLanguage: true,
allowConfigureDateFormat: true,
allowConfigureTimezone: true,
allowConfigureRedirectUrl: true,
allowConfigureCommunication: true,
}}
onDocumentCreated={(data) => {
setDocumentId(data.documentId);
}}
/>
</div>
);
}
export default DocumentManager;
```
## Advanced Usage
### Using Additional Props
You can pass additional props to the iframe for testing features before they're officially supported:
```jsx
<EmbedCreateDocument
presignToken="YOUR_PRESIGN_TOKEN"
additionalProps={{
experimentalFeature: true,
customSetting: 'value',
}}
/>
```
### Restricting To Only Field Editing
When updating documents or templates, you can restrict editing to fields only skipping the recipient configuration step:
```jsx
<EmbedUpdateDocument
presignToken="YOUR_PRESIGN_TOKEN"
documentId={123}
onlyEditFields={true}
onDocumentUpdated={(data) => {
console.log('Fields updated:', data.documentId);
}}
/>
```
With embedded authoring, your users can seamlessly create and edit documents and templates within your application, enhancing the overall user experience and streamlining document workflows.
@@ -0,0 +1,10 @@
export default {
index: 'Get Started',
react: 'React Integration',
vue: 'Vue Integration',
svelte: 'Svelte Integration',
solid: 'Solid Integration',
preact: 'Preact Integration',
angular: 'Angular Integration',
'css-variables': 'CSS Variables',
};
@@ -1,11 +0,0 @@
{
"index": "Get Started",
"react": "React Integration",
"vue": "Vue Integration",
"svelte": "Svelte Integration",
"solid": "Solid Integration",
"preact": "Preact Integration",
"angular": "Angular Integration",
"css-variables": "CSS Variables",
"authoring": "Authoring"
}
@@ -1,167 +0,0 @@
---
title: Authoring
description: Learn how to use embedded authoring to create documents and templates in your application
---
# Embedded Authoring
In addition to embedding signing experiences, Documenso now supports embedded authoring, allowing you to integrate document and template creation directly within your application.
## How Embedded Authoring Works
The embedded authoring feature enables your users to create new documents without leaving your application. This process works through secure presign tokens that authenticate the embedding session and manage permissions.
## Creating Documents with Embedded Authoring
To implement document creation in your application, use the `EmbedCreateDocument` component from our SDK:
```jsx
import { unstable_EmbedCreateDocument as EmbedCreateDocument } from '@documenso/embed-react';
const DocumentCreator = () => {
// You'll need to obtain a presign token using your API key
const presignToken = 'YOUR_PRESIGN_TOKEN';
return (
<div style={{ height: '800px', width: '100%' }}>
<EmbedCreateDocument
presignToken={presignToken}
externalId="order-12345"
onDocumentCreated={(data) => {
console.log('Document created with ID:', data.documentId);
console.log('External reference ID:', data.externalId);
}}
/>
</div>
);
};
```
## Obtaining a Presign Token
Before using the `EmbedCreateDocument` component, you'll need to obtain a presign token from your backend. This token authorizes the embedding session.
You can create a presign token by making a request to:
```
POST /api/v2-beta/embedding/create-presign-token
```
This API endpoint requires authentication with your Documenso API key. The token has a default expiration of 1 hour, but you can customize this duration based on your security requirements.
You can find more details on this request at our [API Documentation](https://openapi.documenso.com/reference#tag/embedding)
## Configuration Options
The `EmbedCreateDocument` component accepts several configuration options:
| Option | Type | Description |
| ------------------ | ------- | ------------------------------------------------------------------ |
| `presignToken` | string | **Required**. The authentication token for the embedding session. |
| `externalId` | string | Optional reference ID from your system to link with the document. |
| `host` | string | Optional custom host URL. Defaults to `https://app.documenso.com`. |
| `css` | string | Optional custom CSS to style the embedded component. |
| `cssVars` | object | Optional CSS variables for colors, spacing, and more. |
| `darkModeDisabled` | boolean | Optional flag to disable dark mode. |
| `className` | string | Optional CSS class name for the iframe. |
## Feature Toggles
You can customize the authoring experience by enabling or disabling specific features:
```jsx
<EmbedCreateDocument
presignToken="YOUR_PRESIGN_TOKEN"
features={{
allowConfigureSignatureTypes: true,
allowConfigureLanguage: true,
allowConfigureDateFormat: true,
allowConfigureTimezone: true,
allowConfigureRedirectUrl: true,
allowConfigureCommunication: true,
}}
/>
```
## Handling Document Creation Events
The `onDocumentCreated` callback is triggered when a document is successfully created, providing both the document ID and your external reference ID:
```jsx
<EmbedCreateDocument
presignToken="YOUR_PRESIGN_TOKEN"
externalId="order-12345"
onDocumentCreated={(data) => {
// Navigate to a success page
navigate(`/documents/success?id=${data.documentId}`);
// Or update your database with the document ID
updateOrderDocument(data.externalId, data.documentId);
}}
/>
```
## Styling the Embedded Component
You can customize the appearance of the embedded component using standard CSS classes:
```jsx
<EmbedCreateDocument
className="h-screen w-full rounded-lg border-none shadow-md"
presignToken="YOUR_PRESIGN_TOKEN"
css={`
.documenso-embed {
border-radius: 8px;
box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
}
`}
cssVars={{
primary: '#0000FF',
background: '#F5F5F5',
radius: '8px',
}}
/>
```
## Complete Integration Example
Here's a complete example of integrating document creation in a React application:
```tsx
import { useState } from 'react';
import { unstable_EmbedCreateDocument as EmbedCreateDocument } from '@documenso/embed-react';
function DocumentCreator() {
// In a real application, you would fetch this token from your backend
// using your API key at /api/v2-beta/embedding/create-presign-token
const presignToken = 'YOUR_PRESIGN_TOKEN';
const [documentId, setDocumentId] = useState<number | null>(null);
if (documentId) {
return (
<div>
<h2>Document Created Successfully!</h2>
<p>Document ID: {documentId}</p>
<button onClick={() => setDocumentId(null)}>Create Another Document</button>
</div>
);
}
return (
<div style={{ height: '800px', width: '100%' }}>
<EmbedCreateDocument
presignToken={presignToken}
externalId="order-12345"
onDocumentCreated={(data) => {
setDocumentId(data.documentId);
}}
/>
</div>
);
}
export default DocumentCreator;
```
With embedded authoring, your users can seamlessly create documents within your application, enhancing the overall user experience and streamlining document workflows.
@@ -3,10 +3,16 @@ title: Get Started
description: Learn how to use embedding to bring signing to your own website or application
---
# Embedding
# Embedded Signing
Our embedding feature lets you integrate our document signing experience into your own application or website. Whether you're building with React, Preact, Vue, Svelte, Solid, Angular, or using generalized web components, this guide will help you get started with embedding Documenso.
## Embedded Signing vs Embedded Authoring
Embedded signing allows you to embed your Documenso documents into your application for signing. Your users will be able to sign the document directly in your application.
Embedded authoring allows you to integrate Documenso's document and template creation and editing into your application. You will be able to create and edit documents and templates directly in your application.
## Availability
Embedding is currently available for all users on a **Teams Plan** and above, as well as **Early Adopter's** within a team (Early Adopters can create a team for free).
@@ -3,16 +3,16 @@ title: Developer Documentation
description: Learn how to run Documenso locally, use our API, integrate webhooks, contribute to the project, and self-host Documenso.
---
import { Card, Cards } from 'nextra/components';
import { Cards } from 'nextra/components';
# Developer Documentation
The developer documentation is a comprehensive guide to help you:
<Cards>
<Card title="Set up dev environment" href="/developers/local-development" />
<Card title="Use the API" href="/developers/public-api" />
<Card title="Integrate webhooks" href="/developers/webhooks" />
<Card title="Contribute to the project" href="/developers/contributing" />
<Card title="Self-host Documenso" href="/developers/self-hosting" />
<Cards.Card title="Set up dev environment" href="/developers/local-development" />
<Cards.Card title="Use the API" href="/developers/public-api" />
<Cards.Card title="Integrate webhooks" href="/developers/webhooks" />
<Cards.Card title="Contribute to the project" href="/developers/contributing" />
<Cards.Card title="Self-host Documenso" href="/developers/self-hosting" />
</Cards>
@@ -0,0 +1,8 @@
export default {
index: 'Get Started',
quickstart: 'Developer Quickstart',
manual: 'Manual Setup',
gitpod: 'Gitpod',
'signing-certificate': 'Signing Certificate',
translations: 'Translations',
};
@@ -1,8 +0,0 @@
{
"index": "Get Started",
"quickstart": "Developer Quickstart",
"manual": "Manual Setup",
"gitpod": "Gitpod",
"signing-certificate": "Signing Certificate",
"translations": "Translations"
}
@@ -61,6 +61,6 @@ You can access the following services:
- Main application - http://localhost:3000
- Incoming Mail Access - http://localhost:9000
- Database Connection Details:
- Port: 54320
- Connection: Use your favourite database client to connect to the database.
- Port: 54320
- Connection: Use your favorite database client to connect to the database.
- S3 Storage Dashboard - http://localhost:9001
@@ -0,0 +1,6 @@
export default {
index: 'Get Started',
authentication: 'Authentication',
'rate-limits': 'Rate Limits',
versioning: 'Versioning',
};
@@ -1,6 +0,0 @@
{
"index": "Get Started",
"authentication": "Authentication",
"rate-limits": "Rate Limits",
"versioning": "Versioning"
}
@@ -9,11 +9,11 @@ Documenso uses API keys for authentication. An API key is a unique token that is
## Creating an API Key
To create an API key, navigate to the user settings page. Click on your avatar in the top right corner of the dashboard and select "**[User settings](https://app.documenso.com/settings)**" from the dropdown menu.
To create an API key, navigate to the user settings page. Click on your avatar in the top right corner of the dashboard and select "Team Settings" from the dropdown menu.
![A screenshot of the Documenso's dashboard that shows the dropdown menu when you click on your user avatar](/public-api-images/documenso-user-dropdown-menu.webp)
Once you're on the user settings page, navigate to the "**[API Tokens](https://app.documenso.com/settings/tokens)**" tab. The "API Token" page lists your existing keys and enables you to create new ones.
Once you're on the settings page, navigate to the **API Tokens** tab. This page lists your existing keys and enables you to create new ones.
![A screenshot of the Documenso's user settings page that shows the API Tokens page](/public-api-images/api-tokens-page-documenso.webp)
@@ -37,31 +37,17 @@ You must include the API key in the `Authorization` request header to authentica
Here's a sample API request using cURL:
```bash
curl --location 'https://app.documenso.com/api/v1/documents?page=1&perPage=1' \
--header 'Authorization: api_xxxxxxxxxxxxxxxx'
curl --location 'https://app.documenso.com/api/v2/envelope/create' \
--header 'Authorization: api_xxxxxxxxxxxxxxxx' \
--form 'payload={ "title": "Some Title", "type": "DOCUMENT" }'
```
Here's a sample response from the API based on the above cURL request:
```json
{
"documents": [
{
"id": 11,
"userId": 2,
"teamId": null,
"title": "documenso",
"status": "PENDING",
"documentDataId": "ab2ecm1npk11rt5sp398waf7h",
"createdAt": "2024-04-25T11:05:18.420Z",
"updatedAt": "2024-04-25T11:05:36.328Z",
"completedAt": null
}
],
"totalPages": 1
"id": "envelope_xxxxxxxxxxxxx"
}
```
![A screenshot of a cURL request to the Documenso public API with the API key in the Authorization header](/public-api-images/documenso-api-authorization.webp)
The API key has access to your account and all its resources. Please keep it secure and do not share it with others. If you suspect your key has been compromised, you can revoke it from the "API Tokens" page in your user settings.
The API key has access to your account and all its resources. Please keep it secure and do not share it with others. If you suspect your key has been compromised, you can revoke it from the same page you created it from.
@@ -9,19 +9,13 @@ import { Callout, Steps } from 'nextra/components';
Documenso provides a public REST API enabling you to interact with your documents programmatically. The API exposes various HTTP endpoints that allow you to perform operations such as:
- retrieving, uploading, deleting, and sending documents for signing
- creating, updating, and deleting recipients
- creating, updating, and deleting document fields
- Retrieving, uploading, deleting, and sending documents for signing
- Creating, updating, and deleting recipients
- Creating, updating, and deleting document fields
The documentation walks you through creating API keys and using them to authenticate your API requests. You'll also learn about the available endpoints, request and response formats, and how to use the API.
## API V1 - Stable
Check out the [API V1 documentation](https://app.documenso.com/api/v1/openapi) for details about the API endpoints, request parameters, response formats, and authentication methods.
## API V2 - Beta
<Callout type="warning">API V2 is currently beta, and will be subject to breaking changes</Callout>
## API V2 - Stable
Check out the [API V2 documentation](https://documen.so/api-v2-docs) for details about the API endpoints, request parameters, response formats, and authentication methods.
@@ -32,17 +26,23 @@ Our new API V2 supports the following typed SDKs:
- [Go](https://github.com/documenso/sdk-go)
<Callout type="info">
For the staging API, please use the following base URL:
`https://stg-app.documenso.com/api/v2-beta/`
For the staging API, please use the following base URL: `https://stg-app.documenso.com/api/v2/`
</Callout>
🚀 [V2 Announcement](https://documen.so/sdk-blog)
## API V1 - Deprecated
📖 [Documentation](https://documen.so/api-v2-docs)
<Callout type="warning">
<strong>API V1 is deprecated.</strong>
<br />
The V1 API will continue to be supported for the foreseeable future, but it is limited to
<strong>Legacy Documents</strong> (Documents created using the old non-envelope editor).
💬 [Leave Feedback](https://documen.so/sdk-feedback)
<strong>Important:</strong> To work with the new <strong>Envelope</strong> document system, you
must use the
<strong> V2 API</strong>.
</Callout>
🔔 [Breaking Changes](https://documen.so/sdk-breaking)
Check out the [API V1 documentation](https://app.documenso.com/api/v1/openapi) for details about the API endpoints, request parameters, response formats, and authentication methods.
## Availability
@@ -1,3 +1,8 @@
---
title: Rate Limits
description: Learn about the rate limits for the Documenso Public API.
---
import { Callout } from 'nextra/components';
# Rate Limits
@@ -7,550 +7,246 @@ import { Callout, Steps } from 'nextra/components';
# API Reference
The Swagger UI for the API is available at [/api/v1/openapi](https://app.documenso.com/api/v1/openapi). This page provides detailed information about the API endpoints, request and response formats, and authentication requirements.
## Upload a Document
Uploading a document to your Documenso account requires a two-step process.
<Steps>
### Create Document
First, you need to make a `POST` request to the `/api/v1/documents` endpoint, which takes a JSON payload with the following fields:
```json
{
"title": "string",
"externalId": "string",
"recipients": [
{
"name": "string",
"email": "user@example.com",
"role": "SIGNER",
"signingOrder": 0
}
],
"meta": {
"subject": "string",
"message": "string",
"timezone": "Etc/UTC",
"dateFormat": "yyyy-MM-dd hh:mm a",
"redirectUrl": "string",
"signingOrder": "PARALLEL"
},
"authOptions": {
"globalAccessAuth": "ACCOUNT",
"globalActionAuth": "ACCOUNT"
},
"formValues": {
"additionalProp1": "string",
"additionalProp2": "string",
"additionalProp3": "string"
}
}
```
- `title` _(required)_ - This represents the document's title.
- `externalId` - This is an optional field that you can use to store an external identifier for the document. This can be useful for tracking the document in your system.
- `recipients` _(required)_ - This is an array of recipient objects. Each recipient object has the following fields:
- `name` - The name of the recipient.
- `email` - The email address of the recipient.
- `role` - The role of the recipient. See the [available roles](/users/signing-documents#roles).
- `signingOrder` - The order in which the recipient should sign the document. This is an integer value starting from 0.
- `meta` - This object contains additional metadata for the document. It has the following fields:
- `subject` - The subject of the email that will be sent to the recipients.
- `message` - The message of the email that will be sent to the recipients.
- `timezone` - The timezone in which the document should be signed.
- `dateFormat` - The date format that should be used in the document.
- `redirectUrl` - The URL to which the user should be redirected after signing the document.
- `signingOrder` - The signing order for the document. This can be either `SEQUENTIAL` or `PARALLEL`.
- `authOptions` - This object contains authentication options for the document. It has the following fields:
- `globalAccessAuth` - The authentication level required to access the document. This can be either `ACCOUNT` or `null`.
- If the document is set to `ACCOUNT`, all recipients must authenticate with their Documenso account to access it.
- The document can be accessed without a Documenso account if it's set to `null`.
- `globalActionAuth` - The authentication level required to perform actions on the document. This can be `ACCOUNT`, `PASSKEY`, `TWO_FACTOR_AUTH`, or `null`.
- If the document is set to `ACCOUNT`, all recipients must authenticate with their Documenso account to perform actions on the document.
- If it's set to `PASSKEY`, all recipients must have the passkey active to perform actions on the document.
- If it's set to `TWO_FACTOR_AUTH`, all recipients must have the two-factor authentication active to perform actions on the document.
- If it's set to `null`, all the recipients can perform actions on the document without any authentication.
- `formValues` - This object contains additional form values for the document. This property only works with native PDF fields and accepts three types: number, text and boolean.
On this page we will refer to both Documents and Templates as Envelopes for convenience, unless otherwise specified.
<Callout type="info">
The `globalActionAuth` property is only available for Enterprise accounts.
This page is used to demonstrate some of the endpoints and how to use them. For the full API
reference, please see the [API Reference](https://openapi.documenso.com/).
</Callout>
Here's an example of the JSON payload for uploading a document:
## Get Envelope
```json
{
"title": "my-document.pdf",
"externalId": "12345",
"recipients": [
{
"name": "Alex Blake",
"email": "alexblake@email.com",
"role": "SIGNER",
"signingOrder": 1
},
{
"name": "Ash Drew",
"email": "ashdrew@email.com",
"role": "SIGNER",
"signingOrder": 0
}
],
"meta": {
"subject": "Sign the document",
"message": "Hey there, please sign this document.",
"timezone": "Europe/London",
"dateFormat": "Day, Month Year",
"redirectUrl": "https://mysite.com/welcome",
"signingOrder": "SEQUENTIAL"
},
"authOptions": {
"globalAccessAuth": "ACCOUNT",
"globalActionAuth": "PASSKEY"
}
}
For the vast majority of use cases, you will need to retrieve the envelope to get details for further operations.
The main details you generally want to extract are the following:
- **Recipients** - The individuals who will be signing the document
- **Fields** - The fields the user will sign
- **Items** - The PDF files the user will see and sign
This is done by doing a the following GET [request](https://openapi.documenso.com/reference#tag/envelope/POST/envelope/create)
```sh
curl -X GET "https://app.documenso.com/api/v2/envelope/envelope_xxxxxxxxxxxxx" \
-H "Authorization: api_xxxxxxxxxxxxxx"
```
### Upload to S3
A successful API call to the `/api/v1/documents` endpoint returns a JSON response containing the upload URL, document ID, and recipient information.
The upload URL is a pre-signed S3 URL that you can use to upload the document to the Documenso (or your) S3 bucket. You need to make a `PUT` request to this URL to upload the document.
```json
{
"uploadUrl": "https://<url>/<bucket-name>/<id>/my-document.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=<credentials>&X-Amz-Date=<date>&X-Amz-Expires=3600&X-Amz-Signature=<signature>&X-Amz-SignedHeaders=host&x-id=PutObject",
"documentId": 51,
"recipients": [
{
"recipientId": 11,
"name": "Alex Blake",
"email": "alexblake@email.com",
"token": "<unique-signer-token>",
"role": "SIGNER",
"signingOrder": 1,
"signingUrl": "https://app.documenso.com/sign/<unique-signer-token>"
},
{
"recipientId": 12,
"name": "Ash Drew",
"email": "ashdrew@email.com",
"token": "<unique-signer-token>",
"role": "SIGNER",
"signingOrder": 0,
"signingUrl": "https://app.documenso.com/sign/<unique-signer-token>"
}
]
}
```
When you make the `PUT` request to the pre-signed URL, you need to include the document file you want to upload. The image below shows how to upload a document to the S3 bucket via Postman.
![Upload document to S3](/api-reference/upload-document-to-s3.webp)
Here's an example of how to upload a document using cURL:
```bash
curl --location --request PUT 'https://<url>/<bucket-name>/<id>/my-document.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=<credentials>&X-Amz-Date=<date>&X-Amz-Expires=3600&X-Amz-Signature=<signature>&X-Amz-SignedHeaders=host&x-id=PutObject' \
--form '=@"/Users/my-user/Documents/documenso.pdf"'
```
Once the document is successfully uploaded, you can access it in your Documenso account dashboard. The screenshot below shows the document that was uploaded via the API.
![Uploaded Document](/api-reference/document-uploaded-to-documenso-via-api.webp)
</Steps>
## Generate Document From Template
Documenso allows you to generate documents from templates. This is useful when you have a standard document format you want to reuse.
The API endpoint for generating a document from a template is `/api/v1/templates/{templateId}/generate-document`, and it takes a JSON payload with the following fields:
```json
{
"title": "string",
"externalId": "string",
"recipients": [
{
"id": 0,
"name": "string",
"email": "user@example.com",
"signingOrder": 0
}
],
"meta": {
"subject": "string",
"message": "string",
"timezone": "string",
"dateFormat": "string",
"redirectUrl": "string",
"signingOrder": "PARALLEL"
},
"authOptions": {
"globalAccessAuth": "ACCOUNT",
"globalActionAuth": "ACCOUNT"
},
"formValues": {
"additionalProp1": "string",
"additionalProp2": "string",
"additionalProp3": "string"
}
}
```
The JSON payload is identical to the payload for uploading a document, so you can read more about the fields in the [Create Document](/developers/public-api/reference#create-document) step. For this API endpoint, the `recipients` property is required.
<Steps>
### Grab the Template ID
The first step is to retrieve the template ID from the Documenso dashboard. You can find the template ID in the URL by navigating to the template details page.
![Template ID](/api-reference/documenso-template-id.webp)
In this case, the template ID is "99999".
### Retrieve the Recipient(s) ID(s)
Once you have the template ID, the next step involves retrieving the ID(s) of the recipient(s) from the template. You can do this by making a GET request to `/api/v1/templates/{template-id}`.
A successful response looks as follows:
```json
{
"id": 0,
"externalId": "string",
"type": "PUBLIC",
"title": "string",
"userId": 0,
"teamId": 0,
"templateDocumentDataId": "string",
"createdAt": "2024-10-11T08:46:58.247Z",
"updatedAt": "2024-10-11T08:46:58.247Z",
"templateMeta": {
"id": "string",
"subject": "string",
"message": "string",
"timezone": "string",
"dateFormat": "string",
"templateId": 0,
"redirectUrl": "string",
"signingOrder": "PARALLEL"
},
"directLink": {
"token": "string",
"enabled": true
},
"templateDocumentData": {
"id": "string",
"type": "S3_PATH",
"data": "string"
},
"Field": [
{
"id": 0,
"recipientId": 0,
"type": "SIGNATURE",
"page": 0,
"positionX": "string",
"positionY": "string",
"width": "string",
"height": "string"
}
],
"Recipient": [
{
"id": 0,
"email": "user@example.com",
"name": "string",
"signingOrder": 0,
"authOptions": "string",
"role": "CC"
}
]
}
```
You'll need the recipient(s) ID(s) for the next step.
### Generate the Document
To generate a document from the template, you need to make a POST request to the `/api/v1/templates/{template-id}/generate-document` endpoint.
At the minimum, you must provide the `recipients` array in the JSON payload. Here's an example of the JSON payload:
```json
{
"recipients": [
{
"id": 0,
"name": "Ash Drew",
"email": "ashdrew@email.com",
"signingOrder": 0
}
]
}
```
Filling the `recipients` array with the corresponding recipient for each template placeholder recipient is recommended. For example, if the template has two placeholders, you should provide at least two recipients in the `recipients` array. Otherwise, the document will be sent to inexistent recipients such as `<recipient.1@documenso.com>`. However, the recipients can always be edited via the API or the web app.
A successful response will contain the document ID and recipient(s) information.
```json
{
"documentId": 999,
"recipients": [
{
"recipientId": 0,
"name": "Ash Drew",
"email": "ashdrew@email.com",
"token": "<signing-token>",
"role": "SIGNER",
"signingOrder": null,
"signingUrl": "https://app.documenso.com/sign/<signing-token>"
}
]
}
```
You can now access the document in your Documenso account dashboard. The screenshot below shows the document that was generated from the template.
![Generated Document](/api-reference/document-generated-from-template.webp)
</Steps>
## Add Fields to Document
The API allows you to add fields to a document via the `/api/v1/documents/{documentId}/fields` endpoint. This is useful when you want to add fields to a document before sending it to recipients.
To add fields to a document, you need to make a `POST` request with a JSON payload containing the field(s) information.
```json
{
"recipientId": 0,
"type": "SIGNATURE",
"pageNumber": 0,
"pageX": 0,
"pageY": 0,
"pageWidth": 0,
"pageHeight": 0,
"fieldMeta": {
"label": "string",
"placeholder": "string",
"required": true,
"readOnly": true,
"type": "text",
"text": "string",
"characterLimit": 0
}
}
// or
[
{
"recipientId": 0,
"type": "SIGNATURE",
"pageNumber": 0,
"pageX": 0,
"pageY": 0,
"pageWidth": 0,
"pageHeight": 0
},
{
"recipientId": 0,
"type": "TEXT",
"pageNumber": 0,
"pageX": 0,
"pageY": 0,
"pageWidth": 0,
"pageHeight": 0,
"fieldMeta": {
"label": "string",
"placeholder": "string",
"required": true,
"readOnly": true,
"type": "text",
"text": "string",
"characterLimit": 0
}
}
]
```
<Callout type="info">This endpoint accepts either one field or an array of fields.</Callout>
Before adding fields to a document, you need each recipient's ID. If the document already has recipients, you can query the document to retrieve the recipient's details. If the document has no recipients, you need to add a recipient via the UI or API before adding a field.
<Steps>
### Retrieve the Recipient(s) ID(s)
Perform a `GET` request to the `/api/v1/documents/{id}` to retrieve the details of a specific document, including the recipient's information.
An example response would look like this:
```json
{
"id": 137,
"externalId": null,
"userId": 3,
"teamId": null,
"title": "documenso.pdf",
"internalVersion": 2,
"type": "TEMPLATE",
"status": "DRAFT",
"documentDataId": "<document-data-id>",
"createdAt": "2024-10-11T12:29:12.725Z",
"updatedAt": "2024-10-11T12:29:12.725Z",
"source": "TEMPLATE",
"visibility": "EVERYONE",
"templateType": "PRIVATE",
"id": "envelope_xxxxxxxxxxxxxxxx",
"secondaryId": "template_9",
"externalId": null,
"createdAt": "2025-11-12T11:36:38.391Z",
"updatedAt": "2025-11-12T11:36:55.648Z",
"completedAt": null,
"deletedAt": null,
"title": "Title",
"recipients": [
{
"id": 55,
"documentId": 137,
"email": "ashdrew@email.com",
"name": "Ash Drew",
"envelopeId": "envelope_xxxxxxxxxxxxxxxx",
"role": "SIGNER",
"signingOrder": null,
"token": "<signing-token>",
"signedAt": null,
"readStatus": "NOT_OPENED",
"signingStatus": "NOT_SIGNED",
"sendStatus": "NOT_SENT",
"signingUrl": "https://app.documenso.com/sign/<signing-token>"
"id": 0,
"email": "recipient+1@documenso.com",
"name": "",
"token": "cxH2Ss79Hj94M1U3PxRAG",
"documentDeletedAt": null,
"expired": null,
"signedAt": null,
"authOptions": {
"accessAuth": [],
"actionAuth": []
},
"signingOrder": 1,
"rejectionReason": null
}
]
}
```
From this response, you'll only need the recipient ID, which is `55` in this case.
### (OR) Add a Recipient
If the document doesn't already have recipient(s), you can add recipient(s) via the API. Make a `POST` request to the `/api/v1/documents/{documentId}/recipients` endpoint with the recipient information. This endpoint takes the following JSON payload:
```json
{
"name": "string",
"email": "user@example.com",
"role": "SIGNER",
"signingOrder": 0,
"authOptions": {
"actionAuth": "ACCOUNT"
}
}
```
<Callout type="info">The `authOptions` property is only available for Enterprise accounts.</Callout>
Here's an example of the JSON payload for adding a recipient:
```json
{
"name": "Ash Drew",
"email": "ashdrew@email.com",
"role": "SIGNER",
"signingOrder": 0
}
```
A successful request will return a JSON response with the newly added recipient. You can now use the recipient ID to add fields to the document.
### Add Field(s)
Now you can make a `POST` request to the `/api/v1/documents/{documentId}/fields` endpoint with the field(s) information. Here's an example:
```json
[
{
"recipientId": 55,
"type": "SIGNATURE",
"pageNumber": 1,
"pageX": 50,
"pageY": 20,
"pageWidth": 25,
"pageHeight": 5
},
{
"recipientId": 55,
"type": "TEXT",
"pageNumber": 1,
"pageX": 20,
"pageY": 50,
"pageWidth": 30,
"pageHeight": 7.5,
"fieldMeta": {
"label": "Address",
"placeholder": "32 New York Street, 41241",
"required": true,
"readOnly": false,
"type": "text",
"text": "32 New York Street, 41241",
"characterLimit": 40
"envelopeItems": [
{
"envelopeId": "envelope_xxxxxxxxxxxxxxxx",
"id": "envelope_item_xxxxxxxxxxxxxxxxx",
"title": "FileOne",
"order": 1
}
}
]
],
// Other attributes
}
```
## Create Envelope
This example request will create a document with the following:
- Two PDF files
- Two recipients with one field each
You will need to:
- Replace api_xxxxxxxxxxxxxx with your API key
- Replace the file paths with the actual paths to your files
Note that the identifier on a field is linking to the files you upload. It can either be the index of the file or the filename. In this example it uses the index of the file.
```sh
curl -X POST "https://app.documenso.com/api/v2/envelope/create" \
-H "Authorization: api_xxxxxxxxxxxxxx" \
-H "Content-Type: multipart/form-data" \
-F 'payload={
"type": "DOCUMENT",
"title": "Envelope Full Field Test",
"recipients": [
{
"email": "recipient+1@example.com",
"name": "Recipient One",
"role": "SIGNER",
"fields": [
{
"identifier": 0,
"type": "SIGNATURE",
"page": 1,
"positionX": 0,
"positionY": 0,
"width": 50,
"height": 50
}
]
},
{
"email": "recipient-2@example.com",
"name": "Recipient Two",
"role": "SIGNER",
"fields": [
{
"identifier": 1,
"type": "SIGNATURE",
"page": 1,
"positionX": 0,
"positionY": 0,
"width": 50,
"height": 50
}
]
}
]
}' \
-F "files=@./field-font-alignment.pdf;type=application/pdf" \
-F "files=@./field-meta.pdf;type=application/pdf"
```
<Callout type="info">
The `text` field represents the default value of the field. If the user doesn't provide any other
value, this is the value that will be used to sign the field.
See the full request and response formats for the create endpoint
[here](https://openapi.documenso.com/reference#tag/envelope/POST/envelope/create)
</Callout>
<Callout type="warning">
It's important to pass the `type` in the `fieldMeta` property for the advanced fields. [Read more
here](#a-note-on-advanced-fields)
## Use Template
Documenso allows you to generate documents from templates. This is useful when you have a standard document format you want to reuse.
The API endpoint for generating a document from a template is `/api/v2/envelopes/use`, and it takes a JSON payload with the following fields:
<Callout type="info">
See the full request and response formats for the use endpoint
[here](https://openapi.documenso.com/reference#tag/envelope/POST/envelope/use)
</Callout>
A successful request will return a JSON response with the newly added fields. The image below illustrates the fields added to the document via the API.
<Steps>
![A screenshot of the document in the Documenso editor](/api-reference/fields-added-via-api.webp)
### Grab the Template ID
</Steps>
The first step is to retrieve the ID of the template you want to use. This can be done via the API or from the Documenso UI.
#### A Note on Advanced Fields
You can get the ID by navigating to the template page and looking at the URL. The ID is the last part of the URL which looks like this "envelope_xxxxxxxx"
The advanced fields are: text, checkbox, radio, number, and select. Whenever you append any of these advanced fields to a document, you need to pass the `type` in the `fieldMeta` property:
### Retrieve the Recipient(s) ID(s)
```json
...
"fieldMeta": {
"type": "text",
}
...
Once you have the template ID, you will want to retrieve the full template so you can see the recipients.
This is optional, and you only will want to do this if you want to modify the recipient details prior to creating the new document.
See the [Get Envelope](#get-envelope) section for more details on how to retrieve the envelope.
### Generate the Document
To generate a document from the template, you need to make a POST request to the [`/api/v2/envelope/use`](https://openapi.documenso.com/reference#tag/envelope/POST/envelope/use) endpoint.
You will need to replace the following:
- `api_xxxxxxxxxxxxxx` with your API key
- `envelope_xxxxxxxxxxxxxxx` with the template ID
- `RECIPIENT_ID_HERE` with the recipient ID you want to modify prior to sending
- `RECIPIENT_EMAIL_HERE` with the new recipient email you want to use
- `RECIPIENT_NAME_HERE` with the new recipient name you want to use
If you want to send the document immediately, you can add the `distributeDocument` parameter to the payload.
```sh
curl -X POST "https://app.documenso.com/api/v2/envelope/use" \
-H "Authorization: api_xxxxxxxxxxxxxx" \
-H "Content-Type: multipart/form-data" \
-F 'payload={
"envelopeId": "envelope_xxxxxxxxxxxxxxx",
"recipients": [
{
"id": RECIPIENT_ID_HERE,
"email": "RECIPIENT_EMAIL_HERE",
"name": "RECIPIENT_NAME_HERE"
}
]
}'
```
Replace the `text` value with the corresponding field type:
#### Generate the Document with Custom Files
- For the `TEXT` field it should be `text`.
- For the `CHECKBOX` field it should be `checkbox`.
- For the `RADIO` field it should be `radio`.
- For the `NUMBER` field it should be `number`.
- For the `SELECT` field it should be `select`. (check this before merge)
You can also generate a document from a template using custom PDF files to replace the template's default PDF files.
You must pass this property at all times, even if you don't need to set any other properties. If you don't, the endpoint will throw an error.
To do this, you will need to grab the `envelopeItemId` of the item you want to replace, this is found in the GET request in the previous step.
## Pre-fill Fields On Document Creation
You will need to replace the following:
- `CUSTOM_FILE_NAME_HERE.pdf` with the custom file name
- `envelope_item_xxxxxxxxxxxxxxxxx` with the `envelopeItemId` of the item you want to replace
```sh
curl -X POST "https://app.documenso.com/api/v2/envelope/use" \
-H "Authorization: api_xxxxxxxxxxxxxx" \
-H "Content-Type: multipart/form-data" \
-F 'payload={
"envelopeId": "envelope_xxxxxxxxxxxxxxx",
"recipients": [
{
"id": RECIPIENT_ID_HERE,
"email": "RECIPIENT_EMAIL_HERE",
"name": "RECIPIENT_NAME_HERE"
}
],
"customDocumentData": [
{
"identifier": "CUSTOM_FILE_NAME_HERE.pdf",
"envelopeItemId": "envelope_item_xxxxxxxxxxxxxxxxx"
}
]
}' \
-F "files=@./CUSTOM_FILE_NAME_HERE.pdf;type=application/pdf"
```
You can now access the document in your Documenso account dashboard.
#### Pre-fill Fields On Document Creation
The API allows you to pre-fill fields on document creation. This is useful when you want to create a document from an existing template and pre-fill the fields with specific values.
To pre-fill a field, you need to make a `POST` request to the `/api/v1/templates/{templateId}/generate-document` endpoint with the field information. Here's an example:
```json
{
"title": "my-document.pdf",
"recipients": [
{
"id": 3,
"name": "Example User",
"email": "example@documenso.com",
"signingOrder": 1,
"role": "SIGNER"
}
],
"prefillFields": [
{
"id": 21,
@@ -574,51 +270,187 @@ To pre-fill a field, you need to make a `POST` request to the `/api/v1/templates
"value": ["option-1", "option-2"]
}
]
// Other payload properties...
}
```
Check out the endpoint in the [API V1 documentation](https://app.documenso.com/api/v1/openapi#:~:text=/%7BtemplateId%7D/-,generate,-%2Ddocument).
</Steps>
### API V2
## Add Recipients
For API V2, you need to make a `POST` request to the `/api/v2-beta/template/use` endpoint with the field(s) information. Here's an example:
The API allows you to add recipients to an envelope via the [`/api/v2/envelope/recipient/create-many`](https://openapi.documenso.com/reference#tag/envelope-recipients/POST/envelope/recipient/create-many) endpoint.
The following is an example of a request which creates 2 new recipients on the envelope.
```sh
curl https://app.documenso.com/api/v2/envelope/recipient/create-many \
--request POST \
--header 'Authorization: api_xxxxxxxxxxxxxx' \
--header 'Content-Type: application/json' \
--data '{
"envelopeId": "envelope_brxkyaxywuxkyeuv",
"data": [
{
"name": "Recipient Name",
"email": "example@documenso.com",
"role": "SIGNER"
},
{
"name": "Recipient Two",
"email": "example+2@documenso.com",
"role": "APPROVER"
}
]
}'
```
## Add Fields
The API allows you to add fields to an envelope via the [`/api/v2/envelope/field/create-many`](https://openapi.documenso.com/reference#tag/envelope-fields/POST/envelope/field/create-many) endpoint.
Before adding fields to an envelope, you will need the following details:
- **Envelope ID** - Which envelope the field will be added to
- **Recipient ID** - Which recipient the field will be added to
- **Envelope Item ID** - Which file the field will be added to. If blank, the field will be added to the first file.
See the [Get Envelope](#get-envelope) section for more details on how to retrieve these details.
### Coordinate-Based Positioning
The following is an example of a request which creates 2 new fields on the first page of the envelope.
Note that width, height, positionX and positionY are percentage numbers between 0 and 100, which scale the field relative to the size of the PDF.
```sh
curl https://app.documenso.com/api/v2/envelope/field/create-many \
--request POST \
--header 'Authorization: api_xxxxxxxxxxxxxx' \
--header 'Content-Type: application/json' \
--data '{
"envelopeId": "envelope_xxxxxxxxxx",
"data": [
{
"recipientId": recipient_id_here,
"envelopeItemId": "envelope_item_id_here",
"type": "TEXT",
"page": 1,
"positionX": 0,
"positionY": 0,
"width": 50,
"height": 50,
"fieldMeta": {
"type": "text",
"label": "First test field"
}
},
{
"recipientId": recipient_id_here,
"envelopeItemId": "envelope_item_id_here",
"type": "TEXT",
"page": 1,
"positionX": 50,
"positionY": 50,
"width": 50,
"height": 50,
"fieldMeta": {
"type": "text",
"label": "Second test field"
}
}
]
}'
```
### Placeholder-Based Positioning
Instead of specifying exact coordinates, you can position fields using placeholder text in the PDF. The API will search for the text and place the field at that location.
This is useful when:
- You have PDFs with designated placeholder text (e.g., `{{signature}}`, `[SIGN HERE]`)
- You want field positions to adapt to document content changes
- You're working with templated documents generated from other systems
```sh
curl https://app.documenso.com/api/v2/envelope/field/create-many \
--request POST \
--header 'Authorization: api_xxxxxxxxxxxxxx' \
--header 'Content-Type: application/json' \
--data '{
"envelopeId": "envelope_xxxxxxxxxx",
"data": [
{
"recipientId": recipient_id_here,
"type": "SIGNATURE",
"placeholder": "{{signature}}"
},
{
"recipientId": recipient_id_here,
"type": "NAME",
"placeholder": "{{name}}",
"width": 30,
"height": 5
}
]
}'
```
#### Placeholder Parameters
| Parameter | Type | Required | Description |
| ------------- | ------- | -------- | ---------------------------------------------------------------------------------------------------------------- |
| `placeholder` | string | Yes | Text to search for in the PDF. The field is placed at the location of this text. |
| `width` | number | No | Override the field width (percentage). If omitted, uses the placeholder text width. |
| `height` | number | No | Override the field height (percentage). If omitted, uses the placeholder text height. |
| `matchAll` | boolean | No | When `true`, creates a field at every occurrence of the placeholder. Default is `false` (first occurrence only). |
<Callout type="info">
The placeholder text is automatically covered with a white rectangle after field creation, so it
won't appear in the final signed document.
</Callout>
#### Multiple Occurrences
If your PDF contains the same placeholder text multiple times (e.g., initials on every page), use `matchAll: true` to create fields at all occurrences:
```json
{
"templateId": 111,
"recipients": [
"recipientId": 123,
"type": "INITIALS",
"placeholder": "{{initials}}",
"matchAll": true
}
```
This will create one INITIALS field for each occurrence of `{{initials}}` in the PDF.
#### Mixing Positioning Methods
You can combine coordinate-based and placeholder-based positioning in the same request:
```json
{
"envelopeId": "envelope_xxxxxxxxxx",
"data": [
{
"id": 3,
"name": "Example User",
"email": "example@documenso.com",
"signingOrder": 1,
"role": "SIGNER"
}
],
"prefillFields": [
{
"id": 21,
"type": "text",
"label": "my-label",
"placeholder": "my-placeholder",
"value": "my-value"
"recipientId": 123,
"type": "SIGNATURE",
"placeholder": "{{signature}}"
},
{
"id": 22,
"type": "number",
"label": "my-label",
"placeholder": "my-placeholder",
"value": "123"
},
{
"id": 23,
"type": "checkbox",
"label": "my-label",
"placeholder": "my-placeholder",
"value": ["option-1", "option-2"]
"recipientId": 123,
"type": "DATE",
"page": 1,
"positionX": 70,
"positionY": 85,
"width": 20,
"height": 3
}
]
}
```
Check out the endpoint in the [API V2 documentation](https://openapi.documenso.com/reference#tag/template/POST/template/use).
Field meta allows you to further configure fields, for example it will allow you to add multiple items for checkboxes or radios.
A successful request will return a JSON response with the newly added fields.
@@ -9,9 +9,9 @@ import { Callout } from 'nextra/components';
Documenso uses API versioning to manage changes to the public API. This allows us to introduce new features, fix bugs, and make other changes without breaking existing integrations.
<Callout type="info">The current version of the API is `v1`.</Callout>
<Callout type="info">The current version of the API is `v2`.</Callout>
The API version is specified in the URL. For example, the base URL for the `v1` API is `https://app.documenso.com/api/v1`.
The API version is specified in the URL. For example, the base URL for the `v2` API is `https://app.documenso.com/api/v2`.
We may make changes to the API without incrementing the version number. We will always try to avoid breaking changes, but in some cases, it may be necessary to make changes that are not backward compatible. In these cases, we will increment the version number and provide information about the changes in the release notes.
@@ -0,0 +1,8 @@
export default {
index: 'Getting Started',
'signing-certificate': 'Signing Certificate',
'how-to': 'How To',
'setting-up-oauth-providers': 'Setting up OAuth Providers',
telemetry: 'Telemetry',
'ai-features': 'AI Recipient & Field Detection',
};
@@ -1,6 +0,0 @@
{
"index": "Getting Started",
"signing-certificate": "Signing Certificate",
"how-to": "How To",
"setting-up-oauth-providers": "Setting up OAuth Providers"
}
@@ -0,0 +1,72 @@
---
title: AI Recipient & Field Detection (Self-hosting)
description: Configure Google Vertex AI so Documenso can detect recipients and fields automatically.
---
import { Callout, Steps } from 'nextra/components';
# AI Recipient & Field Detection (Self-hosting)
This guide covers how to enable the AI recipient and field detection features when you self-host Documenso.
## What this enables
- Detect recipients from uploaded PDFs (roles, names, emails when present).
- Detect and place fields (signature, initials, name, email, date, text, number, radio, checkbox) onto draft envelopes.
- Built-in rate limits (3 requests per minute per IP) to prevent abuse.
## Prerequisites
- A Google Cloud project with the **Vertex AI API** enabled and billing active.
- A **Vertex AI Express API key** with access to Gemini models (create via the [Vertex AI Express flow](https://cloud.google.com/vertex-ai/generative-ai/docs/start/express-mode/overview) and manage keys in [API keys](https://cloud.google.com/vertex-ai/generative-ai/docs/start/api-keys)).
- Documenso version that includes the AI detection feature and the corresponding database migration.
## Configure environment variables
Add these variables to your deployment `.env` (or secret manager):
```
GOOGLE_VERTEX_PROJECT_ID="<your-gcp-project-id>"
GOOGLE_VERTEX_API_KEY="<your-vertex-api-key>"
# Optional, defaults to "global"
GOOGLE_VERTEX_LOCATION="global"
```
<Callout type="info">
Use a region close to your users if you need data residency considerations (e.g. `europe-west1`).
If you omit the location, Documenso uses `global`. Not all models are available in every region;
if a model is unavailable, switch to a supported region.
</Callout>
## Deploy with the published container
- Use the official Documenso image (DockerHub or GHCR) and supply the Vertex env vars above.
- Ensure migrations run on startup (the container runs `prisma migrate deploy` in production mode).
- Restart the container after adding or changing Vertex env vars.
## Enable the feature in Documenso
Once the service is running with the Vertex env vars:
<Steps>
### Organisation settings
Go to **Settings → Document Preferences → AI Features** and set to **Enabled**. Teams that inherit organisation defaults will pick this up.
### Team settings
If a team overrides organisation defaults, go to **Team Settings → Document Preferences → AI Features** and choose **Enabled** (or **Inherit** to follow the organisation).
### Verify in the editor
Open a draft envelope. In **Recipients**, you should see the sparkle button for AI detection. In **Fields**, you should see **Detect with AI** available.
</Steps>
## Troubleshooting
- **Too many requests**: Wait a minute or two and retry (rate limit is 3/min per IP).
- **AI options hidden**: Ensure the env vars are set, the server was restarted after setting them, and `aiFeaturesEnabled` is enabled at organisation/team level.
- **Detection fails immediately**: Confirm the Vertex API key is valid and the project has Vertex AI enabled. Check server logs for status codes from Vertex.
If issues persist, recheck env vars, restart the service, and confirm the Prisma migration was applied.
@@ -119,6 +119,8 @@ NEXT_PRIVATE_SMTP_USERNAME="<your-username>"
NEXT_PRIVATE_SMTP_PASSWORD="<your-password>"
```
For full AI setup details (including model availability notes), see the [AI Recipient & Field Detection (Self-hosting)](./ai-features) page.
### Set Up Your Signing Certificate
<Callout type="warning">
@@ -146,6 +148,7 @@ This method avoids file permission issues by creating the certificate directly i
# Generate certificate inside container using environment variable
docker exec -e CERT_PASS="$CERT_PASS" -it documenso-production-documenso-1 bash -c "
mkdir -p /app/certs && \
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout /tmp/private.key \
-out /tmp/certificate.crt \
@@ -267,47 +270,95 @@ You can access the Documenso application by visiting the URL you provided for th
The environment variables listed above are a subset of those available for configuring Documenso. The table below provides a complete list of environment variables and their descriptions.
| Variable | Description |
| -------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| `PORT` | The port on which the Documenso application runs. It defaults to `3000`. |
| `NEXTAUTH_SECRET` | The secret key used by NextAuth.js for encryption and signing. |
| `NEXT_PRIVATE_ENCRYPTION_KEY` | The primary encryption key for symmetric encryption and decryption (at least 32 characters). |
| `NEXT_PRIVATE_ENCRYPTION_SECONDARY_KEY` | The secondary encryption key for symmetric encryption and decryption (at least 32 characters). |
| `NEXT_PRIVATE_GOOGLE_CLIENT_ID` | The Google client ID for Google authentication (optional). |
| `NEXT_PRIVATE_GOOGLE_CLIENT_SECRET` | The Google client secret for Google authentication (optional). |
| `NEXT_PUBLIC_WEBAPP_URL` | The URL for the web application. |
| `NEXT_PRIVATE_DATABASE_URL` | The URL for the primary database connection (with connection pooling). |
| `NEXT_PRIVATE_DIRECT_DATABASE_URL` | The URL for the direct database connection (without connection pooling). |
| `NEXT_PRIVATE_SIGNING_TRANSPORT` | The signing transport to use. Available options: local (default) |
| `NEXT_PRIVATE_SIGNING_PASSPHRASE` | The passphrase for the key file. |
| `NEXT_PRIVATE_SIGNING_LOCAL_FILE_CONTENTS` | The base64-encoded contents of the key file will be used instead of the file path. |
| `NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH` | The path to the key file, default `/opt/documenso/cert.p12`. |
| `NEXT_PUBLIC_UPLOAD_TRANSPORT` | The transport for file uploads (database or s3). |
| `NEXT_PRIVATE_UPLOAD_ENDPOINT` | The endpoint for the S3 storage transport (for third-party S3-compatible providers). |
| `NEXT_PRIVATE_UPLOAD_FORCE_PATH_STYLE` | Whether to force path-style URLs for the S3 storage transport. |
| `NEXT_PRIVATE_UPLOAD_REGION` | The region for the S3 storage transport (defaults to us-east-1). |
| `NEXT_PRIVATE_UPLOAD_BUCKET` | The bucket to use for the S3 storage transport. |
| `NEXT_PRIVATE_UPLOAD_ACCESS_KEY_ID` | The access key ID for the S3 storage transport. |
| `NEXT_PRIVATE_UPLOAD_SECRET_ACCESS_KEY` | The secret access key for the S3 storage transport. |
| `NEXT_PRIVATE_SMTP_TRANSPORT` | The transport to send emails (smtp-auth, smtp-api, resend, or mailchannels). |
| `NEXT_PRIVATE_SMTP_HOST` | The host for the SMTP server for SMTP transports. |
| `NEXT_PRIVATE_SMTP_PORT` | The port for the SMTP server for SMTP transports. |
| `NEXT_PRIVATE_SMTP_USERNAME` | The username for the SMTP server for the `smtp-auth` transport. |
| `NEXT_PRIVATE_SMTP_PASSWORD` | The password for the SMTP server for the `smtp-auth` transport. |
| `NEXT_PRIVATE_SMTP_APIKEY_USER` | The API key user for the SMTP server for the `smtp-api` transport. |
| `NEXT_PRIVATE_SMTP_APIKEY` | The API key for the SMTP server for the `smtp-api` transport. |
| `NEXT_PRIVATE_SMTP_SECURE` | Whether to force the use of TLS for the SMTP server for SMTP transports. |
| `NEXT_PRIVATE_SMTP_FROM_ADDRESS` | The email address for the "from" address. |
| `NEXT_PRIVATE_SMTP_FROM_NAME` | The sender name for the "from" address. |
| `NEXT_PRIVATE_RESEND_API_KEY` | The API key for Resend.com for the `resend` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_API_KEY` | The optional API key for MailChannels (if using a proxy) for the `mailchannels` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_ENDPOINT` | The optional endpoint for the MailChannels API (if using a proxy) for the `mailchannels` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_DKIM_DOMAIN` | The domain for DKIM signing with MailChannels for the `mailchannels` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_DKIM_SELECTOR` | The selector for DKIM signing with MailChannels for the `mailchannels` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_DKIM_PRIVATE_KEY` | The private key for DKIM signing with MailChannels for the `mailchannels` transport. |
| `NEXT_PUBLIC_DOCUMENT_SIZE_UPLOAD_LIMIT` | The maximum document upload limit displayed to the user (in MB). |
| `NEXT_PUBLIC_POSTHOG_KEY` | The optional PostHog key for analytics and feature flags. |
| `NEXT_PUBLIC_DISABLE_SIGNUP` | Whether to disable user signups through the /signup page. |
For AI setup specifics, see the [AI Recipient & Field Detection (Self-hosting)](./ai-features) page.
| Variable | Description |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `PORT` | The port on which the Documenso application runs. It defaults to `3000`. |
| `NEXTAUTH_SECRET` | The secret key used by NextAuth.js for encryption and signing. |
| `NEXT_PRIVATE_ENCRYPTION_KEY` | The primary encryption key for symmetric encryption and decryption (at least 32 characters). |
| `NEXT_PRIVATE_ENCRYPTION_SECONDARY_KEY` | The secondary encryption key for symmetric encryption and decryption (at least 32 characters). |
| `NEXT_PRIVATE_GOOGLE_CLIENT_ID` | The Google client ID for Google authentication (optional). |
| `NEXT_PRIVATE_GOOGLE_CLIENT_SECRET` | The Google client secret for Google authentication (optional). |
| `NEXT_PRIVATE_MICROSOFT_CLIENT_ID` | The Microsoft client ID for Microsoft authentication (optional). |
| `NEXT_PRIVATE_MICROSOFT_CLIENT_SECRET` | The Microsoft client secret for Microsoft authentication (optional). |
| `NEXT_PRIVATE_OIDC_CLIENT_ID` | The OIDC client ID for OIDC authentication (optional). |
| `NEXT_PRIVATE_OIDC_CLIENT_SECRET` | The OIDC client secret for OIDC authentication (optional). |
| `NEXT_PRIVATE_OIDC_WELL_KNOWN` | The well-known URL for the OIDC provider (optional). |
| `NEXT_PRIVATE_OIDC_PROVIDER_LABEL` | The label to display for the OIDC provider button (optional). |
| `NEXT_PRIVATE_OIDC_SKIP_VERIFY` | Whether to skip email verification for OIDC accounts (optional, default `false`). |
| `NEXT_PUBLIC_WEBAPP_URL` | The URL for the web application. |
| `NEXT_PUBLIC_SUPPORT_EMAIL` | The support email address displayed to users (default `support@documenso.com`). |
| `NEXT_PRIVATE_DATABASE_URL` | The URL for the primary database connection (with connection pooling). |
| `NEXT_PRIVATE_DIRECT_DATABASE_URL` | The URL for the direct database connection (without connection pooling). |
| `NEXT_PRIVATE_SIGNING_TRANSPORT` | The signing transport to use. Available options: local (default), gcloud-hsm |
| `NEXT_PRIVATE_SIGNING_PASSPHRASE` | The passphrase for the key file. |
| `NEXT_PRIVATE_SIGNING_LOCAL_FILE_CONTENTS` | The base64-encoded contents of the key file will be used instead of the file path. |
| `NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH` | The path to the key file, default `/opt/documenso/cert.p12`. |
| `NEXT_PRIVATE_SIGNING_TIMESTAMP_AUTHORITY` | Comma-separated list of timestamp authority URLs for PDF signing. Enables LTV and archival timestamps. |
| `NEXT_PUBLIC_SIGNING_CONTACT_INFO` | Contact info to embed in PDF signatures. Defaults to the webapp URL. |
| `NEXT_PRIVATE_USE_LEGACY_SIGNING_SUBFILTER` | Set to "true" to use the legacy adbe.pkcs7.detached subfilter instead of ETSI.CAdES.detached. |
| `NEXT_PUBLIC_UPLOAD_TRANSPORT` | The transport for file uploads (database or s3). |
| `NEXT_PRIVATE_UPLOAD_ENDPOINT` | The endpoint for the S3 storage transport (for third-party S3-compatible providers). |
| `NEXT_PRIVATE_UPLOAD_FORCE_PATH_STYLE` | Whether to force path-style URLs for the S3 storage transport. |
| `NEXT_PRIVATE_UPLOAD_REGION` | The region for the S3 storage transport (defaults to us-east-1). |
| `NEXT_PRIVATE_UPLOAD_BUCKET` | The bucket to use for the S3 storage transport. |
| `NEXT_PRIVATE_UPLOAD_ACCESS_KEY_ID` | The access key ID for the S3 storage transport. |
| `NEXT_PRIVATE_UPLOAD_SECRET_ACCESS_KEY` | The secret access key for the S3 storage transport. |
| `NEXT_PRIVATE_SMTP_TRANSPORT` | The transport to send emails (smtp-auth, smtp-api, resend, or mailchannels). |
| `NEXT_PRIVATE_SMTP_HOST` | The host for the SMTP server for SMTP transports. |
| `NEXT_PRIVATE_SMTP_PORT` | The port for the SMTP server for SMTP transports. |
| `NEXT_PRIVATE_SMTP_USERNAME` | The username for the SMTP server for the `smtp-auth` transport. |
| `NEXT_PRIVATE_SMTP_PASSWORD` | The password for the SMTP server for the `smtp-auth` transport. |
| `NEXT_PRIVATE_SMTP_APIKEY_USER` | The API key user for the SMTP server for the `smtp-api` transport. |
| `NEXT_PRIVATE_SMTP_APIKEY` | The API key for the SMTP server for the `smtp-api` transport. |
| `NEXT_PRIVATE_SMTP_SECURE` | Whether to force the use of TLS for the SMTP server for SMTP transports. |
| `NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS` | Whether to ignore TLS errors for the SMTP server (useful for self-signed certificates). |
| `NEXT_PRIVATE_SMTP_FROM_ADDRESS` | The email address for the "from" address. |
| `NEXT_PRIVATE_SMTP_FROM_NAME` | The sender name for the "from" address. |
| `NEXT_PRIVATE_RESEND_API_KEY` | The API key for Resend.com for the `resend` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_API_KEY` | The optional API key for MailChannels (if using a proxy) for the `mailchannels` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_ENDPOINT` | The optional endpoint for the MailChannels API (if using a proxy) for the `mailchannels` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_DKIM_DOMAIN` | The domain for DKIM signing with MailChannels for the `mailchannels` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_DKIM_SELECTOR` | The selector for DKIM signing with MailChannels for the `mailchannels` transport. |
| `NEXT_PRIVATE_MAILCHANNELS_DKIM_PRIVATE_KEY` | The private key for DKIM signing with MailChannels for the `mailchannels` transport. |
| `NEXT_PUBLIC_DOCUMENT_SIZE_UPLOAD_LIMIT` | The maximum document upload limit displayed to the user (in MB). |
| `NEXT_PUBLIC_POSTHOG_KEY` | The optional PostHog key for analytics and feature flags. |
| `NEXT_PUBLIC_DISABLE_SIGNUP` | Whether to disable user signups through the /signup page. |
| `NEXT_PRIVATE_BROWSERLESS_URL` | The URL for a Browserless.io instance to generate PDFs (optional). |
| `DOCUMENSO_DISABLE_TELEMETRY` | Set to `true` to disable anonymous telemetry (see [Telemetry](#telemetry) section below). |
| `GOOGLE_VERTEX_PROJECT_ID` | Google Cloud project ID used for Vertex AI (required for AI detection). |
| `GOOGLE_VERTEX_API_KEY` | Vertex AI Express API key with access to Gemini models (required for AI detection). See [AI Recipient & Field Detectionfor](./ai-features) for details. |
| `GOOGLE_VERTEX_LOCATION` | Optional Vertex region, defaults to `global`. Not all models are available in every region. |
## Telemetry
Documenso collects anonymous telemetry data to help us understand how the software is being used and improve the product. This telemetry is **enabled by default** for self-hosted instances.
### What We Collect
We collect minimal, privacy-preserving data:
- **App Version**: The version of Documenso you are running
- **Installation ID**: A unique identifier for your installation (stored in your database)
- **Node ID**: A unique identifier for each server/container instance (stored in the OS temp directory)
We do **not** collect any personal data, document contents, user information, or usage patterns.
### Events
- **Server Startup**: Captured once when the server starts
- **Server Heartbeat**: Captured every hour while the server is running
### Disabling Telemetry
To disable telemetry, set the following environment variable:
```bash
DOCUMENSO_DISABLE_TELEMETRY=true
```
This will completely disable all telemetry data collection.
## Run as a Service
@@ -53,15 +53,21 @@ Have the Certificate Authority sign the Certificate Signing Request.
Configure your instance to use the new certificate by configuring the following environment variables in your `.env` file:
| Environment Variable | Description |
| :-------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------- |
| `NEXT_PRIVATE_SIGNING_TRANSPORT` | The transport used for document signing. Available options: local (default), gcloud-hsm |
| `NEXT_PRIVATE_SIGNING_PASSPHRASE` | The passphrase for the local file-based signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH` | The local file path to the .p12 file to use for the local signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_LOCAL_FILE_CONTENTS` | The base64-encoded contents of the .p12 file to use for the local signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_HSM_KEY_PATH` | The Google Cloud HSM key path for the gcloud-hsm signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_HSM _PUBLIC_CRT_FILE_PATH` | The path to the Google Cloud HSM public certificate file to use for the gcloud-hsm signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_HSM _PUBLIC_CRT_FILE_CONTENTS` | The base64-encoded contents of the Google Cloud HSM public certificate file for the gcloud-hsm signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_ APPLICATION_CREDENTIALS_CONTENTS` | The Google Cloud Credentials file path for the gcloud-hsm signing transport. This field is optional. |
| Environment Variable | Description |
| :------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------- |
| `NEXT_PRIVATE_SIGNING_TRANSPORT` | The transport used for document signing. Available options: local (default), gcloud-hsm |
| `NEXT_PRIVATE_SIGNING_PASSPHRASE` | The passphrase for the local file-based signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH` | The local file path to the .p12 file to use for the local signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_LOCAL_FILE_CONTENTS` | The base64-encoded contents of the .p12 file to use for the local signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_HSM_KEY_PATH` | The Google Cloud HSM key path for the gcloud-hsm signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_HSM_PUBLIC_CRT_FILE_PATH` | The path to the Google Cloud HSM public certificate file to use for the gcloud-hsm signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_HSM_PUBLIC_CRT_FILE_CONTENTS` | The base64-encoded contents of the Google Cloud HSM public certificate file for the gcloud-hsm signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_APPLICATION_CREDENTIALS_CONTENTS` | The base64-encoded Google Cloud Credentials for the gcloud-hsm signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_HSM_CERT_CHAIN_FILE_PATH` | The path to the certificate chain file for the gcloud-hsm signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_HSM_CERT_CHAIN_CONTENTS` | The base64-encoded contents of the certificate chain for the gcloud-hsm signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_GCLOUD_HSM_SECRET_MANAGER_CERT_PATH` | The Google Secret Manager path to retrieve the certificate for the gcloud-hsm signing transport. This field is optional. |
| `NEXT_PRIVATE_SIGNING_TIMESTAMP_AUTHORITY` | Comma-separated list of timestamp authority URLs for PDF signing. Enables LTV and archival timestamps. This field is optional. |
| `NEXT_PUBLIC_SIGNING_CONTACT_INFO` | Contact info to embed in PDF signatures. Defaults to the webapp URL. This field is optional. |
| `NEXT_PRIVATE_USE_LEGACY_SIGNING_SUBFILTER` | Set to "true" to use the legacy adbe.pkcs7.detached subfilter instead of ETSI.CAdES.detached. This field is optional. |
</Steps>
@@ -0,0 +1,90 @@
---
title: Telemetry
description: Learn about the telemetry data that Documenso collects from self-hosted instances.
---
# Telemetry
Documenso collects anonymous telemetry data from self-hosted instances to help us understand how the software is being used and make improvements to the product. This telemetry is enabled by default, but you can easily disable it if you prefer.
## What We Collect
We collect minimal, privacy-preserving information that helps us understand the health and adoption of self-hosted installations:
- **App Version**: The version of Documenso you are running. This helps us understand which versions are in use and prioritize support for older versions.
- **Installation ID**: A unique identifier for your installation. This is stored in your database and helps us count distinct installations without knowing who you are.
- **Node ID**: A unique identifier for each server or container instance. This is stored in your operating system's temporary directory and helps us understand deployment patterns (for example, how many instances are running in a cluster).
### What We Don't Collect
We do **not** collect any of the following:
- Personal information about you or your users
- Document contents or file names
- User email addresses or names
- Usage patterns or feature usage statistics
- Server logs or error messages
- Any data that could identify your organization or users
## Why We Collect Telemetry
The telemetry data we collect serves several important purposes:
1. **Product Improvement**: Understanding which versions are in use helps us prioritize bug fixes and security updates for the versions that matter most.
2. **Support Planning**: Knowing how many installations exist and their deployment patterns helps us plan support resources and documentation.
3. **Feature Development**: Understanding deployment patterns (like cluster sizes) helps us make better architectural decisions for future features.
4. **Community Health**: Tracking adoption helps us understand the growth of the self-hosted community and allocate resources accordingly.
All of this is done anonymously and in aggregate. We cannot identify you, your organization, or your users from the telemetry data we collect.
## Events We Track
We track two simple events:
- **Server Startup**: Captured once when your server starts. This tells us when installations are first set up or restarted.
- **Server Heartbeat**: Captured every hour while your server is running. This helps us understand how many active installations exist and their uptime patterns.
## How to Disable Telemetry
If you prefer not to send telemetry data, you can disable it by setting an environment variable.
### Using Environment Variables
Add the following to your environment configuration:
```bash
DOCUMENSO_DISABLE_TELEMETRY=true
```
### Docker
If you're using Docker, you can set this in your `docker-compose.yml`:
```yaml
services:
app:
environment:
- DOCUMENSO_DISABLE_TELEMETRY=true
```
Or pass it when running a container:
```bash
docker run -e DOCUMENSO_DISABLE_TELEMETRY=true ...
```
### After Disabling
Once you set `DOCUMENSO_DISABLE_TELEMETRY=true` and restart your server, no telemetry data will be sent. The telemetry client will not initialize, and no network requests will be made to our telemetry servers.
Note: If you previously had telemetry enabled, the installation ID stored in your database will remain, but it will no longer be used or sent anywhere.
## Questions or Concerns
If you have questions about our telemetry practices or concerns about privacy, please reach out to us. We're committed to transparency and respect your choice to disable telemetry if you prefer.
@@ -5,7 +5,7 @@ description: Learn how to use webhooks to receive real-time notifications about
# Webhooks
Webhooks are HTTP callbacks triggered by specific events. When the user subscribes to a specific event, and that event occurs, the webhook makes an HTTP request to the URL provided by the user. The request can be a simple notification or carry a payload with more information about the event.
Webhooks are HTTP callbacks triggered by specific events. When you subscribe to a specific event and that event occurs, the webhook makes an HTTP request to the URL you provide. The request can be a simple notification or carry a payload with more information about the event.
Some of the common use cases for webhooks include:
@@ -25,13 +25,13 @@ Documenso supports Webhooks and allows you to subscribe to the following events:
## Create a webhook subscription
You can create a webhook subscription from the user settings page. Click on your avatar in the top right corner of the dashboard and select "**[User settings](https://app.documenso.com/settings)**" from the dropdown menu.
You can create a webhook subscription from the team settings page. Click your avatar in the top right corner of the dashboard and select "Team settings" from the dropdown menu.
![A screenshot of the Documenso's dashboard that shows the dropdown menu when you click on your user avatar](/webhook-images/dashboard-user-dropdown-menu.webp)
![A screenshot of the Documenso's dashboard that shows the dropdown menu when you click on your user avatar](/webhook-images/documenso-main-page.webp)
Then, navigate to the "**[Webhooks](https://app.documenso.com/settings/webhooks)**" tab, where you can see a list of your existing webhooks and create new ones.
Then, navigate to the "Webhooks" tab, which takes you to the webhooks main page.
![A screenshot of the Documenso's user settings page that shows the Webhooks tab and the Create Webhook button](/webhook-images/webhooks-settings-page.webp)
![A screenshot of the Documenso's team settings page that shows the Webhooks tab and the Create Webhook button](/webhook-images/webhooks-main-page.webp)
Clicking on the "**Create Webhook**" button opens a modal to create a new webhook subscription.
@@ -41,7 +41,7 @@ To create a new webhook subscription, you need to provide the following informat
- Select the event(s) you want to subscribe to: `document.created`, `document.sent`, `document.opened`, `document.signed`, `document.completed`, `document.rejected`, `document.cancelled`.
- Optionally, you can provide a secret key that will be used to sign the payload. This key will be included in the `X-Documenso-Secret` header of the request.
![A screenshot of the Create Webhook modal that shows the URL input field and the event checkboxes](/webhook-images/webhooks-page-create-webhook-modal.webp)
![A screenshot of the Create Webhook modal that shows the URL input field and the event checkboxes](/webhook-images/create-webhook-dialog.webp)
After you have filled in the required information, click on the "**Create Webhook**" button to save your subscription.
@@ -49,7 +49,22 @@ The screenshot below illustrates a newly created webhook subscription.
![A screenshot of the Documenso's user settings page that shows the newly created webhook subscription](/webhook-images/webhooks-page.webp)
You can edit or delete your webhook subscriptions by clicking the "**Edit**" or "**Delete**" buttons next to the webhook.
You can edit, view the logs, or delete your webhook subscriptions by clicking the three dots (...) under the "Action" column. You can also access the webhook logs by clicking on the webhook subscription directly.
![A screenshot of the Documenso's team settings page that shows the webhook logs](/webhook-images/webhook-detail-page.webp)
You can go even further and check the execution details of each call by clicking on a specific webhook call.
![A screenshot of the Documenso's team settings page that shows the webhook call details](/webhook-images/webhook-run-page.webp)
This page shows the details of the webhook call such as:
- status
- event
- date when the webhook was sent
- response code
- request body
- response body and headers
## Webhook fields
@@ -529,7 +544,7 @@ Example payload for the `document.rejected` event:
}
```
Example payload for the `document.rejected` event:
Example payload for the `document.cancelled` event:
```json
{
@@ -619,18 +634,26 @@ Example payload for the `document.rejected` event:
}
```
## Webhook Events Testing
## Webhook events testing
You can trigger test webhook events to test the webhook functionality. To trigger a test webhook, navigate to the [Webhooks page](/developers/webhooks) and click on the "Test Webhook" button.
You can trigger test webhook events to test the webhook functionality. To do so, navigate to the webhook subscription details page and click the "Test" button.
![Documenso's Webhooks Page](/webhook-images/test-webhooks-page.webp)
![A screenshot of the Documenso's team settings page that shows the webhook logs](/webhook-images/webhook-detail-page.webp)
This opens a dialog where you can select the event type to test.
![Documenso's individual webhook page](/webhook-images/test-webhook-dialog.webp)
![Documenso's individual webhook page](/webhook-images/webhook-test-trigger.webp)
Choose the appropriate event and click "Send Test Webhook." Youll shortly receive a test payload from Documenso with sample data.
Choose the event you want to test and click "Send". Youll then receive a test payload from Documenso with sample data.
## Webhook events resending
To resend a webhook call, you need to navigate to the webhook call page and click the "Resend" button.
![A screenshot of the Documenso's team settings page that shows the webhook call details](/webhook-images/webhook-run-page.webp)
This will send the webhook event to the webhook URL again.
## Availability
Webhooks are available to individual users and teams.
Webhooks are available to teams only.
+23
View File
@@ -0,0 +1,23 @@
export default {
index: 'Introduction',
support: 'Support',
'-- How To Use': {
type: 'separator',
title: 'How To Use',
},
'get-started': 'Get Started',
profile: 'Public Profile',
organisations: 'Organisations',
documents: 'Documents',
templates: 'Templates',
branding: 'Branding',
'email-domains': 'Email Domains',
'direct-links': 'Direct Signing Links',
'-- Legal Overview': {
type: 'separator',
title: 'Legal Overview',
},
'fair-use': 'Fair Use Policy',
licenses: 'Licenses',
compliance: 'Compliance',
};
-23
View File
@@ -1,23 +0,0 @@
{
"index": "Introduction",
"support": "Support",
"-- How To Use": {
"type": "separator",
"title": "How To Use"
},
"get-started": "Get Started",
"profile": "Public Profile",
"organisations": "Organisations",
"documents": "Documents",
"templates": "Templates",
"branding": "Branding",
"email-domains": "Email Domains",
"direct-links": "Direct Signing Links",
"-- Legal Overview": {
"type": "separator",
"title": "Legal Overview"
},
"fair-use": "Fair Use Policy",
"licenses": "Licenses",
"compliance": "Compliance"
}
@@ -0,0 +1,4 @@
export default {
'signature-levels': 'Signature Levels',
'standards-and-regulations': 'Standards and Regulations',
};
@@ -1,4 +0,0 @@
{
"signature-levels": "Signature Levels",
"standards-and-regulations": "Standards and Regulations"
}
@@ -1,3 +1,8 @@
---
title: Signature Levels
description: Learn about the different signature levels for Documenso.
---
import { Callout } from 'nextra/components';
# Signature Levels
@@ -26,20 +31,20 @@ ensures the legal validity and enforceability of electronic signatures and recor
### Main Requirements
- [x] Intent to Sign: "Parties must demonstrate their intent to sign [..]"
- [x] Consent: "The ESIGN Act requires that all parties involved in a transaction consent to the use of electronic signatures and records [..]"
- [x] Consumer Disclosures: Before obtaining their consent, financial institutions must provide the consumer a clear and conspicuous statement informing the consumer [..]
- [x] Record Retention: Electronic Records must be maintained for later access by signers.
- [x] Security: The ESIGN Act does not mandate specific security measures, but it does require that parties take reasonable steps to ensure the security and integrity of electronic signatures and records. This may include implementing encryption, access controls, and authentication measures.
- [x] **Intent to Sign**: "Parties must demonstrate their intent to sign [..]"
- [x] **Consent**: "The ESIGN Act requires that all parties involved in a transaction consent to the use of electronic signatures and records [..]"
- [x] **Consumer Disclosures**: Before obtaining their consent, financial institutions must provide the consumer a clear and conspicuous statement informing the consumer [..]
- [x] **Record Retention**: Electronic Records must be maintained for later access by signers.
- [x] **Security**: The ESIGN Act does not mandate specific security measures, but it does require that parties take reasonable steps to ensure the security and integrity of electronic signatures and records. This may include implementing encryption, access controls, and authentication measures.
## UETA (Uniform Electronic Transactions Act)
<Callout type="info" emoji="✅">
Status: Compliant
</Callout>
The Uniform Electronic Transactions Act is a law that provides a legal framework for the use of electronic
signatures and records in electronic transactions, ensuring they have the same validity and enforceability
as paper documents and handwritten signatures.
The Uniform Electronic Transactions Act is a law that provides a legal framework for the use of
electronic signatures and records in electronic transactions, ensuring they have the same validity
and enforceability as paper documents and handwritten signatures.
### Main Requirements
@@ -50,9 +55,9 @@ _See [ESIGN](/users/compliance/signature-levels#-esign-electronic-signatures-in-
<Callout type="info" emoji="✅">
Status: Compliant for Level 1 - SES (Simple Electronic Signatures)
</Callout>
eIDAS (Electronic Identification, Authentication and Trust Services) is an EU regulation that standardizes
electronic identification and trust services for secure and seamless electronic transactions across European
member states.
eIDAS (Electronic Identification, Authentication and Trust Services) is an EU regulation that
standardizes electronic identification and trust services for secure and seamless electronic
transactions across European member states.
### Level 1 - SES (Simple Electronic Signatures)
@@ -69,8 +74,8 @@ eIDAS SES (Simple Electronic Signature) is a basic electronic signature with min
Status: [Planned](https://github.com/documenso/backlog/issues/9) via third party until [Let's
Sign](https://github.com/documenso/backlog/issues/21) is realized.
</Callout>
eIDAS AES (Advanced Electronic Signature) provides a higher level of security with unique identification
of the signer and data integrity.
eIDAS AES (Advanced Electronic Signature) provides a higher level of security with unique
identification of the signer and data integrity.
### Main Requirements
@@ -85,8 +90,8 @@ of the signer and data integrity.
Status: [Planned](https://github.com/documenso/backlog/issues/32) via third party until [Let's
Sign](https://github.com/documenso/backlog/issues/21) is realized.
</Callout>
eIDAS QES (Qualified Electronic Signature) is the highest security level, legally equivalent to a handwritten
signature within the EU.
eIDAS QES (Qualified Electronic Signature) is the highest security level, legally equivalent to a
handwritten signature within the EU.
### Main Requirements
@@ -1,3 +1,8 @@
---
title: Standards and Regulations
description: Learn about the different standards and regulations for Documenso.
---
import { Callout } from 'nextra/components';
## 21 CFR Part 11
@@ -0,0 +1,10 @@
export default {
'sending-documents': 'Sending Documents',
'document-preferences': 'Document Preferences',
'document-visibility': 'Document Visibility',
fields: 'Document Fields',
'pdf-placeholders': 'PDF Placeholders',
'email-preferences': 'Email Preferences',
'ai-detection': 'AI Recipient & Field Detection',
'default-recipients': 'Default Recipients',
};
@@ -1,7 +0,0 @@
{
"sending-documents": "Sending Documents",
"document-preferences": "Document Preferences",
"document-visibility": "Document Visibility",
"fields": "Document Fields",
"email-preferences": "Email Preferences"
}
@@ -0,0 +1,68 @@
---
title: AI Recipient & Field Detection
description: Use Documensos AI helpers to detect recipients and fields in draft documents.
---
# AI Recipient & Field Detection
Documenso can suggest recipients and place fields automatically using Google Vertex AI (Gemini). The feature is optional and only available when your organisation or team has **AI Features** enabled. Documents are processed securely and providers do not retain your data for training.
## Requirements
- AI Features must be enabled in **Document Preferences** for your organisation or team.
- The envelope must be in **Draft** status.
- Helpful rate limits are in place (up to 3 detection requests per minute per IP) to prevent abuse. If you see a “too many requests” message, wait a minute or two and try again.
### Enable AI features
1. **Organisation settings**:
Settings → Document Preferences → **AI Features** → Enabled.
_This applies to teams that inherit organisation defaults._
2. **Team settings**:
Team Settings → Document Preferences → **AI Features** → choose Enabled, Disabled, or Inherit.
## Detect recipients
Use this to identify who needs to sign or approve.
1. Open a draft document/template and go to the **Recipients** panel.
2. Select the **sparkle** button to start detection. If AI is enabled, uploads launched from the dashboard will open the detector automatically.
![Detect recipients with AI button in the Recipients panel](/document-signing/ai-recipient-detect-button.webp)
3. Wait for progress to finish, then review the suggested recipients.
4. Remove any incorrect entries, then **Add recipients** to apply them. Existing recipients and duplicates are preserved.
Notes:
- Detection is unavailable once an envelope is completed.
- You can re-run detection if you update the document; each run counts toward the rate limit.
## Detect fields
Use this to auto-place fields on the pages of a draft.
1. Open the envelope editor and switch to the **Fields** tab.
2. Select **Detect with AI**. Provide optional context (e.g., “Alice is the tenant, Bob is the landlord”) to improve recipient assignment.
![AI field detection dialog with context input](/document-signing/ai-field-detection-button.webp)
![AI field detection dialog with context input](/document-signing/ai-field-detection-dialog.webp)
3. Watch the progress indicators; they update per page and total fields found.
4. Review the summary and choose **Add fields** to place them in the editor.
Notes:
- Works only for draft envelopes and teams with AI features enabled.
- Existing fields are masked during detection to avoid duplicates.
- Fields are assigned to recipients based on nearby labels and your context message; you can edit them after adding.
## Best practices
- Keep labels near the intended fields (e.g., “Tenant signature”, “Buyer email”).
- Provide short context when roles are ambiguous.
- Always review suggestions before sending; AI assists but does not replace final checks.
@@ -0,0 +1,45 @@
---
title: Default Document Recipients
description: Learn how to set default recipients with various roles for your documents.
---
import { Callout, Steps } from 'nextra/components';
# Default Document Recipients
Documenso allows you to set default recipients for your documents. This is useful when you require specific recipients to be added to every document you send.
You can add default recipients with the same roles as the recipients you can add when sending a document:
- **Signer** - The recipient will be required to sign the document.
- **Approver** - The recipient will be required to approve the document.
- **Viewer** - The recipient will be required to view the document.
- **CC** - The recipient will receive a copy of the document.
You can set default recipients at the organisation or team level.
### Organisation level
To set default recipients at the organisation level, navigate to the organisation settings page and click the "Document" tab under the "Preferences" section.
Then scroll down to the "Default Recipients" section and add the recipients you want to be included in every document you send.
![A screenshot of the organisation's default recipients page](/default-recipients/organisation-default-recipients-select-step.webp)
The recipients are added with the "CC" role by default, but you can select a different role for each recipient.
![A screenshot of the organisation's default recipients page when selecting the role of the recipient](/default-recipients/organisation-default-recipients-role-step.webp)
### Team level
Setting the default recipients at the team level follows the same process as setting them at the organisation level.
<Callout type="info">
Setting the default recipients at the team level will override organisation-level defaults.
</Callout>
To set default recipients at the team level, navigate to the team settings page and click the "Document" tab under the "Preferences" section.
Then scroll down to the "Default Recipients" section. By default, the team will inherit the default recipients from the organisation. You can override these defaults by adding the recipients you want to be added to every document you send.
![A screenshot of the team's default recipients page](/default-recipients/team-default-recipients.webp)
@@ -11,120 +11,76 @@ Learn about the different fields you can add to your documents in Documenso and
The signature field collects the signer's signature. It's required for each recipient with the "Signer" role.
### Document Editor View
The field doesn't have any additional settings. You just need to place it on the document where you want the signer to sign.
![The signature field in the Documenso document editor](/document-signing/signature-field-document-editor-view.webp)
### Document Signing View
The signature field settings include:
The recipient will see the signature field when they open the document to sign.
The recipient must click on the signature field to open the signing view, where they can sign using their mouse, touchpad, or touchscreen.
![The signature field in the Documenso document signing view](/document-signing/signature-field-document-signing-view.webp)
The image below shows the signature field signed by the recipient.
![The signature field signed by the user in the Documenso document signing view](/document-signing/signed-signature-field.webp)
After signing, the recipient can click the "Complete" button to complete the signing process.
- **Font size** - The typed signature font size. You can disable typed signatures in the document settings.
## Email Field
The email field is used to collect the signer's email address.
### Document Editor View
The field doesn't have any additional settings. You just need to place it on the document where you want the signer to sign.
The email field is used to collect the signer's email address. This will be the email address you entered when you created the recipients.
![The email field in the Documenso document editor](/document-signing/email-field-document-editor-view.webp)
### Document Signing View
The email field settings include:
When the recipient opens the document to sign, they will see the email field.
The recipient must click on the email field to automatically sign the field with the email associated with their account.
![The email field in the Documenso document signing view](/document-signing/email-field-document-signing-view.webp)
The image below shows the email field signed by the recipient.
![The email field signed by the user in the Documenso document signing view](/document-signing/signed-email-field.webp)
After entering their email address, the recipient can click the "Complete" button to complete the signing process.
- **Font Size** - The font size of the email address.
- **Text Align** - The horizontal text alignment of the email address.
## Name Field
The name field is used to collect the signer's name.
### Document Editor View
The field doesn't have any additional settings. You just need to place it on the document where you want the signer to sign.
![The name field in the Documenso document editor](/document-signing/name-field-document-editor-view.webp)
### Document Signing View
The name field settings include:
When the recipient opens the document to sign, they will see the name field.
- **Font Size** - The font size of the name.
- **Text Align** - The horizontal text alignment of the name.
The recipient must click on the name field, which will automatically sign the field with the name associated with their account.
## Initials Field
![The name field in the Documenso document signing view](/document-signing/name-field-document-signing-view.webp)
The initials field is used to collect the signer's initials. This is generally the first and last name initials.
The image below shows the name field signed by the recipient.
![The initials field in the Documenso document editor](/document-signing/initials-field-document-editor-view.webp)
![The name field signed by the user in the Documenso document signing view](/document-signing/name-field-signed.webp)
The initials field settings include:
After entering their name, the recipient can click the "Complete" button to complete the signing process.
- **Font Size** - The font size of the initials.
- **Text Align** - The horizontal text alignment of the initials.
## Date Field
The date field is used to collect the date of the signature.
### Document Editor View
The field doesn't have any additional settings. You just need to place it on the document where you want the signer to sign.
The date field is used to collect the date of the signature. You can change the date format in the document settings.
![The date field in the Documenso document editor](/document-signing/date-field-document-editor-view.webp)
### Document Signing View
The date field settings include:
When the recipient opens the document to sign, they will see the date field.
The recipient must click on the date field to automatically sign the field with the current date and time.
![The date field in the Documenso document signing view](/document-signing/date-field-document-signing-view.webp)
The image below shows the date field signed by the recipient.
![The date field signed by the user in the Documenso document signing view](/document-signing/date-field-signed.webp)
After entering the date, the recipient can click the "Complete" button to complete the signing process.
- **Font Size** - The font size of the date.
- **Text Align** - The horizontal text alignment of the date.
## Text Field
The text field is used to collect text input from the signer.
### Document Editor View
Place the text field on the document where you want the signer to enter text. The text field comes with additional settings that can be configured.
![The text field in the Documenso document editor](/document-signing/text-field-document-editor-view.webp)
To open the settings, click on the text field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.
![The text field settings in the Documenso document editor](/document-signing/text-field-advanced-settings-document-editor-view.webp)
The text field settings include:
- **Label** - The label displayed in the field.
- **Placeholder** - The placeholder text displayed in the field.
- **Text** - The default text displayed in the field.
- **Label** - The label displayed in the field when the user opens the document to sign
- **Placeholder** - The placeholder text displayed in the field. The signer will see this prior to signing.
- **Text** - The text which will be prefilled into the field. The signer can change this text unless the field is read-only.
- **Character limit** - The maximum number of characters allowed in the field.
- **Required** - Whether the field is required or not.
- **Read only** - Whether the field is read-only or not.
- **Text Align** - The horizontal text alignment of the text in the field.
- **Vertical Align** - The vertical text alignment of the text in the field.
- **Line height** - The line height of the text in the field. Useful for multi-line text fields.
- **Letter spacing** - The spacing between each character in the text in the field.
It also comes with a couple of rules:
@@ -133,71 +89,26 @@ It also comes with a couple of rules:
- The signer must fill out a required field.
- The text field characters count can't exceed the character limit.
- The signer can't modify a read-only field.
- The field auto-signs if there is a default text value.
Let's look at the following example.
![A text field with the settings configured by the user in the Documenso document editor](/document-signing/text-field-with-filled-advanced-settings.webp)
The field is configured as follows:
- Label: "Address"
- Placeholder: "Your office address"
- Default Text: "Signing Street 1, 241245"
- Character Limit: 35
- Required: False
- Read Only: False
Since the field has a label set, the label is displayed instead of the default text field value - "Add text".
### Document Signing View
What the recipient sees when they open the document to sign depends on the settings configured by the sender.
In this case, the recipient sees the text field signed with the default value.
![Text field with the default value signed by the user in the Documenso document signing view](/document-signing/text-field-autosigned.webp)
The recipient can modify the text field value since the field is not read-only. To change the value, the recipient must click the field to un-sign it.
Once it's unsigned, the field uses the label set by the sender.
![Unsigned text field in the Documenso document signing view](/document-signing/text-field-unsigned.webp)
To sign the field with a different value, the recipient needs to click on the field and enter the new value.
![Text field with the text input in the Documenso document signing view](/document-signing/text-field-input-modal.webp)
Since the text field has a character limit, the recipient must enter a value that doesn't exceed the limit. Otherwise, an error message will appear, and the field will not be signed.
The image below illustrates the text field signed with a new value.
![Text field signed with a new value](/document-signing/text-field-new-value-signed.webp)
After signing the field, the recipient can click the "Complete" button to complete the signing process.
- The field will be inserted automatically into the document if there is a default text value.
## Number Field
The number field is used for collecting a number input from the signer.
### Document Editor View
Place the number field on the document where you want the signer to enter a number. The number field comes with additional settings that can be configured.
![The number field in the Documenso document editor](/document-signing/number-field-document-editor.webp)
To open the settings, click on the number field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.
![The number field in the Documenso document editor](/document-signing/number-field-document-editor-view.webp)
The number field settings include:
- **Label** - The label displayed is the field.
- **Placeholder** - The placeholder text displayed in the field.
- **Value** - The default number displayed in the field.
- **Value** - The value which will be prefilled into the field. The signer can change this value unless the field is read-only.
- **Number format** - The format of the number.
- **Required** - Whether the field is required or not.
- **Read only** - Whether the field is read-only or not.
- **Text Align** - The horizontal text alignment of the number in the field.
- **Vertical Align** - The vertical text alignment of the number in the field.
- **Line height** - The line height of the number in the field. Useful for multi-line number fields.
- **Letter spacing** - The spacing between each character in the number in the field.
- **Validation** - The validation rules for the field.
It also comes with a couple of rules:
@@ -210,66 +121,18 @@ It also comes with a couple of rules:
- If the default number and a min value are set, the default number must be greater than the min value.
- The value must match the number format if a number format is set.
In this example, the number field is configured as follows:
- Label: "Quantity"
- Placeholder: "Enter the preferred quantity"
- Default Value: 12
- Number Format: "123,456,789.00"
- Required: False
- Read Only: False
- Validation:
- Min value: 5, Max value: 50
![A number field with the label configured by the user in the Documenso document editor](/document-signing/number-field-label.webp)
Since the field has a label set, the label is displayed instead of the default number field value - "Add number".
### Document Signing View
What the recipient sees when they open the document to sign depends on the settings configured by the sender.
The recipient sees the number field signed with the default value in this case.
![Number field with the default value signed by the user in the Documenso document signing view](/document-signing/number-field-autosigned.webp)
Since the number field is not read-only, the recipient can modify its value. To change the value, the recipient must click the field to un-sign it.
Once it's unsigned, the field uses the label set by the sender.
![Unsigned number field in the Documenso document signing view](/document-signing/number-field-unsigned.webp)
To sign the field with a different value, the recipient needs to click on the field and enter the new value.
![Number field with the number input in the Documenso document signing view](/document-signing/number-field-input-modal.webp)
Since the number field has a validation rule set, the recipient must enter a value that meets the rules. In this example, the value needs to be between 5 and 50. Otherwise, an error message will appear, and the field will not be signed.
The image below illustrates the text field signed with a new value.
![Number field signed with a new value](/document-signing/number-field-signed-with-another-value.webp)
After signing the field, the recipient can click the "Complete" button to complete the signing process.
## Radio Field
The radio field is used to collect a single choice from the signer.
### Document Editor View
Place the radio field on the document where you want the signer to select a choice. The radio field comes with additional settings that can be configured.
![The radio field in the Documenso document editor](/document-signing/radio-field-document-editor-view.webp)
To open the settings, click on the radio field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.
![The radio field advanced settings in the Documenso document editor](/document-signing/radio-field-advanced-settings-document-editor-view.webp)
The radio field settings include:
- **Required** - Whether the field is required or not.
- **Read only** - Whether the field is read-only or not.
- **Values** - The list of choices for the field.
- **Direction** - The direction of the radio field. Can be "Vertical" or "Horizontal".
It also comes with a couple of rules:
@@ -282,57 +145,22 @@ It also comes with a couple of rules:
- It should contain at least one option.
- The field can't have more than one option selected.
In this example, the radio field is configured as follows:
- Required: False
- Read Only: False
- Options:
- Option 1
- Option 2
- Empty value
- Empty value
- Option 3
![The radio field with the settings configured by the user in the Documenso document editor](/document-signing/radio-field-options-document-editor-view.webp)
Since the field contains radio options, it displays them instead of the default radio field value, "Radio".
### Document Signing View
What the recipient sees when they open the document to sign depends on the settings configured by the sender.
In this case, the recipient sees the radio field unsigned because the sender didn't select a value.
![Radio field with no value selected in the Documenso document signing view](/document-signing/radio-field-unsigned.webp)
The recipient can select one of the options by clicking on the radio button next to the option.
![Radio field with the value selected by the user in the Documenso document signing view](/document-signing/radio-field-signed.webp)
After signing the field, the recipient can click the "Complete" button to complete the signing process.
## Checkbox Field
The checkbox field is used to collect multiple choices from the signer.
### Document Editor View
Place the checkbox field on the document where you want the signer to select choices. The checkbox field comes with additional settings that can be configured.
![The checkbox field in the Documenso document editor](/document-signing/checkbox-document-editor-view.webp)
To open the settings, click on the checkbox field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.
![The checkbox field settings in the Documenso document editor](/document-signing/checkbox-advanced-settings.webp)
![The checkbox field in the Documenso document editor](/document-signing/checkbox-field-document-editor-view.webp)
The checkbox field settings include the following:
- **Validation** - The validation rules for the field.
- **Rule** - The rule specifies "At least", "At most", and "Exactly".
- **Number** - The number of choices that must be selected.
- **Required** - Whether the field is required or not.
- **Read only** - Whether the field is read-only or not.
- **Options** - The list of choices for the field.
- **Direction** - The direction of the checkbox field. Can be "Vertical" or "Horizontal".
- **Validation Rule** - The rule specifies "At least", "At most", and "Exactly".
- **Validation Number** - The number of choices that must be selected.
It also comes with a couple of rules:
@@ -344,67 +172,20 @@ It also comes with a couple of rules:
- The signer can't modify the field if it's read-only.
- It should contain at least one option.
In this example, the checkbox field is configured as follows:
- No validation rules
- Required: True
- Read Only: False
- Options:
- Option 1
- Empty value (checked)
- Option 2
- Option 3 (checked)
- Empty value
![The checkbox field with the settings configured by the user in the Documenso document editor](/document-signing/checkbox-advanced-settings-document-editor-view.webp)
Since the field contains checkbox options, it displays them instead of the default checkbox field value, "Checkbox".
### Document Signing View
What the recipient sees when they open the document to sign depends on the settings configured by the sender.
In this case, the recipient sees the checkbox field signed with the values selected by the sender.
![Checkbox field with the values selected by the user in the Documenso document signing view](/document-signing/checkbox-field-document-signing-view.webp)
Since the field is required, the recipient can either sign with the values selected by the sender or modify the values.
The values can be modified in 2 ways:
- Click on the options you want to select or deselect.
- Hover over the field and click the "X" button to clear all the selected values.
The image below illustrates the checkbox field with the values cleared by the recipient. Since the field is required, it has a red border instead of the yellow one (non-required fields).
![Checkbox field the values cleared by the user in the Documenso document signing view](/document-signing/checkbox-field-unsigned.webp)
Then, the recipient can select values other than the ones chosen by the sender.
![Checkbox field with the values selected by the user in the Documenso document signing view](/document-signing/checkbox-field-custom-sign.webp)
After signing the field, the recipient can click the "Complete" button to complete the signing process.
## Dropdown/Select Field
The dropdown/select field collects a single choice from a list of options.
### Document Editor View
Place the dropdown/select field on the document where you want the signer to select a choice. The dropdown/select field comes with additional settings that can be configured.
![The dropdown/select field in the Documenso document editor](/document-signing/select-field-sliders.webp)
To open the settings, click on the dropdown/select field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.
![The dropdown/select field settings in the Documenso document editor](/document-signing/select-field-advanced-settings-panel.webp)
![The dropdown/select field in the Documenso document editor](/document-signing/dropdown-field-document-editor-view.webp)
The dropdown/select field settings include:
- **Required** - Whether the field is required or not.
- **Read only** - Whether the field is read-only or not.
- **Options** - The list of choices for the field.
- **Default** value - The default value selected in the field.
- **Default Value** - The default value selected in the field.
It also comes with a couple of rules:
@@ -416,31 +197,3 @@ It also comes with a couple of rules:
- The field can't be signed with a value not in the options list.
- The signer can't modify the field if it's read-only.
- It should contain at least one option.
In this example, the dropdown/select field is configured as follows:
- Required: False
- Read Only: False
- Default Value: None
- Options:
- Document
- Template
- Other
### Document Signing View
What the recipient sees when they open the document to sign depends on the settings configured by the sender.
In this case, the recipient sees the dropdown/select field with the default label, "-- Select ---" since the sender has not set a default value.
![Dropdown/select field in the Documenso document signing view](/document-signing/select-field-unsigned.webp)
The recipient can modify the dropdown/select field value since the field is not read-only. To change the value, the recipient must click on the field for the dropdown list to appear.
![Dropdown/select field with the dropdown list in the Documenso document signing view](/document-signing/select-field-unsigned-dropdown.webp)
The recipient can select one of the options from the list. The image below illustrates the dropdown/select field signed with a new value.
![Dropdown/select field signed with a value](/document-signing/select-field-signed.webp)
After signing the field, the recipient can click the "Complete" button to complete the signing process.
@@ -0,0 +1,179 @@
---
title: PDF Placeholders
description: Learn how to use placeholder text in your PDFs for automatic field placement in Documenso.
---
import { Callout } from 'nextra/components';
# PDF Placeholders
Documenso can automatically detect placeholder text in your PDF documents and create fields at those locations. This allows you to prepare documents in your preferred editing tool (Word, Google Docs, etc.) with placeholders that become signature fields when uploaded.
## How It Works
When you upload a PDF, Documenso scans for text matching the placeholder pattern `{{...}}`. Each placeholder can specify:
1. **Field type** - What kind of field to create (signature, name, email, etc.)
2. **Recipient** - Which signer the field belongs to (r1, r2, etc.)
3. **Options** - Additional settings like required, read-only, font size, etc.
The placeholder text is automatically hidden after fields are created, so your final document looks clean.
## Placeholder Format
The basic format is:
```
{{FIELD_TYPE, RECIPIENT, option1=value1, option2=value2}}
```
### Examples
| Placeholder | Description |
| ----------------------------- | ----------------------------------- |
| `{{signature, r1}}` | Signature field for recipient 1 |
| `{{name, r1}}` | Name field for recipient 1 |
| `{{email, r2}}` | Email field for recipient 2 |
| `{{date, r1}}` | Date field for recipient 1 |
| `{{text, r1, required=true}}` | Required text field for recipient 1 |
| `{{initials, r1}}` | Initials field for recipient 1 |
## Supported Field Types
The following field types are supported in placeholders:
| Field Type | Placeholder Value |
| ---------- | ----------------- |
| Signature | `signature` |
| Initials | `initials` |
| Name | `name` |
| Email | `email` |
| Date | `date` |
| Text | `text` |
| Number | `number` |
| Radio | `radio` |
| Checkbox | `checkbox` |
| Dropdown | `dropdown` |
<Callout type="info">
Field types are case-insensitive. `{{ SIGNATURE, r1 }}` and `{{ signature, r1 }}` are equivalent.
</Callout>
## Recipient Identifiers
Recipients are identified using `r1`, `r2`, `r3`, etc. The number corresponds to the order in which recipients are created:
- `r1` - First recipient
- `r2` - Second recipient
- `r3` - Third recipient
When you upload a PDF with placeholders, Documenso will:
1. Create placeholder recipients for each unique identifier found (e.g., `r1`, `r2`)
2. You can then update these with real email addresses before sending
<Callout type="warning">
Placeholders without a recipient identifier (e.g., `{{ signature }}` without `r1`) are reserved
for API use and will not create fields during upload.
</Callout>
## Field Options
You can customize fields by adding options after the recipient identifier:
### Common Options
| Option | Values | Description |
| ----------- | ------------------------- | ------------------------------------------ |
| `required` | `true`, `false` | Whether the field must be filled |
| `readOnly` | `true`, `false` | Whether the field is pre-filled and locked |
| `fontSize` | Number (e.g., `12`) | Font size in points |
| `textAlign` | `left`, `center`, `right` | Horizontal text alignment |
### Text Field Options
| Option | Values | Description |
| ---------------- | ------ | ------------------------------------- |
| `label` | Text | Label shown in the field |
| `placeholder` | Text | Placeholder text shown before signing |
| `text` | Text | Pre-filled text value |
| `characterLimit` | Number | Maximum characters allowed |
### Number Field Options
| Option | Values | Description |
| -------------- | ------------- | --------------------- |
| `value` | Number | Pre-filled value |
| `minValue` | Number | Minimum allowed value |
| `maxValue` | Number | Maximum allowed value |
| `numberFormat` | Format string | Number display format |
### Examples with Options
```
{{text, r1, required=true, label=Company Name}}
{{number, r1, minValue=0, maxValue=100, value=50}}
{{name, r1, fontSize=14}}
{{text, r2, readOnly=true, text=Contract #12345}}
```
<Callout type="info">
Signature and Free Signature fields do not support additional options beyond the field type and
recipient.
</Callout>
## Multiple Recipients Example
Here's how a document might look with placeholders for two signers:
```
AGREEMENT
Party A Signature: {{signature, r1}}
Party A Name: {{name, r1}}
Party A Date: {{date, r1}}
Party B Signature: {{signature, r2}}
Party B Name: {{name, r2}}
Party B Date: {{date, r2}}
```
When uploaded, this creates:
- 3 fields assigned to recipient 1 (Party A)
- 3 fields assigned to recipient 2 (Party B)
- 2 placeholder recipients that you can update with real email addresses
## Tips for Creating Documents
1. **Use a readable font** - Placeholders need to be readable by the PDF parser. Standard fonts like Arial, Helvetica, or Times New Roman work best.
2. **Don't split placeholders** - Ensure the entire placeholder text `{{...}}` is on a single line and not broken across text boxes.
3. **Size matters** - The field will be sized to match the placeholder text width. Use spaces or longer placeholder text if you need wider fields.
4. **Test with a draft** - Upload your document as a draft first to verify fields are detected correctly before sending.
<Callout type="info">
Placeholder detection happens automatically when you upload a PDF. You can review and adjust the
created fields in the document editor before sending.
</Callout>
## Troubleshooting
### Placeholders Not Detected
- Ensure placeholders use double curly braces: `{{...}}`
- Check that the placeholder includes a recipient identifier (e.g., `r1`)
- Verify the field type is spelled correctly
- Try using a standard font in your source document
### Wrong Field Position
- The field is placed at the exact location of the placeholder text
- If the position seems off, check that your PDF wasn't scaled or reformatted when exported
### Placeholder Text Still Visible
- Placeholder text is covered with a white rectangle after field creation
- If you see the text, try re-uploading the document
@@ -9,90 +9,85 @@ import { Callout, Steps } from 'nextra/components';
This guide will walk you through the process of sending a document out for signing. You will learn how to upload a document, add recipients, place signature fields, and send the document for signing.
## Uploading a Document
<Steps>
### Login Into Your Account
### Log In to Your Account
The guide assumes you have a Documenso account. If you don't, you can create a free account [here](https://documen.so/free-docs).
### Upload Document
Navigate to the [Documenso dashboard](https://app.documenso.com/documents) and click on the "Add a document" button. Select the document you want to upload and wait for the upload to complete.
Navigate to the [Documenso dashboard](https://app.documenso.com/documents) and click on the "Upload Document" button located at the top right of the page. Select the documents you want to upload and wait for the upload to complete.
<Callout type="info">
The maximum file size for uploaded documents is 150MB in production. In staging, the limit is
50MB.
The maximum file size for uploaded documents is 150MB in production. You can upload up to 5
documents at a time on standard plans. In staging, the limit is 50MB.
</Callout>
![Documenso dashboard](/document-signing/documenso-documents-dashboard.webp)
After the upload is complete, you will be redirected to the document's page. You can configure the document's settings and add recipients and fields here.
After the upload is complete, you will be redirected to the editor. You can configure the document's settings and add recipients and fields here.
![Documenso document overview](/document-signing/documenso-uploaded-document.webp)
</Steps>
### (Optional) Advanced Options
## Configuring and Sending Document
Click on the "Advanced options" button to access additional settings for the document. You can set an external ID, date format, time zone, and the redirect URL.
The Documenso editor allows you to create and configure documents or templates. The editor consists of three sections that guide you through the process of preparing your document.
![Advanced settings for a document uploaded in the Documenso dashboard](/document-signing/documenso-uploaded-document-advanced-options.webp)
1. **Document & Recipients** - Upload files and add recipients
2. **Add Fields** - Add fields to the document
3. **Preview** - Preview the document before sending
The external ID allows you to set a custom ID for the document that can be used to identify the document in your external system(s).
You can click each section to navigate to it, and the current section will be highlighted in the sidebar.
The date format and time zone settings allow you to customize how the date and time are displayed in the document.
![Editor page in the Documenso dashboard](/document-signing/editor-overview.webp)
The redirect URL allows you to specify a URL where the signer will be redirected after signing the document.
There is also a quick actions section on the left-hand side which allows you to:
### (Optional) Document Access
- **Document Settings** - Configure general settings, emails, or security settings for the document
- **Send Document** - Send the document to the recipients
- **Duplicate** - Duplicate the document
- **Download** - Download the document PDF
- **Delete** - Delete the document
Documenso enables you to set up access control for your documents. You can require authentication for viewing the document.
The header contains some notable items:
The available options are:
- **Title** - You can edit the title in the top-left corner of the header by clicking on the text
- **Status** - You can see the current status of the document next to the title
- **Attachments** - You can configure the attachments on the right-hand side of the header
- **Require account** - The recipient must be signed in to view the document.
- **None** - The document can be accessed directly by the URL sent to the recipient.
<Steps>
![Document access settings in the Documenso dashboard](/document-signing/documenso-enterprise-document-access.webp)
### Upload Documents and Add Recipients
The first step in the editor is to upload your document and add recipients.
![Upload and add recipients page in the Documenso editor](/document-signing/editor-upload-recipients.webp)
#### Upload Document
You can upload documents by either clicking the "Add a document" dropzone, or dragging and dropping files into the dropzone.
<Callout type="info">
The "Document Access" feature is only available for Enterprise accounts.
The maximum file size for uploaded documents is 150MB in production. You can upload up to 5
documents at a time on standard plans. In staging, the limit is 50MB.
</Callout>
### (Optional) Recipient Authentication
#### Add Recipients
The "Recipient Authentication" feature allows you to specify the authentication method required for recipients to sign the signature field.
Click the "+ Add Signer" button to add a new recipient. For each recipient you can configure the following:
The available options are:
- **Email address** - The recipient's email address
- **Name** - The recipient's name
- **Order** - The sequence in which the recipient should sign the document. Only available if the "Enable Signing Order" checkbox is enabled
- **Role** - As seen below
- **Require passkey** - The recipient must have an account and passkey configured via their settings.
- **Require 2FA** - The recipient must have an account and 2FA enabled via their settings.
- **None** - No authentication required.
![Document recipient action authentication in the Documenso dashboard](/document-signing/document-enterprise-recipient-action-authentication.webp)
This can be overridden by setting the authentication requirements directly for each recipient in the next step.
<Callout type="info">
The "Recipient Authentication" feature is only available for Enterprise accounts.
</Callout>
### Recipients
Click the "+ Add Signer" button to add a new recipient. You can configure the recipient's email address, name, role, and authentication method on this page.
You can choose any option from the ["Recipient Authentication"](#optional-recipient-authentication) section, or you can set it to "Inherit authentication method" to use the global action signing authentication method configured in the "General Settings" step.
![The required authentication method for a recipient](/document-signing/documenso-document-recipient-authentication-method.webp)
You can also set the recipient's role, which determines their actions and permissions in the document.
![The recipient role](/document-signing/documenso-document-recipient-role.webp)
#### Roles
Documenso has 4 roles for recipients with different permissions and actions.
Documenso has 5 roles for recipients with different permissions and actions.
| Role | Function | Action required | Signature |
| :-------: | :-----------------------------------------------------------------------------: | :-------------: | :-------: |
| Signer | Needs to sign signatures fields assigned to them. | Yes | Yes |
| Signer | Needs to sign signature fields assigned to them. | Yes | Yes |
| Approver | Needs to approve the document as a whole. Signature optional. | Yes | Optional |
| Viewer | Needs to confirm they viewed the document. | Yes | No |
| Assistant | Can help prepare the document by filling in fields on behalf of other signers. | Yes | No |
@@ -100,15 +95,20 @@ Documenso has 4 roles for recipients with different permissions and actions.
### Fields
Documenso supports 9 different field types that can be added to the document. Each field type collects various information from the recipients when they sign the document.
Documenso supports 10 different field types that can be added to the document. Each field type collects various information from the recipients when they sign the document.
To create a field, you can either click and drag to draw a field on the document or drag and drop the field type from the sidebar.
![The available field types in the Documenso dashboard](/document-signing/documenso-document-fields.webp)
The field created will be assigned to the currently selected recipient. You can change the recipient by clicking on the recipient's name in the right sidebar.
The available field types are:
- **Signature** - Collects the signer's signature
- **Email** - Collects the signer's email address
- **Name** - Collects the signer's name
- **Initials** - Collects the signer's initials
- **Date** - Collects the date of the signature
- **Text** - Collects text input from the signer
- **Number** - Collects a number input from the signer
@@ -123,11 +123,11 @@ All fields can be placed anywhere on the document and resized as needed.
page](/users/documents/fields).
</Callout>
#### Signature Required
### Preview
Signer Roles require at least 1 signature field. You will get an error message if you try to send a document without a signature field.
In this section, you can preview what the document will look like once it is fully signed. This uses placeholder data for the fields.
![Error message when trying to send a document without a signature field](/document-signing/documenso-no-signature-field-found.webp)
![Preview section in the Documenso editor](/document-signing/documenso-editor-preview.webp)
### Email Settings
@@ -156,3 +156,54 @@ https://app.documenso.com/sign/12ACP777zxQLO52hjj_vCB
```
</Steps>
## Document Settings
To access the document settings, click the "Document Settings" button in the quick actions section.
### General Settings
![General Documenso editor settings](/document-signing/documenso-editor-general-settings.webp)
- **Language** - The language that the emails will be sent in
- **Allowed Signature Types** - The signature types that the recipient will be allowed to use
- **Date Format** - The date format that will be used for date fields
- **Time Zone** - The time zone that will be used for date fields
- **External ID** - A custom ID for the document that can be used to identify the document in your external system(s)
- **Redirect URL** - The URL where the signer will be redirected after signing the document
- **Document Distribution Method** - Whether to use emails to send the document, or none (which we will generate signing links for manual distribution)
### Email Settings
![Email Documenso editor settings](/document-signing/documenso-editor-email-settings.webp)
- **Reply To** - The email address that will be used as the reply to email address
- **Subject** - The subject of the email
- **Message** - The message of the email
- **Checkboxes** - You can select which emails should be sent during the document signing process
### Security Settings
Documenso enables you to set up access control for your documents. You can require authentication for viewing the document.
The available options are:
- **Require account** - The recipient must be signed in to view the document.
- **Require 2FA** - The recipient must use 2FA to sign the document.
- **None** - The document can be accessed directly by the URL sent to the recipient.
![Security Documenso editor settings](/document-signing/documenso-editor-security-settings.webp)
The "Recipient Authentication" feature allows you to specify the authentication method required for recipients to sign the signature field.
The available options are:
- **Require passkey** - The recipient must have an account and passkey configured via their settings.
- **Require 2FA** - The recipient must have an account and 2FA enabled via their settings.
- **None** - No authentication required.
This can be overridden by setting the authentication requirements directly for each recipient in the next step.
<Callout type="info">
The "Recipient Authentication" feature is only available for Enterprise accounts.
</Callout>
@@ -1,3 +1,8 @@
---
title: Email Domains
description: Learn how to create and manage email domains in Documenso.
---
import { Callout, Steps } from 'nextra/components';
# Email Domains
+25 -12
View File
@@ -7,28 +7,41 @@ import { Callout } from 'nextra/components';
# Fair Use Policy
### Why
We like to overdeliver, but we cannot overcommit.
We offer our plans without any limits on volume because we want our users and customers to make the most of their accounts. Estimating volume is incredibly hard, especially for shorter intervals like a quarter. We are not interested in selling volume packages our customers end up not using. This is why the individual plan and the team plan do not include a limit on signing or API volume. If you are a customer of these [plans](https://documen.so/pricing), we ask you to abide by this fair use policy:
Our plans are designed to be generous and flexible without forcing customers into rigid volume limits they may never use. At the same time, estimating usage at scale is hard, especially over short periods. This fair use policy exists to keep plans sustainable while allowing us to add more value wherever possible without overformalizing restrictions.
We offer our plans without any limits on volume because we want users and customers to make the most of their accounts. Estimating volume is incredibly hard, especially for shorter intervals like a quarter. We are not interested in selling volume packages our customers end up not using.
This is why our plans not include a limit on signing or API volume. If you are a customer of these plans, we ask you to abide by this fair use policy.
### Spirit of the Plan
> Use the limitless accounts as much as you like (they are meant to offer a lot) while respecting the spirit and intended scope of the account.
Use the limitless plans as much as you like. They are meant to offer a lot. Please respect the spirit and intended scope of the account.
<Callout type="info">
What happens if I violate this policy? We will ask you to upgrade to a fitting plan or custom
pricing. We wont block your account without reaching out. [Message
us](mailto:support@documenso.com) for questions. It's probably fine, though.
What happens if I go beyond the scope of this policy? We will ask you to upgrade to a fitting plan
or custom pricing. We will not block your account without reaching out. You can message us for
questions.
</Callout>
### Fair Support
We believe in fair support as much as fair usage.
Fair support includes reasonable and within reason application level help for self hosted users. We will help you get unstuck and point you in the right direction when issues come up. Support is provided in good faith and within reasonable time and effort limits. We are not your operations team and cannot take responsibility for running, monitoring, or maintaining your infrastructure.
If you are unsure whether something falls within fair use or fair support, reach out. We are happy to talk it through.
### DO
- Sign as many documents with the individual plan for your single business or organization you are part of
- Use the API and Zapier to automate all your signing to sign as much as possible
- Experiment with the plans and integrations, testing what you want to build: When in doubt, do it. Especially if you are just starting.
- Sign as many documents as you need with the individual plan for your single business or organization
- Use the API and automation tools to automate your signing workflows
- Experiment with plans and integrations while testing what you want to build
### DON'T
- Use the individual account's API to power a platform
- Run a huge company, signing thousands of documents per day on a two-user team plan using the API
- Let this policy make you overthink. If you are a paying customer, we want you to win, and it's probably fine
- Use an individual account API to power a platform or product
- Run a large company signing thousands of documents per day on a small team plan
- Expect enterprise level support for fair support plan
- Overthink this policy. If you are a paying customer, we want you to win
@@ -10,7 +10,12 @@ import { Callout, Steps } from 'nextra/components';
<Steps>
### Pick a Plan
The first step to start using Documenso is to pick a plan and create an account. At the moment of writing this guide, we have 3 plans available: Free, Individual, Teams and Platform.
The first step to start using Documenso is to pick a plan and create an account. At the moment of writing this guide, we have 4 plans available:
- Free
- Individual
- Teams
- Platform
Explore each plan's features and choose the one that best suits your needs. The [pricing page](https://documen.so/pricing) has more information about the plans.
@@ -24,7 +29,7 @@ To create a free account, navigate to the [registration page](https://documen.so
### Optional: Claim a Premium Username
You can claim a premium username by upgrading to a paid plan. After upgrading to a paid plan, you can update your [public profile](https://app.documenso.com/settings/public-profile).
You can claim a premium username by upgrading to a paid plan. After upgrading to a paid plan, you can update your [public profile](/users/profile).
### Optional: Create a Team
@@ -0,0 +1,5 @@
export default {
index: 'Overview',
'community-edition': 'Community Edition',
'enterprise-edition': 'Enterprise Edition',
};
@@ -1,5 +0,0 @@
{
"index": "Overview",
"community-edition": "Community Edition",
"enterprise-edition": "Enterprise Edition"
}
@@ -1,3 +1,8 @@
---
title: Community Edition
description: Learn about the Community Edition of Documenso.
---
import { Callout } from 'nextra/components';
# Community Edition
@@ -32,10 +37,10 @@ Documenso and the Community Edition are licensed under [AGPL3](https://github.co
### Conditions
License and copyright notice
State changes
Disclose source
Network use is distribution
- License and copyright notice
- State changes
- Disclose source
- Network use is distribution
<Callout type="warning">
It's important to remember that you must keep the AGPL3 license for your modified or non-modified
@@ -1,21 +1,57 @@
---
title: Enterprise Edition
description: Learn about the Enterprise Edition of Documenso.
---
import { Callout } from 'nextra/components';
# Enterprise Edition
The Documenso Enterprise Edition is our license for self-hosters that need the full range of support and compliance. Everything in the EE folder and all features listed [here](https://github.com/documenso/documenso/blob/main/packages/ee/FEATURES) can be used after acquiring a paid license.
## Includes
- Self-Host Documenso in any context.
- Premium Support via Slack, Discord and Email.
- Flexible Licensing (e.g. MIT) for deeper custom integration (if needed).
- Access to all Enterprise-grade compliance and administration features.
## Limitations
The Enterprise Edition currently has no limitations except custom contract terms.
<Callout type="info">
The Enterprise Edition requires a paid subscription. [Contact us for a
quote](https://documen.so/enterprise).
</Callout>
The Documenso Enterprise Edition is our license for self-hosters that need the full range of support and compliance.
The following features are included in the Enterprise Edition:
{/* Keep this synced with the packages/ee/FEATURES file */}
- The Stripe Billing Module
- Organisation Authentication Portal
- Document Action Reauthentication (Passkeys and 2FA)
- 21 CFR
- Email domains
- Embed authoring
- Embed authoring white label
In addition, you will receive:
- Premium Support via Slack, Discord and Email.
- Flexible Licensing (e.g. MIT) for deeper custom integration (if needed).
- Access to Enterprise-grade compliance and administration features.
- Permission to self-Host Documenso in any context.
The Enterprise Edition currently has no limitations except custom contract terms.
## Getting a License
To acquire an Enterprise Edition license, please [contact our sales team](https://documen.so/enterprise) for a quote. Our team will work with you to understand your requirements and provide a license that fits your needs.
## Using Your License
Once you have acquired an Enterprise Edition license:
1. Access your license key at [license.documenso.com](https://license.documenso.com)
2. Set the `NEXT_PRIVATE_DOCUMENSO_LICENSE_KEY` environment variable in your Documenso instance with your license key
```bash
NEXT_PRIVATE_DOCUMENSO_LICENSE_KEY="your-license-key-here"
```
3. You can verify your license status in the Admin Panel under the Stats section.
![Admin License Status](/images/admin-license-status.webp)
Your license will be verified on startup and periodically to ensure continued access to Enterprise features.
@@ -1,3 +1,8 @@
---
title: Licenses
description: Learn about the different licenses for self-hosting Documenso.
---
# Self-Hosting Licenses
Documenso comes in two versions for self-hosting:
@@ -0,0 +1,8 @@
export default {
index: 'Introduction',
members: 'Members',
groups: 'Groups',
teams: 'Teams',
sso: 'SSO',
billing: 'Billing',
};
@@ -1,8 +0,0 @@
{
"index": "Introduction",
"members": "Members",
"groups": "Groups",
"teams": "Teams",
"sso": "SSO",
"billing": "Billing"
}
@@ -0,0 +1,4 @@
export default {
index: 'Configuration',
'microsoft-entra-id': 'Microsoft Entra ID',
};
@@ -1,4 +0,0 @@
{
"index": "Configuration",
"microsoft-entra-id": "Microsoft Entra ID"
}
+1 -1
View File
@@ -15,7 +15,7 @@ Documenso allows you to create a public profile to share your templates for anyo
### Navigate to Your Profile Settings
Click on your profile picture in the top right corner and select "Settings" or "Team Settings". Then, navigate to the "Public Profile" tab to configure your profile.
Click on your profile picture in the top right corner and select "Team Settings". Then, navigate to the "Public Profile" tab to configure your profile.
![The profile settings page](/public-profile/documenso-public-profile-settings.webp)
+6 -6
View File
@@ -9,30 +9,30 @@ description: Learn what types of support we offer.
If you are a developer or free user, you can reach out to the community or raise an issue:
### [Create Github Issues](https://github.com/documenso/documenso/issues)
**[Create Github Issues](https://github.com/documenso/documenso/issues)**
The community and the core team address GitHub issues. Be sure to check if a similar issue already exists. Please note that while we want to address everything immediately, we must prioritize.
### [Join our Discord](https://documen.so/discord)
**[Join our Discord](https://documen.so/discord)**
You can ask for help in the [community help channel](https://discord.com/channels/1132216843537485854/1133419426524430376).
## Paid Account Support
### Email: support@documenso.com
**Email: support@documenso.com**
If you are paying customers facing issues, email our customer support, especially in urgent cases.
### Private Discord channel
**Private Discord channel**
If you prefer Discord, we can invite you to a private channel. Message support to make this happen.
## Enterprise Support
### Email: support@documenso.com
**Email: support@documenso.com**
If you are paying customers facing issues, email our customer support, especially in urgent cases.
### Slack
**Slack**
If your team is on Slack, we can create a private workspace to support you more closely.
+21 -55
View File
@@ -1,3 +1,8 @@
---
title: Templates
description: Learn how to create and use templates in Documenso.
---
import { Callout, Steps } from 'nextra/components';
# Document Templates
@@ -8,82 +13,43 @@ Documenso allows you to create templates, which are reusable documents. Template
### Create New Template
To create a new template, navigate to the ["Templates" page](https://app.documenso.com/templates) and click on the "New Template" button.
To create a new template, navigate to the "Templates" page and click on the "Upload Template" button.
![Documenso template page](/templates/documenso-template-page.webp)
Clicking on the "New Template" button opens a new modal to upload the document you want to use as a template. Select the document and wait for Documenso to upload it to your account.
You can select multiple files at once to upload into the template. Once the upload is complete you will be redirected to the editor.
![Upload a new template document in the Documenso dashboard](/templates/documenso-template-page-upload-document.webp)
![A successfully uploaded document in the Documenso dashboard](/templates/documenso-template-page-uploaded-document.webp)
Once the upload is complete, Documenso opens the template configuration page.
![A successfuly uploaded document in the Documenso dashboard](/templates/documenso-template-page-uploaded-document.webp)
See the [documents](/users/documents/sending-documents) page for more information on how to use the editor.
You can then configure the template by adding recipients, fields, and other options.
### (Optional) Email options
When you send a document for signing, Documenso emails the recipients with a link to the document. The email contains a subject, message, and the document.
Documenso uses a generic subject and message but also allows you to customize them for each document and template.
![Configuring the email options for the Documenso template](/templates/documenso-template-page-uploaded-document-email-options.webp)
To configure the email options, click the "Email Options" tab and fill in the subject and message fields. Every time you use this template for signing, Documenso will use the custom subject and message you provided. They can also be overridden before sending the document.
### (Optional) Advanced Options
The template also has advanced options that you can configure. These options include settings such as the external ID, date format, time zone and the redirect URL.
![Configuring the advanced options for the Documenso template](/templates/documenso-template-page-uploaded-document-advanced-options.webp)
The external ID allows you to set a custom ID for the document that can be used to identify the document in your external system(s).
The date format and time zone settings allow you to customize how the date and time are displayed in the document.
The redirect URL allows you to specify a URL where the signer will be redirected after signing the document.
### Add Placeholders or Recipients
You can add placeholders for the template recipients. Placeholders specify where the recipient's name, email, and other information should be in the document.
When adding recipients, you can use dummy recipients which can be replaced with actual recipients when you use a template, which we will explain in the next section.
You can also add recipients directly to the template. Recipients are the people who will receive the document for signing.
For example, the following has two recipients:
- placeholder@documenso.com
- me@documenso.com
![Adding placeholder recipients for the Documenso template](/templates/documenso-template-recipients.webp)
If you add placeholders to the template, you must replace them with actual recipients when creating a document from it. See the modal from the ["Use a Template"](#use-a-template) section.
### Add Fields
The last step involves adding fields to the document. These fields collect information from the recipients when they sign the document.
Documenso provides the following field types:
- **Signature** - Collects the signer's signature
- **Email** - Collects the signer's email address
- **Name** - Collects the signer's name
- **Date** - Collects the date of the signature
- **Text** - Collects text input from the signer
- **Number** - Collects a number input from the signer
- **Radio** - Collects a single choice from the signer
- **Checkbox** - Collects multiple choices from the signer
- **Dropdown/Select** - Collects a single choice from a list of choices
![Adding fields for the Documenso template](/templates/documenso-template-page-fields.webp)
After adding the fields, press the "Save Template" button to save the template.
You can then place fields for each recipient.
<Callout type="info">
Learn more about the available field types and how to use them on the [Fields
page](signing-documents/fields).
page](/users/documents/fields).
</Callout>
### Use a Template
Click on the "Use Template" button to create a new document from the template. Before creating the document, you are asked to fill in the recipients for the placeholders you added to the template.
Once you're ready to use the template, you can click the "Use Template" button in the top right corner.
After filling in the recipients, click the "Create Document" button to create the document in your account.
Here you can choose to use the template as is, or you can replace the emails or names with different recipients as you require.
You can now decide whether to create the document as a draft, or immediately send it to the recipients for signing.
![Use an available Documenso template](/templates/documenso-use-template.webp)
@@ -91,7 +57,7 @@ You can also send the document straight to the recipients for signing by checkin
### (Optional) Create A Direct Signing Link
A direct signing link allows you to create a shareable link for document signing, where recipients can fill in their information and sign the document. See the "Create Direct Link" button in the image from [step 4](#add-placeholders-or-recipients).
A direct signing link allows you to create a shareable link for document signing, where recipients can fill in their information and sign the document.
<Callout type="info">
Check out the [Direct Signing Links](/users/direct-links) section for more information.
+6
View File
@@ -0,0 +1,6 @@
module.exports = {
plugins: {
tailwindcss: {},
autoprefixer: {},
},
};
Binary file not shown.

Before

Width:  |  Height:  |  Size: 123 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 106 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 96 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 92 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 65 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 555 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 928 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 897 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 596 KiB

Some files were not shown because too many files have changed in this diff Show More