Compare commits
144 Commits
v1.8.1-rc.
...
v1.9.1-rc.
| Author | SHA1 | Date | |
|---|---|---|---|
| e95e13021d | |||
| 5dfb17c216 | |||
| 27b81bc807 | |||
| 6ce0be67ab | |||
| 123a709836 | |||
| ae6cc24317 | |||
| a41ac632d0 | |||
| 1789eff564 | |||
| 235d846d2b | |||
| ca3d65ad10 | |||
| 617e3a46e0 | |||
| 255c33cdab | |||
| 1560218d4a | |||
| 5c7768c253 | |||
| 7bb93e4233 | |||
| 42e39f7ef1 | |||
| 838e399c73 | |||
| b6a891acc8 | |||
| 84b4d58856 | |||
| c51c32fdc6 | |||
| 59c1e55233 | |||
| 2fbaf56c06 | |||
| 70320cd24b | |||
| 00b46561c2 | |||
| 11bc93a9a4 | |||
| 11528090a5 | |||
| 3c4863f285 | |||
| 2ff330f9d4 | |||
| ce1c93b2a6 | |||
| 82337e4e3a | |||
| 7d9a3f9776 | |||
| cbad065dac | |||
| 25a3861c91 | |||
| b9ae277041 | |||
| 7fad826d06 | |||
| eb8ba2036a | |||
| 339759166c | |||
| 637e06f9c0 | |||
| 332e0657e0 | |||
| 4017b250fb | |||
| 41373a7c6f | |||
| 7cc85ca6bc | |||
| bc19fa0cbd | |||
| a60f58e20b | |||
| aca902b5ff | |||
| 2f866c41b4 | |||
| 7e4faef95f | |||
| bcef84787d | |||
| 70a3ac0525 | |||
| c6fb101a99 | |||
| 2984af769c | |||
| 9183f668d3 | |||
| 54ea96391a | |||
| 42d24fd1a1 | |||
| dc36a8182c | |||
| 0ef85b47b1 | |||
| 058d9dd0ba | |||
| 74bb230247 | |||
| 7c1e0f34e8 | |||
| 7e31323faa | |||
| a28cdf437b | |||
| 80dfbeb16f | |||
| 9de3a32ceb | |||
| 0d3864548c | |||
| 9e03747e43 | |||
| 5750f2b477 | |||
| 901be70f97 | |||
| 7d0a9c6439 | |||
| 48b55758e3 | |||
| dcaccb65f2 | |||
| 723e1b4ea2 | |||
| 08a69c6168 | |||
| 948d9c24cf | |||
| ebbe922982 | |||
| 6520bbd5e3 | |||
| 4e197ac24c | |||
| f707e5fb10 | |||
| 6fc5e565d0 | |||
| 07c852744b | |||
| 4fab98c633 | |||
| 18ca0cf3d6 | |||
| b3e044e278 | |||
| e2a250063f | |||
| 4085151f80 | |||
| 0d3681e26a | |||
| cfe7b3a51f | |||
| 08d3d6a80a | |||
| 9d83bda12c | |||
| 22fd1b5be1 | |||
| df33fbf91b | |||
| ee6efc4cca | |||
| 6da15ab12b | |||
| 7ef2a8769b | |||
| 487f52e194 | |||
| 39b1c5bbec | |||
| 32857bbfeb | |||
| 41218e2585 | |||
| a1a2d0801b | |||
| c588c09b26 | |||
| 74382e21e7 | |||
| 8a7ec7e982 | |||
| 2948a33bf9 | |||
| 98b2da5018 | |||
| fc1f76b543 | |||
| 22c9fb777b | |||
| 2da051a7f9 | |||
| 390a317bd3 | |||
| c161553d1d | |||
| c960a48b4f | |||
| 9502f4361d | |||
| 82deab41f4 | |||
| 2245812f0b | |||
| 861e9c976b | |||
| f55808199b | |||
| b4a7f1887d | |||
| f73441ee85 | |||
| d7de3b08c1 | |||
| 7d201f05d9 | |||
| a21ee2cea6 | |||
| 4ad46b81c9 | |||
| 10b8e785e0 | |||
| 5fbed783fc | |||
| c9fe134852 | |||
| f2149719e3 | |||
| 161d40cde7 | |||
| 76028771b8 | |||
| 5df1a6602e | |||
| 3d7b28a92b | |||
| ed862413b1 | |||
| 9d02ab4a5e | |||
| 34c0868d77 | |||
| fae9c0ca24 | |||
| dd162205fa | |||
| a88ae1cc1e | |||
| 904948e2bc | |||
| 3b6b96f551 | |||
| 67e49c82a3 | |||
| 9f45fe62e4 | |||
| 9e8094e34c | |||
| 0e7e9e17c9 | |||
| b3ccb3d26f | |||
| b17370c153 | |||
| 0c53f5b061 | |||
| ed6157de80 |
@ -10,13 +10,7 @@
|
||||
"ghcr.io/devcontainers/features/node:1": {}
|
||||
},
|
||||
"onCreateCommand": "./.devcontainer/on-create.sh",
|
||||
"forwardPorts": [
|
||||
3000,
|
||||
54320,
|
||||
9000,
|
||||
2500,
|
||||
1100
|
||||
],
|
||||
"forwardPorts": [3000, 54320, 9000, 2500, 1100],
|
||||
"customizations": {
|
||||
"vscode": {
|
||||
"extensions": [
|
||||
@ -35,4 +29,4 @@
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
1
.github/actions/cache-build/action.yml
vendored
@ -13,7 +13,6 @@ runs:
|
||||
with:
|
||||
path: |
|
||||
${{ github.workspace }}/apps/web/.next
|
||||
${{ github.workspace }}/apps/marketing/.next
|
||||
**/.turbo/**
|
||||
**/dist/**
|
||||
|
||||
|
||||
10
.github/dependabot.yml
vendored
@ -11,16 +11,6 @@ updates:
|
||||
- 'ci'
|
||||
open-pull-requests-limit: 0
|
||||
|
||||
- package-ecosystem: 'npm'
|
||||
directory: '/apps/marketing'
|
||||
schedule:
|
||||
interval: 'weekly'
|
||||
target-branch: 'main'
|
||||
labels:
|
||||
- 'npm dependencies'
|
||||
- 'frontend'
|
||||
open-pull-requests-limit: 0
|
||||
|
||||
- package-ecosystem: 'npm'
|
||||
directory: '/apps/web'
|
||||
schedule:
|
||||
|
||||
3
.github/labeler.yml
vendored
@ -1,6 +1,3 @@
|
||||
'apps: marketing':
|
||||
- apps/marketing/**
|
||||
|
||||
'apps: web':
|
||||
- apps/web/**
|
||||
|
||||
|
||||
2
.github/workflows/codeql-analysis.yml
vendored
@ -10,7 +10,7 @@ on:
|
||||
jobs:
|
||||
analyze:
|
||||
name: Analyze
|
||||
runs-on: ubuntu-latest
|
||||
runs-on: ubuntu-22.04
|
||||
permissions:
|
||||
actions: read
|
||||
contents: read
|
||||
|
||||
2
.github/workflows/e2e-tests.yml
vendored
@ -8,7 +8,7 @@ jobs:
|
||||
e2e_tests:
|
||||
name: 'E2E Tests'
|
||||
timeout-minutes: 60
|
||||
runs-on: ubuntu-latest
|
||||
runs-on: warp-ubuntu-2204-x64-16x
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
|
||||
8
.github/workflows/publish.yml
vendored
@ -90,7 +90,7 @@ jobs:
|
||||
GIT_SHA="$(git rev-parse HEAD)"
|
||||
|
||||
# Check if the version is stable (no rc or beta in the version)
|
||||
if [[ "$APP_VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
|
||||
if [[ "$APP_VERSION" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
|
||||
docker manifest create \
|
||||
documenso/documenso:latest \
|
||||
--amend documenso/documenso-amd64:latest \
|
||||
@ -99,7 +99,7 @@ jobs:
|
||||
docker manifest push documenso/documenso:latest
|
||||
fi
|
||||
|
||||
if [[ "$APP_VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+-rc\.[0-9]+$ ]]; then
|
||||
if [[ "$APP_VERSION" =~ ^v[0-9]+\.[0-9]+\.[0-9]+-rc\.[0-9]+$ ]]; then
|
||||
docker manifest create \
|
||||
documenso/documenso:rc \
|
||||
--amend documenso/documenso-amd64:rc \
|
||||
@ -127,7 +127,7 @@ jobs:
|
||||
GIT_SHA="$(git rev-parse HEAD)"
|
||||
|
||||
# Check if the version is stable (no rc or beta in the version)
|
||||
if [[ "$APP_VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
|
||||
if [[ "$APP_VERSION" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
|
||||
docker manifest create \
|
||||
ghcr.io/documenso/documenso:latest \
|
||||
--amend ghcr.io/documenso/documenso-amd64:latest \
|
||||
@ -136,7 +136,7 @@ jobs:
|
||||
docker manifest push ghcr.io/documenso/documenso:latest
|
||||
fi
|
||||
|
||||
if [[ "$APP_VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+-rc\.[0-9]+$ ]]; then
|
||||
if [[ "$APP_VERSION" =~ ^v[0-9]+\.[0-9]+\.[0-9]+-rc\.[0-9]+$ ]]; then
|
||||
docker manifest create \
|
||||
ghcr.io/documenso/documenso:rc \
|
||||
--amend ghcr.io/documenso/documenso-amd64:rc \
|
||||
|
||||
@ -11,6 +11,5 @@ echo "Copying .well-known/ contents"
|
||||
node "$MONOREPO_ROOT/scripts/copy-wellknown.cjs"
|
||||
|
||||
git add "$MONOREPO_ROOT/apps/web/public/"
|
||||
git add "$MONOREPO_ROOT/apps/marketing/public/"
|
||||
|
||||
npx lint-staged
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
> 🚨 We are live on Product Hunt 🎉 Check out our latest launch: <a href="https://documen.so/sign-everywhere">The Platform Plan</a>!
|
||||
|
||||
<a href="https://www.producthunt.com/posts/documenso-platform-plan?embed=true&utm_source=badge-featured&utm_medium=badge&utm_souce=badge-documenso-platform-plan" target="_blank"><img src="https://api.producthunt.com/widgets/embed-image/v1/featured.svg?post_id=670576&theme=light" alt="Documenso Platform Plan - Whitelabeled signing flows in your product | Product Hunt" style="width: 250px; height: 54px;" width="250" height="54" /></a>
|
||||
|
||||
<img src="https://github.com/documenso/documenso/assets/13398220/a643571f-0239-46a6-a73e-6bef38d1228b" alt="Documenso Logo">
|
||||
|
||||
<p align="center" style="margin-top: 20px">
|
||||
|
||||
@ -1,36 +1 @@
|
||||
This is a [Next.js](https://nextjs.org/) project bootstrapped with [`create-next-app`](https://github.com/vercel/next.js/tree/canary/packages/create-next-app).
|
||||
|
||||
## Getting Started
|
||||
|
||||
First, run the development server:
|
||||
|
||||
```bash
|
||||
npm run dev
|
||||
# or
|
||||
yarn dev
|
||||
# or
|
||||
pnpm dev
|
||||
# or
|
||||
bun dev
|
||||
```
|
||||
|
||||
Open [http://localhost:3002](http://localhost:3002) with your browser to see the result.
|
||||
|
||||
You can start editing the page by modifying `app/page.tsx`. The page auto-updates as you edit the file.
|
||||
|
||||
This project uses [`next/font`](https://nextjs.org/docs/basic-features/font-optimization) to automatically optimize and load Inter, a custom Google Font.
|
||||
|
||||
## Learn More
|
||||
|
||||
To learn more about Next.js, take a look at the following resources:
|
||||
|
||||
- [Next.js Documentation](https://nextjs.org/docs) - learn about Next.js features and API.
|
||||
- [Learn Next.js](https://nextjs.org/learn) - an interactive Next.js tutorial.
|
||||
|
||||
You can check out [the Next.js GitHub repository](https://github.com/vercel/next.js/) - your feedback and contributions are welcome!
|
||||
|
||||
## Deploy on Vercel
|
||||
|
||||
The easiest way to deploy your Next.js app is to use the [Vercel Platform](https://vercel.com/new?utm_medium=default-template&filter=next.js&utm_source=create-next-app&utm_campaign=create-next-app-readme) from the creators of Next.js.
|
||||
|
||||
Check out our [Next.js deployment documentation](https://nextjs.org/docs/deployment) for more details.
|
||||
# @documenso/documentation
|
||||
|
||||
@ -27,6 +27,6 @@
|
||||
"@types/node": "^20",
|
||||
"@types/react": "^18",
|
||||
"@types/react-dom": "^18",
|
||||
"typescript": "^5"
|
||||
"typescript": "5.6.2"
|
||||
}
|
||||
}
|
||||
@ -4,7 +4,7 @@ import '../styles.css';
|
||||
export default function App({ Component, pageProps }) {
|
||||
return (
|
||||
<PlausibleProvider>
|
||||
<Component {...pageProps} />;
|
||||
<Component {...pageProps} />
|
||||
</PlausibleProvider>
|
||||
);
|
||||
}
|
||||
|
||||
@ -14,4 +14,4 @@
|
||||
"public-api": "Public API",
|
||||
"embedding": "Embedding",
|
||||
"webhooks": "Webhooks"
|
||||
}
|
||||
}
|
||||
|
||||
@ -20,11 +20,7 @@ If you are looking for development notes on translations, you can find them [her
|
||||
|
||||
We store our translations in PO files, which are located in our GitHub repository [here](https://github.com/documenso/documenso/tree/main/packages/lib/translations).
|
||||
|
||||
The translation files are organized into folders represented by their respective language codes (`en` for English, `de` for German, etc). Each language folder contains three PO files:
|
||||
|
||||
1. `web.po`: Translations for the web application
|
||||
2. `marketing.po`: Translations for the marketing application
|
||||
3. `common.po`: Shared translations between web and marketing
|
||||
The translation files are organized into folders represented by their respective language codes (`en` for English, `de` for German, etc).
|
||||
|
||||
Each PO file contains translations which look like this:
|
||||
|
||||
@ -46,11 +42,10 @@ msgstr "Möchten Sie auffällige Signatur-Links wie diesen senden? <0>Überprüf
|
||||
### Updating Existing Translations
|
||||
|
||||
1. Fork the repository.
|
||||
2. Navigate to the appropriate language folder.
|
||||
3. Open the PO file you want to update (web.po, marketing.po, or common.po).
|
||||
4. Make your changes, ensuring you follow the PO file format.
|
||||
5. Commit your changes with a message such as `chore: update German translations`
|
||||
6. Create a Pull Request.
|
||||
2. Navigate to the appropriate language folder and open the PO file you want to update.
|
||||
3. Make your changes, ensuring you follow the PO file format.
|
||||
4. Commit your changes with a message such as `chore: update German translations`
|
||||
5. Create a Pull Request.
|
||||
|
||||
### Adding a New Language
|
||||
|
||||
|
||||
@ -5,5 +5,7 @@
|
||||
"svelte": "Svelte Integration",
|
||||
"solid": "Solid Integration",
|
||||
"preact": "Preact Integration",
|
||||
"css-variables": "CSS Variables"
|
||||
}
|
||||
"angular": "Angular Integration",
|
||||
"css-variables": "CSS Variables",
|
||||
"web-components": "Web Components"
|
||||
}
|
||||
|
||||
90
apps/documentation/pages/developers/embedding/angular.mdx
Normal file
@ -0,0 +1,90 @@
|
||||
---
|
||||
title: Angular Integration
|
||||
description: Learn how to use our embedding SDK within your Angular application.
|
||||
---
|
||||
|
||||
# Angular Integration
|
||||
|
||||
Our Angular SDK provides a simple way to embed a signing experience within your Angular application. It supports both direct link templates and signing tokens.
|
||||
|
||||
## Installation
|
||||
|
||||
To install the SDK, run the following command:
|
||||
|
||||
```bash
|
||||
npm install @documenso/embed-angular
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
To embed a signing experience, you'll need to provide the token for the document you want to embed. This can be done in a few different ways, depending on your use case.
|
||||
|
||||
### Direct Link Template
|
||||
|
||||
If you have a direct link template, you can simply provide the token for the template to the `EmbedDirectTemplate` component.
|
||||
|
||||
```typescript
|
||||
import { Component } from '@angular/core';
|
||||
import { EmbedDirectTemplate } from '@documenso/embed-angular';
|
||||
|
||||
@Component({
|
||||
selector: 'app-embedding',
|
||||
template: `
|
||||
<embed-direct-template [token]="token" />
|
||||
`,
|
||||
standalone: true,
|
||||
imports: [EmbedDirectTemplate],
|
||||
})
|
||||
export class EmbeddingComponent {
|
||||
token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
|
||||
}
|
||||
```
|
||||
|
||||
#### Props
|
||||
|
||||
| Prop | Type | Description |
|
||||
| ------------------- | ------------------- | ------------------------------------------------------------------------------------------ |
|
||||
| token | string | The token for the document you want to embed |
|
||||
| host | string (optional) | The host to be used for the signing experience, relevant for self-hosters |
|
||||
| name | string (optional) | The name the signer that will be used by default for signing |
|
||||
| lockName | boolean (optional) | Whether or not the name field should be locked disallowing modifications |
|
||||
| email | string (optional) | The email the signer that will be used by default for signing |
|
||||
| lockEmail | boolean (optional) | Whether or not the email field should be locked disallowing modifications |
|
||||
| onDocumentReady | function (optional) | A callback function that will be called when the document is loaded and ready to be signed |
|
||||
| onDocumentCompleted | function (optional) | A callback function that will be called when the document has been completed |
|
||||
| onDocumentError | function (optional) | A callback function that will be called when an error occurs with the document |
|
||||
| onFieldSigned | function (optional) | A callback function that will be called when a field is signed |
|
||||
| onFieldUnsigned | function (optional) | A callback function that will be called when a field is unsigned |
|
||||
|
||||
### Signing Token
|
||||
|
||||
If you have a signing token, you can provide it to the `EmbedSignDocument` component.
|
||||
|
||||
```typescript
|
||||
import { Component } from '@angular/core';
|
||||
import { EmbedSignDocument } from '@documenso/embed-angular';
|
||||
|
||||
@Component({
|
||||
selector: 'app-embedding',
|
||||
template: `
|
||||
<embed-sign-document [token]="token" />
|
||||
`,
|
||||
standalone: true,
|
||||
imports: [EmbedSignDocument],
|
||||
})
|
||||
export class EmbeddingComponent {
|
||||
token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
|
||||
}
|
||||
```
|
||||
|
||||
#### Props
|
||||
|
||||
| Prop | Type | Description |
|
||||
| ------------------- | ------------------- | ------------------------------------------------------------------------------------------ |
|
||||
| token | string | The token for the document you want to embed |
|
||||
| host | string (optional) | The host to be used for the signing experience, relevant for self-hosters |
|
||||
| name | string (optional) | The name the signer that will be used by default for signing |
|
||||
| lockName | boolean (optional) | Whether or not the name field should be locked disallowing modifications |
|
||||
| onDocumentReady | function (optional) | A callback function that will be called when the document is loaded and ready to be signed |
|
||||
| onDocumentCompleted | function (optional) | A callback function that will be called when the document has been completed |
|
||||
| onDocumentError | function (optional) | A callback function that will be called when an error occurs with the document |
|
||||
@ -111,6 +111,83 @@ The colors will be automatically converted to the appropriate format internally.
|
||||
|
||||
4. **Consistent Radius**: Use a consistent border radius value that matches your application's design system.
|
||||
|
||||
## CSS Class Targets
|
||||
|
||||
In addition to CSS variables, specific components in the embedded experience can be targeted using CSS classes for more granular styling:
|
||||
|
||||
### Component Classes
|
||||
|
||||
| Class Name | Description |
|
||||
| --------------------------------- | ----------------------------------------------------------------------- |
|
||||
| `.embed--Root` | Main container for the embedded signing experience |
|
||||
| `.embed--DocumentContainer` | Container for the document and signing widget |
|
||||
| `.embed--DocumentViewer` | Container for the document viewer |
|
||||
| `.embed--DocumentWidget` | The signing widget container |
|
||||
| `.embed--DocumentWidgetContainer` | Outer container for the signing widget, handles positioning |
|
||||
| `.embed--DocumentWidgetHeader` | Header section of the signing widget |
|
||||
| `.embed--DocumentWidgetContent` | Main content area of the signing widget |
|
||||
| `.embed--DocumentWidgetForm` | Form section within the signing widget |
|
||||
| `.embed--DocumentWidgetFooter` | Footer section of the signing widget |
|
||||
| `.embed--WaitingForTurn` | Container for the waiting screen when it's not the user's turn to sign |
|
||||
| `.embed--DocumentCompleted` | Container for the completion screen after signing |
|
||||
| `.field--FieldRootContainer` | Base container for document fields (signatures, text, checkboxes, etc.) |
|
||||
|
||||
Field components also expose several data attributes that can be used for styling different states:
|
||||
|
||||
| Data Attribute | Values | Description |
|
||||
| ------------------- | ---------------------------------------------- | ------------------------------------ |
|
||||
| `[data-field-type]` | `SIGNATURE`, `TEXT`, `CHECKBOX`, `RADIO`, etc. | The type of field |
|
||||
| `[data-inserted]` | `true`, `false` | Whether the field has been filled |
|
||||
| `[data-validate]` | `true`, `false` | Whether the field is being validated |
|
||||
|
||||
### Field Styling Example
|
||||
|
||||
```css
|
||||
/* Style all field containers */
|
||||
.field--FieldRootContainer {
|
||||
transition: all 200ms ease;
|
||||
}
|
||||
|
||||
/* Style specific field types */
|
||||
.field--FieldRootContainer[data-field-type='SIGNATURE'] {
|
||||
background-color: rgba(0, 0, 0, 0.02);
|
||||
}
|
||||
|
||||
/* Style inserted fields */
|
||||
.field--FieldRootContainer[data-inserted='true'] {
|
||||
background-color: var(--primary);
|
||||
opacity: 0.2;
|
||||
}
|
||||
|
||||
/* Style fields being validated */
|
||||
.field--FieldRootContainer[data-validate='true'] {
|
||||
border-color: orange;
|
||||
}
|
||||
```
|
||||
|
||||
### Example Usage
|
||||
|
||||
```css
|
||||
/* Custom styles for the document widget */
|
||||
.embed--DocumentWidget {
|
||||
background-color: #ffffff;
|
||||
box-shadow: 0 4px 6px -1px rgb(0 0 0 / 0.1);
|
||||
}
|
||||
|
||||
/* Custom styles for the waiting screen */
|
||||
.embed--WaitingForTurn {
|
||||
background-color: #f9fafb;
|
||||
padding: 2rem;
|
||||
}
|
||||
|
||||
/* Responsive adjustments for the document container */
|
||||
@media (min-width: 768px) {
|
||||
.embed--DocumentContainer {
|
||||
gap: 2rem;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Related
|
||||
|
||||
- [React Integration](/developers/embedding/react)
|
||||
|
||||
@ -5,7 +5,7 @@ description: Learn how to use embedding to bring signing to your own website or
|
||||
|
||||
# Embedding
|
||||
|
||||
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, or using generalized web components, this guide will help you get started with embedding Documenso.
|
||||
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.
|
||||
|
||||
## Availability
|
||||
|
||||
@ -52,9 +52,9 @@ Platform customers have access to advanced styling options to customize the embe
|
||||
<EmbedDirectTemplate
|
||||
token={token}
|
||||
cssVars={{
|
||||
colorPrimary: '#0000FF',
|
||||
colorBackground: '#F5F5F5',
|
||||
borderRadius: '8px',
|
||||
primary: '#0000FF',
|
||||
background: '#F5F5F5',
|
||||
radius: '8px',
|
||||
}}
|
||||
/>
|
||||
```
|
||||
@ -73,13 +73,15 @@ These customization options are available for both Direct Templates and Signing
|
||||
|
||||
We support embedding across a range of popular JavaScript frameworks, including:
|
||||
|
||||
| Framework | Package |
|
||||
| --------- | -------------------------------------------------------------------------------- |
|
||||
| React | [@documenso/embed-react](https://www.npmjs.com/package/@documenso/embed-react) |
|
||||
| Preact | [@documenso/embed-preact](https://www.npmjs.com/package/@documenso/embed-preact) |
|
||||
| Vue | [@documenso/embed-vue](https://www.npmjs.com/package/@documenso/embed-vue) |
|
||||
| Svelte | [@documenso/embed-svelte](https://www.npmjs.com/package/@documenso/embed-svelte) |
|
||||
| Solid | [@documenso/embed-solid](https://www.npmjs.com/package/@documenso/embed-solid) |
|
||||
| Framework | Package |
|
||||
| --------- | ---------------------------------------------------------------------------------- |
|
||||
| React | [@documenso/embed-react](https://www.npmjs.com/package/@documenso/embed-react) |
|
||||
| Preact | [@documenso/embed-preact](https://www.npmjs.com/package/@documenso/embed-preact) |
|
||||
| Vue | [@documenso/embed-vue](https://www.npmjs.com/package/@documenso/embed-vue) |
|
||||
| Svelte | [@documenso/embed-svelte](https://www.npmjs.com/package/@documenso/embed-svelte) |
|
||||
| Solid | [@documenso/embed-solid](https://www.npmjs.com/package/@documenso/embed-solid) |
|
||||
| Angular | [@documenso/embed-angular](https://www.npmjs.com/package/@documenso/embed-angular) |
|
||||
| Web Components | [@documenso/embed-webcomponent](https://www.npmjs.com/package/@documenso/embed-webcomponent) |
|
||||
|
||||
Additionally, we provide **web components** for more generalized use. However, please note that web components are still in their early stages and haven't been extensively tested.
|
||||
|
||||
@ -127,7 +129,7 @@ This will show a dialog which will ask you to configure which recipient should b
|
||||
|
||||
## Embedding with Signing Tokens
|
||||
|
||||
To embed the signing process for an ordinary document, you’ll need a **document signing token** for the recipient. This token provides the necessary access to load the document and facilitate the signing process securely.
|
||||
To embed the signing process for an ordinary document, you'll need a **document signing token** for the recipient. This token provides the necessary access to load the document and facilitate the signing process securely.
|
||||
|
||||
#### Instructions
|
||||
|
||||
@ -164,6 +166,8 @@ Once you've obtained the appropriate tokens, you can integrate the signing exper
|
||||
- [Vue](/developers/embedding/vue)
|
||||
- [Svelte](/developers/embedding/svelte)
|
||||
- [Solid](/developers/embedding/solid)
|
||||
- [Angular](/developers/embedding/angular)
|
||||
- [Web Components](/developers/embedding/web-components)
|
||||
|
||||
If you're using **web components**, the integration process is slightly different. Keep in mind that web components are currently less tested but can still provide flexibility for general use cases.
|
||||
|
||||
@ -174,4 +178,6 @@ If you're using **web components**, the integration process is slightly differen
|
||||
- [Svelte Integration](/developers/embedding/svelte)
|
||||
- [Solid Integration](/developers/embedding/solid)
|
||||
- [Preact Integration](/developers/embedding/preact)
|
||||
- [Angular Integration](/developers/embedding/angular)
|
||||
- [Web Components](/developers/embedding/web-components)
|
||||
- [CSS Variables](/developers/embedding/css-variables)
|
||||
|
||||
@ -95,9 +95,9 @@ const MyEmbeddingComponent = () => {
|
||||
}
|
||||
`;
|
||||
const cssVars = {
|
||||
colorPrimary: '#0000FF',
|
||||
colorBackground: '#F5F5F5',
|
||||
borderRadius: '8px',
|
||||
primary: '#0000FF',
|
||||
background: '#F5F5F5',
|
||||
radius: '8px',
|
||||
};
|
||||
|
||||
return (
|
||||
|
||||
@ -99,9 +99,9 @@ const MyEmbeddingComponent = () => {
|
||||
`}
|
||||
// CSS Variables
|
||||
cssVars={{
|
||||
colorPrimary: '#0000FF',
|
||||
colorBackground: '#F5F5F5',
|
||||
borderRadius: '8px',
|
||||
primary: '#0000FF',
|
||||
background: '#F5F5F5',
|
||||
radius: '8px',
|
||||
}}
|
||||
// Dark Mode Control
|
||||
darkModeDisabled={true}
|
||||
|
||||
@ -95,9 +95,9 @@ const MyEmbeddingComponent = () => {
|
||||
}
|
||||
`;
|
||||
const cssVars = {
|
||||
colorPrimary: '#0000FF',
|
||||
colorBackground: '#F5F5F5',
|
||||
borderRadius: '8px',
|
||||
primary: '#0000FF',
|
||||
background: '#F5F5F5',
|
||||
radius: '8px',
|
||||
};
|
||||
|
||||
return (
|
||||
|
||||
@ -97,9 +97,9 @@ Platform customers have access to advanced styling options:
|
||||
}
|
||||
`;
|
||||
const cssVars = {
|
||||
colorPrimary: '#0000FF',
|
||||
colorBackground: '#F5F5F5',
|
||||
borderRadius: '8px',
|
||||
primary: '#0000FF',
|
||||
background: '#F5F5F5',
|
||||
radius: '8px',
|
||||
};
|
||||
</script>
|
||||
|
||||
|
||||
@ -97,9 +97,9 @@ Platform customers have access to advanced styling options:
|
||||
}
|
||||
`;
|
||||
const cssVars = {
|
||||
colorPrimary: '#0000FF',
|
||||
colorBackground: '#F5F5F5',
|
||||
borderRadius: '8px',
|
||||
primary: '#0000FF',
|
||||
background: '#F5F5F5',
|
||||
radius: '8px',
|
||||
};
|
||||
</script>
|
||||
|
||||
|
||||
@ -0,0 +1,89 @@
|
||||
---
|
||||
title: Web Components Integration
|
||||
description: Learn how to use our embedding SDK via Web Components on a framework-less web application.
|
||||
---
|
||||
|
||||
# Web Components Integration
|
||||
|
||||
Our Web Components SDK provides a simple way to embed a signing experience within your framework-less web application. It supports both direct link templates and signing tokens.
|
||||
|
||||
## Installation
|
||||
|
||||
To install the SDK, run the following command:
|
||||
|
||||
```bash
|
||||
npm install @documenso/embed-webcomponent
|
||||
```
|
||||
|
||||
Then in your html file, add the following to add the script, replacing the path with the proper path to the web component script.
|
||||
|
||||
```html
|
||||
<script src="YOUR_PATH_HERE"></script>
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
To embed a signing experience, you'll need to provide the token for the document you want to embed. This can be done in a few different ways, depending on your use case.
|
||||
|
||||
### Direct Link Template
|
||||
|
||||
If you have a direct link template, you can simply provide the token for the template to the `documenso-embed-direct-template` tag.
|
||||
|
||||
```html
|
||||
<documenso-embed-direct-template
|
||||
token="YOUR_TOKEN_HERE"
|
||||
</documenso-embed-direct-template>
|
||||
```
|
||||
|
||||
#### Attributes
|
||||
|
||||
| Attribute | Type | Description |
|
||||
| ------------------- | ------------------- | ------------------------------------------------------------------------------------------ |
|
||||
| token | string | The token for the document you want to embed |
|
||||
| host | string (optional) | The host to be used for the signing experience, relevant for self-hosters |
|
||||
| name | string (optional) | The name the signer that will be used by default for signing |
|
||||
| lockName | boolean (optional) | Whether or not the name field should be locked disallowing modifications |
|
||||
| email | string (optional) | The email the signer that will be used by default for signing |
|
||||
| lockEmail | boolean (optional) | Whether or not the email field should be locked disallowing modifications |
|
||||
| onDocumentReady | function (optional) | A callback function that will be called when the document is loaded and ready to be signed |
|
||||
| onDocumentCompleted | function (optional) | A callback function that will be called when the document has been completed |
|
||||
| onDocumentError | function (optional) | A callback function that will be called when an error occurs with the document |
|
||||
| onFieldSigned | function (optional) | A callback function that will be called when a field is signed |
|
||||
| onFieldUnsigned | function (optional) | A callback function that will be called when a field is unsigned |
|
||||
|
||||
### Signing Token
|
||||
|
||||
If you have a signing token, you can provide it to the `documenso-embed-sign-document` tag.
|
||||
|
||||
```html
|
||||
<documenso-embed-sign-document
|
||||
token="YOUR_TOKEN_HERE"
|
||||
</documenso-embed-sign-document>
|
||||
```
|
||||
|
||||
#### Attributes
|
||||
|
||||
| Attribute | Type | Description |
|
||||
| ------------------- | ------------------- | ------------------------------------------------------------------------------------------ |
|
||||
| token | string | The token for the document you want to embed |
|
||||
| host | string (optional) | The host to be used for the signing experience, relevant for self-hosters |
|
||||
| name | string (optional) | The name the signer that will be used by default for signing |
|
||||
| lockName | boolean (optional) | Whether or not the name field should be locked disallowing modifications |
|
||||
| onDocumentReady | function (optional) | A callback function that will be called when the document is loaded and ready to be signed |
|
||||
| onDocumentCompleted | function (optional) | A callback function that will be called when the document has been completed |
|
||||
| onDocumentError | function (optional) | A callback function that will be called when an error occurs with the document |
|
||||
|
||||
### Creating via JavaScript
|
||||
|
||||
You can also create the tag element using javascript, for dynamic generation of either modes. For example, this would add the sign document embed to the DOM.
|
||||
|
||||
```javascript
|
||||
document.getElementById('my-wrapper-here').innerHTML = '';
|
||||
|
||||
const tag = document.createElement('documenso-embed-sign-document');
|
||||
tag.setAttribute('token', data.token);
|
||||
tag.style.width = '100%';
|
||||
tag.style.height = '100%';
|
||||
|
||||
document.getElementById('my-wrapper-here').appendChild(tag);
|
||||
```
|
||||
@ -3,6 +3,8 @@ title: Public API
|
||||
description: Learn how to interact with your documents programmatically using the Documenso public API.
|
||||
---
|
||||
|
||||
import { Callout, Steps } from 'nextra/components';
|
||||
|
||||
# Public API
|
||||
|
||||
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:
|
||||
@ -13,10 +15,35 @@ Documenso provides a public REST API enabling you to interact with your document
|
||||
|
||||
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.
|
||||
|
||||
## Swagger Documentation
|
||||
## API V1 - Stable
|
||||
|
||||
The [Swagger documentation](https://app.documenso.com/api/v1/openapi) also provides information about the API endpoints, request parameters, response formats, and authentication methods.
|
||||
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>
|
||||
|
||||
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.
|
||||
|
||||
Our new API V2 supports the following typed SDKs:
|
||||
|
||||
- [TypeScript](https://github.com/documenso/sdk-typescript)
|
||||
- [Python](https://github.com/documenso/sdk-python)
|
||||
- [Go](https://github.com/documenso/sdk-go)
|
||||
|
||||
<Callout type="info">
|
||||
For the staging API, please use the following base URL:
|
||||
`https://stg-app.documenso.dev/api/v2-beta/`
|
||||
</Callout>
|
||||
|
||||
🚀 [V2 Announcement](https://documen.so/sdk-blog)
|
||||
|
||||
📖 [Documentation](https://documen.so/api-v2-docs)
|
||||
|
||||
💬 [Leave Feedback](https://documen.so/sdk-feedback)
|
||||
|
||||
🔔 [Breaking Changes](https://documen.so/sdk-breaking)
|
||||
|
||||
## Availability
|
||||
|
||||
The API is available to individual users and teams.
|
||||
The API is available to individual users, teams and higher plans. [Fair Use](https://documen.so/fair) applies.
|
||||
|
||||
@ -532,3 +532,93 @@ Replace the `text` value with the corresponding field type:
|
||||
- For the `SELECT` field it should be `select`. (check this before merge)
|
||||
|
||||
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.
|
||||
|
||||
## 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,
|
||||
"type": "text",
|
||||
"label": "my-label",
|
||||
"placeholder": "my-placeholder",
|
||||
"value": "my-value"
|
||||
},
|
||||
{
|
||||
"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"]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Check out the endpoint in the [API V1 documentation](https://app.documenso.com/api/v1/openapi#:~:text=/%7BtemplateId%7D/-,generate,-%2Ddocument).
|
||||
|
||||
### API V2
|
||||
|
||||
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:
|
||||
|
||||
```json
|
||||
{
|
||||
"templateId": 111,
|
||||
"recipients": [
|
||||
{
|
||||
"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"
|
||||
},
|
||||
{
|
||||
"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"]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Check out the endpoint in the [API V2 documentation](https://openapi.documenso.com/reference#tag/template/POST/template/use).
|
||||
|
||||
@ -21,6 +21,7 @@ Documenso supports Webhooks and allows you to subscribe to the following events:
|
||||
- `document.signed`
|
||||
- `document.completed`
|
||||
- `document.rejected`
|
||||
- `document.cancelled`
|
||||
|
||||
## Create a webhook subscription
|
||||
|
||||
@ -37,7 +38,7 @@ Clicking on the "**Create Webhook**" button opens a modal to create a new webhoo
|
||||
To create a new webhook subscription, you need to provide the following information:
|
||||
|
||||
- Enter the webhook URL that will receive the event payload.
|
||||
- Select the event(s) you want to subscribe to: `document.created`, `document.sent`, `document.opened`, `document.signed`, `document.completed`, `document.rejected`.
|
||||
- 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.
|
||||
|
||||

|
||||
@ -528,6 +529,96 @@ Example payload for the `document.rejected` event:
|
||||
}
|
||||
```
|
||||
|
||||
Example payload for the `document.rejected` event:
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "DOCUMENT_CANCELLED",
|
||||
"payload": {
|
||||
"id": 7,
|
||||
"externalId": null,
|
||||
"userId": 3,
|
||||
"authOptions": null,
|
||||
"formValues": null,
|
||||
"visibility": "EVERYONE",
|
||||
"title": "documenso.pdf",
|
||||
"status": "PENDING",
|
||||
"documentDataId": "cm6exvn93006hi02ru90a265a",
|
||||
"createdAt": "2025-01-27T11:02:14.393Z",
|
||||
"updatedAt": "2025-01-27T11:03:16.387Z",
|
||||
"completedAt": null,
|
||||
"deletedAt": null,
|
||||
"teamId": null,
|
||||
"templateId": null,
|
||||
"source": "DOCUMENT",
|
||||
"documentMeta": {
|
||||
"id": "cm6exvn96006ji02rqvzjvwoy",
|
||||
"subject": "",
|
||||
"message": "",
|
||||
"timezone": "Etc/UTC",
|
||||
"password": null,
|
||||
"dateFormat": "yyyy-MM-dd hh:mm a",
|
||||
"redirectUrl": "",
|
||||
"signingOrder": "PARALLEL",
|
||||
"typedSignatureEnabled": true,
|
||||
"language": "en",
|
||||
"distributionMethod": "EMAIL",
|
||||
"emailSettings": {
|
||||
"documentDeleted": true,
|
||||
"documentPending": true,
|
||||
"recipientSigned": true,
|
||||
"recipientRemoved": true,
|
||||
"documentCompleted": true,
|
||||
"ownerDocumentCompleted": true,
|
||||
"recipientSigningRequest": true
|
||||
}
|
||||
},
|
||||
"recipients": [
|
||||
{
|
||||
"id": 7,
|
||||
"documentId": 7,
|
||||
"templateId": null,
|
||||
"email": "mybirihix@mailinator.com",
|
||||
"name": "Zorita Baird",
|
||||
"token": "XkKx1HCs6Znm2UBJA2j6o",
|
||||
"documentDeletedAt": null,
|
||||
"expired": null,
|
||||
"signedAt": null,
|
||||
"authOptions": { "accessAuth": null, "actionAuth": null },
|
||||
"signingOrder": 1,
|
||||
"rejectionReason": null,
|
||||
"role": "SIGNER",
|
||||
"readStatus": "NOT_OPENED",
|
||||
"signingStatus": "NOT_SIGNED",
|
||||
"sendStatus": "SENT"
|
||||
}
|
||||
],
|
||||
"Recipient": [
|
||||
{
|
||||
"id": 7,
|
||||
"documentId": 7,
|
||||
"templateId": null,
|
||||
"email": "signer@documenso.com",
|
||||
"name": "Signer",
|
||||
"token": "XkKx1HCs6Znm2UBJA2j6o",
|
||||
"documentDeletedAt": null,
|
||||
"expired": null,
|
||||
"signedAt": null,
|
||||
"authOptions": { "accessAuth": null, "actionAuth": null },
|
||||
"signingOrder": 1,
|
||||
"rejectionReason": null,
|
||||
"role": "SIGNER",
|
||||
"readStatus": "NOT_OPENED",
|
||||
"signingStatus": "NOT_SIGNED",
|
||||
"sendStatus": "SENT"
|
||||
}
|
||||
]
|
||||
},
|
||||
"createdAt": "2025-01-27T11:03:27.730Z",
|
||||
"webhookEndpoint": "https://mywebhooksite.com/mywebhook"
|
||||
}
|
||||
```
|
||||
|
||||
## Availability
|
||||
|
||||
Webhooks are available to individual users and teams.
|
||||
|
||||
@ -85,12 +85,13 @@ You can also set the recipient's role, which determines their actions and permis
|
||||
|
||||
Documenso has 4 roles for recipients with different permissions and actions.
|
||||
|
||||
| Role | Function | Action required | Signature |
|
||||
| :------: | :-----------------------------------------------------------------------------: | :-------------: | :-------: |
|
||||
| Signer | Needs to sign signatures 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 |
|
||||
| BCC | Receives a copy of the signed document after completion. No action is required. | No | No |
|
||||
| Role | Function | Action required | Signature |
|
||||
| :-------: | :-----------------------------------------------------------------------------: | :-------------: | :-------: |
|
||||
| Signer | Needs to sign signatures 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 |
|
||||
| CC | Receives a copy of the signed document after completion. No action is required. | No | No |
|
||||
|
||||
### Fields
|
||||
|
||||
|
||||
@ -17,23 +17,25 @@ The default document visibility option allows you to control who can view and ac
|
||||
|
||||
The default document visibility is set to "_EVERYONE_" by default. You can change this setting by going to the [team's general preferences page](/users/teams/preferences) and selecting a different visibility option.
|
||||
|
||||
<Callout type="warning">
|
||||
If the team member uploading the document has a role lower than the default document visibility,
|
||||
the document visibility will be set to a lower visibility level matching the team member's role.
|
||||
</Callout>
|
||||
|
||||
Here's how it works:
|
||||
|
||||
- If a user with the "_Member_" role creates a document and the default document visibility is set to "_Admin_" or "_Managers and above_", the document's visibility is set to "_Everyone_".
|
||||
- If a user with the "_Manager_" role creates a document and the default document visibility is set to "_Admin_", the document's visibility is set to "_Managers and above_".
|
||||
- Otherwise, the document's visibility is set to the default document visibility.
|
||||
- If a user with the "_Member_" role creates a document and the default document visibility is set to "_Everyone_", the document's visibility is set to "_EVERYONE_".
|
||||
- The user can't change the visibility of the document in the document editor.
|
||||
- If a user with the "_Member_" role creates a document and the default document visibility is set to "_Admin_" or "_Managers and above_", the document's visibility is set to the default document visibility ("_Admin_" or "_Managers and above_" in this case).
|
||||
- The user can't change the visibility of the document in the document editor.
|
||||
- If a user with the "_Manager_" role creates a document and the default document visibility is set to "_Everyone_" or "_Managers and above_", the document's visibility is set to the default document visibility ("_Everyone_" or "_Managers and above_" in this case).
|
||||
- The user can change the visibility of the document to any of these options, except "_Admin_", in the document editor.
|
||||
- If a user with the "_Manager_" role creates a document and the default document visibility is set to "_Admin_", the document's visibility is set to "_Admin_".
|
||||
- The user can't change the visibility of the document in the document editor.
|
||||
- If a user with the "_Admin_" role creates a document, and the default document visibility is set to "_Everyone_", "_Managers and above_", or "_Admin_", the document's visibility is set to the default document visibility.
|
||||
- The user can change the visibility of the document to any of these options in the document editor.
|
||||
|
||||
You can change the visibility of a document at any time by editing the document and selecting a different visibility option.
|
||||
|
||||

|
||||
|
||||
<Callout type="warning">
|
||||
Updating the default document visibility in the team's general settings will not affect the
|
||||
Updating the default document visibility in the team's general preferences will not affect the
|
||||
visibility of existing documents. You will need to update the visibility of each document
|
||||
individually.
|
||||
</Callout>
|
||||
|
||||
@ -1 +0,0 @@
|
||||
# @documenso/marketing
|
||||
1
apps/marketing/ambient.d.ts
vendored
@ -1 +0,0 @@
|
||||
declare module '@documenso/tailwind-config';
|
||||
@ -1,63 +0,0 @@
|
||||
---
|
||||
title: Launching Direct Links
|
||||
description: Today, we are launching direct links to templates, a new and async way to get documents signed.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-06-17
|
||||
tags:
|
||||
- Announcement
|
||||
- Direct Links
|
||||
- Profiles
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/direct-links.png"
|
||||
width="1400"
|
||||
height="884"
|
||||
alt="Direct Links in Templats List View"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">Direct Template Links - Async signing, anytime.</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; We are launching direct links to templates. With direct links, a document is created from a template every time anyone signs the link. Links can be public.
|
||||
|
||||
## Sync or Async?
|
||||
|
||||
> Quick refresher on Sync vs. Async: Sync means everyone has to wait for me until they can continue their work. Async means everyone can and does their work at the time that fits best.
|
||||
|
||||
Digital signing has become almost as normalized as email when doing business. While not 100% of companies are onboarded on digital signatures yet, hardly anyone is surprised when receiving a link to sign something digitally. As we got used to the user experience of sending emails, we also got used to the experience of sending document signature requests, with all the downsides:
|
||||
|
||||
- I have to become active each time before anything can happen: I need to send a signature request
|
||||
- My counterpart has to wait for me to send: "Did you send the signing link yet?"
|
||||
- I need to monitor the requests I started for completion: "I sent you a link yesterday; please check it out."
|
||||
|
||||
## Introducing Direct Links
|
||||
|
||||
Today, we are introducing a new paradigm to signing: Async Direct Signing Links. Direct links are attached to a template and can be used anytime by anyone using the link. You set up the signature experience and flow once using all existing template mechanisms and you are done. You can provide anyone with the link so they can sign whenever they need to. You can even post the link publicly if you want to maximize its reach, i.e. for sales contracts.
|
||||
|
||||
<video
|
||||
id="vid"
|
||||
width="100%"
|
||||
src="https://github.com/documenso/design/assets/1309312/129f690b-29b4-4a11-b9a0-14fc6648e611"
|
||||
autoPlay
|
||||
loop
|
||||
muted
|
||||
></video>
|
||||
|
||||
## Embrace Async
|
||||
|
||||
So, how does this help anyone? You may still need to send a signature request to people, but in the cases you don't, you are not forced to anymore. Need an NDA? Check out our standing NDA link. A customer needs an updated Form W-9? Just use the company W-9 Link; it always has the most up-to-date form. You can even go as far as publicly posting a link to a software development or design contract any potential customer can sign anytime. Can they talk to you first? Sure, but if they don't need to or already have to, they go straight to the link. The process of actively sending has gotten us used to using a sync paradigm (I send, you receive and sign, and I get the result), whereas an async one (you sign whenever it suits you, and I become active only then, if at all) is way better suited. Adding more approval and signature steps makes sure you still control the outcome, but the process becomes a lot more efficient. For example, you can grab your own copy of the early adopter's pledge here if you missed it: [documen.so/pledge](https://documen.so/pledge).
|
||||
|
||||
> Take a minute to think about every signing request you send and whether they really require you to be part of the transaction. Could they be outsourced to the recipient and only reviewed once their part is done?
|
||||
|
||||
## Coming Soon: Profiles
|
||||
|
||||
The best place to put your public links will be your **Documenso profile**, which is also close to launching. We want to get a feel for how links are used and move on to profiles shortly after. Want to try out direct links? Grab a free account here to get started: [documen.so/free](https://documen.so/free).
|
||||
|
||||
As always, we want to hear from you on [Twitter / X](https://twitter.com/eltimuro) (DMs are open) or [Discord](https://documen.so/discord) if you have any questions, ideas, or comments.
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,51 +0,0 @@
|
||||
---
|
||||
title: Announcing Documenso
|
||||
description: Launching an open-source document signing tool because trusted-based products should be built on openness. The first release will be in 2023. Sign up at documenso.com to be on board.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2022-12-29
|
||||
tags:
|
||||
- Announcement
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/blog-banner-announcing-documenso.webp"
|
||||
width="1400"
|
||||
height="884"
|
||||
alt="Documenso announcement blog banner"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">Documenso — The Open Source DocuSign Alternative.</figcaption>
|
||||
</figure>
|
||||
|
||||
## TL; DR;
|
||||
|
||||
I'm launching an open source document signing tool because trust-based products should be built on openness. The first release will be in 2023. Sign up at <a href="https://documenso.com" target="_blank">documenso.com</a> and get on board.
|
||||
|
||||
## Let’s build the world’s most trusted document-signing tool.
|
||||
|
||||
Today I'm excited to announce my new project Documenso. Documenso is an open source document signing tool you can host yourself and freely build upon because it's, you know, open source. Before I get more into the details of what and when will be launched I want to take a moment and talk about why.
|
||||
|
||||
## Digital signing is great
|
||||
|
||||
Signing Documents digitally has countless benefits: Less struggle with printing, less wasting paper, faster request delivery, easier changes, easier coordination of people far away, verifiable document integrity, and verifiable signer identity (this is a vast topic, will write more on soon), easier storage and search of signed documents, the list goes on. Digital Signatures take something very old and very trusted like personally signing documents into the digital space, adding the benefits listed above. It also introduces a new party to every signing transaction, the signing tool providers. What was peer to peer transaction before, now goes through an intermediary. While this isn't a problem in itself, it should make us think about how we want these providers of trust to work.
|
||||
|
||||
## How do we build trusted systems?
|
||||
|
||||
While doing research for Documenso I came upon a quote that expresses the current state of document signing pretty well:
|
||||
|
||||
> Document signing is NOT a technical problem. [Editor’s Note: Because it was solved technically a long time ago] It’s a legal acceptance problem — and everyone KNOWS DocuSign and friends and understands how they’re admissible. Anything else would have to compete with that and people would be suspicious of it for a long time.
|
||||
|
||||
While this may sound like a hurdle at first, it immediately gave me a sense of validation for a more open approach to signing. People will and should be suspicious of their tools and demand a high bar when it comes to trust. And the way to earn this trust is by being open. Trusted tools should be the result of thoughtful discussion and reviews. They should be the result of the needs and will of its community. They should be transparent, adaptable, and empowering while using. Open Source embodies these values very well for software, which makes it a perfect fit for this space and creating a high-trust tool.
|
||||
|
||||
## Next Steps
|
||||
|
||||
So, what can you expect from here on out? I've started to build Documenso 0.1 which is scheduled to release in “early” 2023. If you're interested in helping make this happen, let me know via [hi@documenso.com](mailto:hi@documenso.com). Getting working code into the hands of the perspective Documenso community is currently the #1 goal. Other than that I'll be releasing several articles about document signing and what something like Documenso should look like, in my humble opinion. So stay tuned!
|
||||
|
||||
If you think Documenso is worthy of support, please share <a href="https://documenso.com" target="_blank">documenso.com</a> with anyone interested, and sign up to be among the first to try out version 0.1 as soon as it launches.
|
||||
|
||||
Cheers from Hamburg
|
||||
|
||||
Timur
|
||||
@ -1,68 +0,0 @@
|
||||
---
|
||||
title: Documenso Profiles Are Here
|
||||
description: Today, we are launching Documenso Profiles, a new way to let your peers sign your documents.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-07-01
|
||||
tags:
|
||||
- Announcement
|
||||
- Direct Links
|
||||
- Profiles
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/profile1.png"
|
||||
width="1260"
|
||||
height="1260"
|
||||
alt="Documenso Profile of Timur"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">Let people sign anytime with Documenso Profiles. Try it [with my profile](https://app.documenso.com/p/timur).</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; We are launching a Documenso Profile where you can display your templates for everyone to sign at any time.
|
||||
|
||||
## Introducing Documenso Profiles
|
||||
|
||||
Today, I’m excited to announce that we are launching Documenso Profiles 🎉 While we have been focussing on the conventional signing experience so far, Direct Links and now profiles are our first steps to bring some long-awaited innovation back to digital signatures.
|
||||
|
||||
Documenso Profiles allows you to share any template with a public link in a very easy-to-understand way. Adding templates to your profiles allows everyone to sign your documents just when they need to. Forms, NDAs, Disclaimers, and even contracts are now available anytime they are needed. Profiles turn the classic signing flow on its head by letting the recipient sign first before the document’s owner becomes active. Booking links (e.g., Cal.com) and customer self-service portals (e.g., Stripe Billing Portal) are becoming the norm, so it’s time we did the same for signing.
|
||||
|
||||
## The Best Way to Share Your Singing Links
|
||||
|
||||
With profiles, we want to offer you the best way to share your standing Documenso Template Links in a public place. You can add your Documenso Profile to your social profiles, Email footer, Video Description, or wherever your audience, customers, and partners interact with you. The profile will be a public, trusted place to ensure you know who you are dealing with.
|
||||
|
||||
Looking at the classical social media fake profile problem, we know this is tricky to achieve. We will pay close attention to how profiles are used and how we can help the community use them easily and securely. As a first step towards this direction, we are introducing a trust badge next to your name. There will be 3 levels to start:
|
||||
|
||||
- Free Users: No Badge
|
||||
- Paid Users: Green Badge
|
||||
- Early Adopters: Gold Badge
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/profile2.png"
|
||||
width="1260"
|
||||
height="1260"
|
||||
alt="Documenso Profile Edit Screen"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">Add and remove templates anytime.</figcaption>
|
||||
</figure>
|
||||
|
||||
## An Open Economy built on Documenso
|
||||
|
||||
We see offering profiles as a first step towards creating a full economy on top of the open signing ecosystem we envision. While we want to keep building the product with the community, we also want an economy to grow on the open tech we create. This includes using the tech (profiles) or offering service on top of the tech (hosting and customization). Our ecosystem is still young, and the goal is not to have Documenso Inc. as the only commercial actor but to fill our own niche in a global and thriving open ecosystem. One of our guiding principles is solving things once and for all. While our focus will be on the core signing product, we want to enable others to offer templates for use on profiles or privately. A lot of contracts, forms, and other paperwork have been recreated countless times. Offering high-quality, peer-reviewed templates is a natural extension of the current platform. There will be free templates, offered as marketing for their creators, and paid templates, offered as actual products.
|
||||
|
||||
## What's next
|
||||
|
||||
While an open signing economy is really exciting, we know it will take time to mature. Building out a mature ecosystem for builders and entrepreneurs takes time. While this aspect of Documenso matures, we will be focussing on the core of the platform: Letting you integrate and embed Documenso wherever you want it.
|
||||
|
||||
If you already have a Documenso account, you can [activate your profile here](https://app.documenso.com/settings/public-profile).
|
||||
Don’t have an account and want to check out profiles? You can do so using our [free plan](https://documen.so/free).
|
||||
|
||||
As always, we want to hear from you on [Twitter / X](https://twitter.com/eltimuro) (DMs are open) or [Discord](https://documen.so/discord) if you have any questions, ideas, or comments.
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,63 +0,0 @@
|
||||
---
|
||||
title: 21 CFR Part 11 is here, and so is Vial.com
|
||||
description: We launched Vial.com with a 21 CFR Part 11 compliant setup. Reach out if 21 CFR Part 11 compliance is among your needs.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-07-18
|
||||
tags:
|
||||
- Vial.com
|
||||
- 21 CFR Part 11
|
||||
- Compliance
|
||||
---
|
||||
|
||||
<video id="vid" width="100%" src="/blog/vial.webm" autoPlay loop muted></video>
|
||||
<figcaption className="text-center">
|
||||
Vial.com uses Documenso for 21 CFR Part 11 compliant signing.
|
||||
</figcaption>
|
||||
|
||||
> TLDR; We launched Vial.com on Documenso and are open for 21 CFR Part 11 business.
|
||||
|
||||
# What is 21 CFR
|
||||
|
||||
You have never heard of 21 CFR Part 11? You are in good company since most people haven't. If you have, you probably work in an industry regulated by the U.S. Food and Drug Administration (FDA). Title 21 of the Code of Federal Regulations (CFR) is dedicated to detailing FDA-regulated business, and sub-part 11 sets out guidelines for using electronic signatures in this highly regulated field. Hence, 21 CFR Part 11 is highly relevant for regulated industries that aim to employ digital signatures. The guidelines set out in 21 CFR Part 11 aim to provide trustworthy, reliable, and equivalent to paper records and handwritten signatures. All Industries that fall under the FDA's regulation, e.g. pharmaceuticals, biotechnology, medical devices, and biologics, must comply with these rules when choosing or creating systems for electronic signatures.
|
||||
|
||||
Compliance with 21 CFR Part 11 is crucial for companies to use electronic records and signatures in their operations legally. It affects how companies manage documentation, conduct audits, and maintain regulatory submissions. Non-compliance can result in legal penalties, rejected submissions, and delays in product approvals, emphasizing the importance of adhering to these guidelines in FDA-regulated activities.
|
||||
|
||||
# Vial.com
|
||||
|
||||
Vial is a technology company on a mission to advance programs to market through computationally designed therapeutics and cost-effective clinical trials. It is imperative that Vial manages this process securely, effectively, and highly compliant. By leveraging it's modern platform, Vial aims to accelerate drug development and, ultimately, time to market for new therapies. You can learn more about them [here](https://vial.com/about-us).
|
||||
|
||||
[Together](https://documen.so/vial-documenso), Documenso and Vial set out to create the first open-source, 21 CFR Part 11 compliant signing solution. After iterating over the product together, Vial moved their operation from DocuSign, a known legacy signing provider, to a Documenso Enterprise plan. We are very happy to be able to support Vial’s mission by fulfilling our own: bringing open signing and all its innovation to where it's needed.
|
||||
|
||||
# 21 CFR Part 11 on Documenso Highlights
|
||||
|
||||
21 CFR Part 11 is a highly complex statute, and going into the all design rationales and the following implementation details, deserves its own article later. For now, I want to share a few notable highlights.
|
||||
|
||||
## The Full Experience
|
||||
|
||||
We implemented 21 CFR Part 11, keeping the main user experience of Documenso intact. Our 21 CFR module is not separate but natively integrated into all Documenso flows, thus not sacrificing usability for compliance. This also means most (if not all) advanced features we offer are usable in a compliant way. This prevents customers from being trapped in an anti-innovation bubble, not allowing access to new features for fear of non-compliance.
|
||||
|
||||
## Action Reauth Using Passkeys
|
||||
|
||||
<video id="vid" width="100%" src="/blog/vial2.webm" autoPlay loop muted controls></video>
|
||||
<figcaption className="text-center">
|
||||
Using passkeys (used here via fingerprint scanner) is the smoothest way to re-authenticate.
|
||||
</figcaption>
|
||||
|
||||
One of the requirements affecting day-to-day life the most is the requirement to actually reauthenticate every signature placed on a document. While we can't change that, we can help make the reauthentication as painless as possible. To this end, we opted for passkeys. While Documenso supports passkeys to log in, they are also supported to authenticate signing on a per-signature level as part of the Documenso Enterprise Plan. The user still has to authenticate every signature but can now do so from the comfort of their passkey provider, be that 1Password, their browser, or any other provider.
|
||||
|
||||
## Direct Links
|
||||
|
||||
We recently launched [Direct Template Links](https://documen.so/direct-links), a new way to let people sign and fill out forms. Links can be completed anytime, creating a new document in the process. Direct Links are also 21 CFR part 11 compliant, using action reauthentication, audit log, and all other compliance requirements.
|
||||
|
||||
# Documenso Enterprise Plan
|
||||
|
||||
With the successful launch of Vial, we are now open for business. 21 CFR Part 11 compliance is part of the Documenso Enterprise plan, which includes all regulations we currently support and upcoming additions. While the pricing depends heavily on your needs and scale, we offer fixed-price plans for better predictability for both sides. In our experience, volume-based pricing is a legacy headache we want to avoid.
|
||||
|
||||
If you are FDA-regulated and looking for a modern signing solution, we are happy to discuss your requirements in detail. You can write us (hi@documenso.com) or contact [our enterprise team](https://documen.so/21cfr) at any time or stage.
|
||||
|
||||
If you have any questions or comments, please reach out on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord).
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,98 +0,0 @@
|
||||
---
|
||||
title: 'Building Documenso — Part 1: Certificates'
|
||||
description: Let's take a look why you need a signing certificate and how Documenso does it.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2023-06-23
|
||||
tags:
|
||||
- Open Source
|
||||
- Document Signature
|
||||
- Certificates
|
||||
- Signing
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/blog-banner-building-documenso.webp"
|
||||
width="1200"
|
||||
height="675"
|
||||
alt="Building Documenso blog banner"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
What actually is a signature?
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
> Disclaimer: I’m not a lawyer and this isn’t legal advice. We plan to publish a much more specific framework on the topic of signature validity.
|
||||
|
||||
This is the first installment of the new Building Documenso series, where I describe the challenges and design choices that we make while building the world’s most open signing platform.
|
||||
|
||||
As you may have heard, we launched the community-reviewed <a href="https://github.com/documenso/documenso" target="_blank">version 0.9 of Documenso on GitHub</a> recently and it’s now available through the early adopter’s plan. One of the most fundamental choices we had to make on this first release, was the choice of certificate. While it’s interesting to know what we opted for, this shall also serve as a guide for everyone facing the same choice for self-hosting Documenso.
|
||||
|
||||
> Question: Why do I need a document signing certificate to self-host?
|
||||
>
|
||||
> Short Answer: Inserting the images of a signature into the document is only part of the signing process.
|
||||
|
||||
To have an actual digitally signed document you need a document signing certificate that is used to create the digital signature that is inserted into the document, alongside the visible one¹.
|
||||
|
||||
When hosting a signature service yourself, as we do, there are four main choices for handling the certificate: Not using a certificate, creating your own, buying a trusted certificate, and becoming and trusted service provider to issue your own trusted certificate.
|
||||
|
||||
## 1\. No Certificate
|
||||
|
||||
A lot of signing services actually don’t employ actual digital signatures besides the inserted image. The only insert and image of the signatures into the document you sign. This can be done and is legally acceptable in many cases. This option isn’t directly supported by Documenso without changing the code.
|
||||
|
||||
## 2\. Create your own
|
||||
|
||||
Since the cryptography behind certificates is freely available as open source you could generate your own using OpenSSL for example. Since it’s hardly more work than option 1 (using Documenso at least), this would be my minimum effort recommendation. Having a self-created (“self-signed”) certificate doesn’t add much in terms of regulation but it guarantees the document’s integrity, meaning no changes have been made after signing². What this doesn’t give you, is the famous green checkmark in Adobe Acrobat. Why? Because you aren’t on the list of providers Adobe “trusts”.³
|
||||
|
||||
## 3\. Buy a “trusted” certificate.
|
||||
|
||||
There are Certificate Authorities (CAs) that can sell you a certificate⁴. The service they provide is, that they validate your name (personal certificates) or your organization’s name (corporate certificate) before creating your certificate for you, just like you did in option 2. The difference is, that they are listed on the previously mentioned trust lists (e.g. Adobe’s) and thus the resulting signatures get a nice, green checkmark in Adobe Reader⁵
|
||||
|
||||
## 4\. Becoming a Trusted Certificate Authority (CA) yourself and create your own certificate
|
||||
|
||||
This option is an incredibly complex endeavour, requiring a lot of effort and skill. It can be done, as there are multiple CAs around the world. Is it worth the effort? That depends a lot on what you’re trying to accomplish.
|
||||
|
||||
<center>. . .</center>
|
||||
|
||||
## What we did
|
||||
|
||||
Having briefly introduced the options, here is what we did: Since we aim to raise the bar on digital signature proliferation and trust, we opted to buy an “Advanced Personal Certificates for Companies/Organisations” from WiseKey. Thus, documents signed with Documenso’s hosted version look like this:
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/blog-fig-building-documenso.webp"
|
||||
width="1262"
|
||||
height="481"
|
||||
alt="Figure 1"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">The famous green checkmark: Signed by hosted Documenso</figcaption>
|
||||
</figure>
|
||||
|
||||
There weren’t any deeper reasons we choose WiseKey, other than they offered what we needed and there wasn’t any reason to look much further. While I didn’t map the entire certificate market offering (yet), I’m pretty sure something similar could be found elsewhere. While we opted for option 3, choosing option 2 might be perfectly reasonable considering your use case.⁶
|
||||
|
||||
> While this is our setup, for now, we have a bigger plan for this topic. While globally trusted SSL Certificates have been available for free, courtesy of Let’s Encrypt, for a while now, there is no such thing as document signing. And there should be. Not having free and trusted infrastructure for signing is blocking a completely new generation of signing products from being created. This is why we’ll start working on option 4 when the time is right.
|
||||
|
||||
Do you have questions or thoughts about this? As always, let me know in the comments, on <a href="http://twitter.com/eltimuro" target="_blank">twitter.com/eltimuro</a>
|
||||
or directly: <a href="https://documen.so/timur" target="_blank">documen.so/timur</a>
|
||||
|
||||
Join the self-hoster community here: <a href="https://documen.so/discord" target="_blank">https://documen.so/discord</a>
|
||||
|
||||
Best from Hamburg
|
||||
|
||||
Timur
|
||||
|
||||
\[1\] There are different approaches to signing a document. For the sake of simplicity, here we talk about a document with X inserted signature images, that is afterward signed once the by signing service, i.e. Documenso. If each visual signature should have its own digital one (e.g. QES — eIDAS Level 3), the case is a bit more complex.
|
||||
|
||||
\[2\] Of course, the signing service provider technically can change and resign the document, especially in the case mentioned in \[1\]. This can be countered by requiring actual digital signatures from each signer, that are bound to their identity/ account. Creating a completely trustless system in the context however is extremely hard to do and not the most pressing business need for the industry at this point, in my opinion. Though, this would be nice.
|
||||
|
||||
\[3\] Adobe, like the EU, has a list of organizations they trust. The Adobe green checkmark is powered by the Adobe trust list, if you want to be trusted by EU standards here: <a href="https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/validation" target="_blank">https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/validation</a>, you need to be on the EU trust list. Getting on each list is possible, though the latter is much more work.
|
||||
|
||||
\[4\] Technically, they sign your certificate creation request (created by you), containing your info with their certificate (which is trusted), making your certificate trusted. This way, everything you sign with your certificate is seen as trusted. They created their certificate just like you, the difference is they are on the lists, mentioned in \[3\]
|
||||
|
||||
\[5\] Why does Adobe get to say, what is trusted? They simply happen to have the most used pdf viewer. And since everyone checks there, whom they consider trusted carries weight. If it should be like this, is a different matter.
|
||||
|
||||
\[6\] Self-Signed signatures, even purely visual signatures, are fully legally binding. Why you use changes mainly your confidence in the signature and the burden of proof. Also, some industries require a certain level of signatures e.g. retail loans (QES/ eIDAS Level 3 in the EU).
|
||||
@ -1,117 +0,0 @@
|
||||
---
|
||||
title: 'Building Documenso — Part 2: Signature Validity'
|
||||
description: Is a signature valid? And what does that mean? It's a surprisingly complex question; let's take a look.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-04-05
|
||||
tags:
|
||||
- Document Signature
|
||||
- Certificates
|
||||
- Signing
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/eu-validate-1.png"
|
||||
width= "650"
|
||||
height= "650"
|
||||
alt= "A report card for signature validity."
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
If a tree does not comply with the EU trust list, does it make a sound when validating?r
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; Signatures can be valid and compliant for different signature levels, even if some validators show higher-level errors. Not all helpful security measures are mandated by law.
|
||||
|
||||
# A valid question
|
||||
|
||||
A few days ago, an early adopter brought up this question in our [Discord](https://documen.so/discord):
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/eu-validate-2.png"
|
||||
width= "650"
|
||||
height= "650"
|
||||
alt= "A report card for signature validity."
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
You can check out the validator here: [https://documen.so/eu-validator](https://documen.so/eu-validator)
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
For those unfamiliar with the tool, he used the validator tool of the EU's Digital Signature Service (DSS) Framework to check the signature of a document signed with Documenso. The EU provides this tool to help users and providers check the validity level of their signatures.
|
||||
|
||||
A short refresher from [Building Documenso — Part 1: Certificates](https://documen.so/certs):
|
||||
|
||||
> Documenso inserts all visual signatures into the document and then seals it using the "Documenso Inc." corporate certificate. This makes the resulting PDF document tamper-proof and guarantees it hasn't changed since signing.
|
||||
|
||||
Before we answer if the document was signed correctly, we need to understand what the goal was.
|
||||
|
||||
There are three signature levels in the European eIDAS regulation:
|
||||
|
||||
1. **Simple Electronic Signatures (Level 1/ SES):** This is just a visual signature or even a checkbox on a document.
|
||||
|
||||
2. **Advanded Electronic Signatures (Level 2/ AES)**: An actual crypographic signature (not just a seal on the whole document, but a specific signature), using a certificate linked to the identification data of the signer.
|
||||
|
||||
3. **Qualified Electronic Signatures (Level 3/ QES):** Same as 2. but done by a government-certified entity on certified hardware and after identifying the signer with an official ID document (e.g., passport)
|
||||
|
||||
> 💡 Side Note: Number 2 (AES) is how most people imagine digital signatures. But most of the market uses 1. plus a seal on the whole document under the name of the signing provider (e.g., Documenso). The signer's data is only inserted visually, not in the actual signature. Why? One of the reasons is that it's much easier, and without a readily available open source framework to draw from, it is quite tricky to build. This is something we aim to build (which many have done) and open source (which no one has done).
|
||||
|
||||
From the perspective of eIDAS, Documenso offers Level 1/ SES signatures since it does not adhere to all of the requirements of Level 2/ AES. This means that, technically, there is no legal need to seal the document to achieve this level of validity (at least within eIDAS). We do it anyway since it improves the level of confidence users can have in the signed document. Sealing the document, even though not legally required, is a great example of Documenso's approach to signatures. First, we aim to provide all legal requirements for a given use case. Then, we add any protection that can be added without unwarranted friction to the creation of the signature.
|
||||
|
||||
## Not if valid, but how valid
|
||||
|
||||
**Q: So, is the signature in the image valid?**
|
||||
|
||||
A: Yes, as an eidas Level 1 SES.
|
||||
|
||||
**Q: Then why does it say "Unable to build a certificate chain up to a trusted list"**
|
||||
|
||||
A: The certificate we use to seal the document after inserting the signatures is not on the EU Trust list.
|
||||
|
||||
**Q: Does that mean it is less secure?**
|
||||
|
||||
A: No, it means the provider (Wisekey) is not on a list maintained by the EU. The cryptographic signature is just as strong as any other
|
||||
|
||||
For someone who does not deal with this stuff daily, this can be hard to comprehend. Whether you use a certificate you generated yourself, one generated by a certificate authority (CA) like Wisekey, or one by another on the EU trust list (e.g., Bundesdruckerei), the cryptographic security guaranteeing that the document has not been tampered with is always the same. Many providers like Documenso, DocuSign, PandaDoc, and Digisigner all use this method for their regular plans. That means if you were to run a document signed by them through the validator above, the result would be the same[1]. The interesting question is why? Why do it like this?
|
||||
|
||||
## Certificate Infrastructure is broken
|
||||
|
||||
While there are some actual expenses involved in providing AES and QES, the blunt reality is that it's just good business to charge for them per signature, making it unsuitable for the "standard offerings"; almost no one has the resources to set this up themselves. While this initial process of becoming a QES-certified entity is really expensive, selling the certificates afterward is very lucrative. This leads to less innovation in the space and only big players providing these high-compliance services. Even certificates only used to seal documents without being QES certified are sold for a large range of prices, and they cost almost nothing to produce.
|
||||
|
||||
## Why Though?
|
||||
|
||||
**Q: Why do people buy a certificate for money and not just generate one themselves? Isn't the cryptographic security the same?**
|
||||
|
||||
A: Self-generated certificates are not recognized for higher-level compliance signatures like QES
|
||||
|
||||
**Q: So if you don't need higher-level signatures, you could just generate one yourself?**
|
||||
|
||||
A: Yes, you could. Since eIDAS Level 1 does not require a cert, you could use your own.
|
||||
|
||||
**Q: Why don't more people?**
|
||||
|
||||
A: One reason is that apart from the EU trust list, there are others, like the Adobe trust list. While not legally required, being on that one (like Wisekey) gives you a green checkmark in Adobe PDF, which is how most people check signature validity.
|
||||
|
||||
**Q: Not a question, but all of this sounds weird**
|
||||
|
||||
A: It is. This is one of the reasons why Documenso exists. We plan to make this easier.
|
||||
|
||||
**Q: How?**
|
||||
|
||||
A: By explaining and providing easy-to-use tools and eventually free, highly compliant signature certificates for everyone.
|
||||
|
||||
Eventually, we plan to start a free certificate authority called Let's Sign, named after another instituion that broke the paid certificate paradigm to the benefit of the internet: [Let's Encrypt](https://letsencrypt.org/).
|
||||
|
||||
As always, feel free to connect on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord) if you have any questions or comments.
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
\
|
||||
\
|
||||
\
|
||||
[1] The signature format (e.g. PKCS7-B) will vary. It's the format what the signature inserted into the document looks like. eIDAS itself does not specifically require any given format, but the PAdES defined by the EU is mostly used by european providers.
|
||||
@ -1,82 +0,0 @@
|
||||
---
|
||||
title: Cal.com Chooses Documenso for DPA and BAA Scalability and Compliance
|
||||
description: Learn how Cal.com scales their Data Processing Agreement (DPA) and Business Associate Agreement (BAA) processes with Documenso’s open source platform as they grow.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-10-11
|
||||
tags:
|
||||
- Customer Story
|
||||
- Open Startup
|
||||
- Open Source
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/cal2.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="Scheduling Infrastructure for Everyone"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Scheduling Infrastructure for Everyone.
|
||||
</figcaption>
|
||||
</figure>
|
||||
TL;DR: Cal.com uses Documenso’s template direct links to facilitate low-friction compliance paperwork, enhancing scalability and user experience.
|
||||
|
||||
## Cal.com – The Most Public Private Company
|
||||
|
||||
[Cal.com](Cal.com) is an open source company that needs no introduction. Founded in 2021 by Bailey Pumfleet and Peer Richelsen, it quickly evolved from an open source alternative to the widespread but limited scheduling platform Calendly into the internet’s most beloved scheduling solution. Starting with just two founders, Cal.com has grown into a team of 22, facilitating millions of bookings per year for its ever-growing user and customer base.
|
||||
|
||||
Their commitment to transparency is evident as they follow the [open startup movement](https://cal.com/open), opening up not only their source code but also providing insights into their business operations. Their Commercial Open Source Software (COSS) model, combining a company and an open source project, has inspired a whole cohort of startups joining the space—not least of which is Documenso.
|
||||
|
||||
## The Need
|
||||
|
||||
At this point, Cal.com serves customers of all sizes, from single users to large enterprises. To provide the best product for their customers, they are certified for SOC 2, HIPAA, GDPR, and many other compliance regulations. One challenge that comes with this is the increasing number of waivers that need to be signed when onboarding customers. Business Associate Agreements (BAAs) and Data Processing Agreements (DPAs) are two of the more commonly known examples. To get these signed with minimal effort for both sides, they were looking for a solution to handle these at scale.
|
||||
|
||||
> We love open source.
|
||||
|
||||
— Peer Richelsen, Co-Founder, Cal.com
|
||||
|
||||
Being an open source company, they also prefer open source in their vendors—for both the shared philosophy and the higher level of trust. The goal was to integrate signing into the checkout process as seamlessly as possible.
|
||||
|
||||
## The Solution
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/cal.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="Cal.com direct link template to sign a DPA"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Sign a DPA with Cal by clicking a link anytime.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
Documenso offers exactly this solution through direct link templates, enabling Cal.com to:
|
||||
|
||||
- Provide Immediate Access: Customers can access and sign necessary compliance documents through direct links at any time.
|
||||
- Enhance User Experience: Users are immediately forwarded to onboarding after signing.
|
||||
- Ensure Easy Access: The documents are stored within the company’s team account, allowing easy access for anyone who needs them.
|
||||
|
||||
Direct Link templates can also easily be embedded, using the [Documenso widget](https://documen.so/embedded). Embedding anywhere, pre-Filling the templates and notfiying the compliance team at certain point of the flow are a few of the many option the team now has in continously enhanceing their onboard and compliance UX.
|
||||
|
||||
Read more about our direct link templates here: [Direct Link Signing](https://docs.documenso.com/users/direct-links).
|
||||
|
||||
## The Journey
|
||||
|
||||
Initially, Cal.com’s team approached the new solution with skepticism. As Bailey reflected:
|
||||
|
||||
> We were intrigued but skeptical at first, as we put a lot of thought into compliance and doing things right. Documenso’s documentation and support showcased how their direct link templates could meet our needs while being highly compliant.
|
||||
|
||||
This experience highlights Documenso’s trust philosophy. We strive to be transparent in everything we do and let people judge for themselves. It also shows that we neither want nor get trust by default. Doing things right is a conversation worth having, especially in a space as opaque as digital signatures. It goes without saying that the whole team is hyped to have Cal.com on board and yet another open source company joining the open signing movement 🚀
|
||||
|
||||
If you have any questions or comments, please reach out on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord).
|
||||
|
||||
Thinking about switching to a modern signing platform? Reach out anytime: [https://documen.so/sales](https://documen.so/sales)
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,87 +0,0 @@
|
||||
---
|
||||
title: Commodifying Signing
|
||||
description: We are creating signing as a public good and are commoditizing it to make it cheaper and better.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-01-25
|
||||
tags:
|
||||
- Vision
|
||||
- Mission
|
||||
- Open Source
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/lighthouse.jpeg"
|
||||
width="650"
|
||||
height="650"
|
||||
alt="A lighthouse on a tiny island."
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Lighthouses are often used as an example of a public good; As they benefit all maritime users, but no one can be excluded from using them as a navigational aid. Use by one person neither prevents access by other people, nor does it reduce availability to others.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
# Commodifying Signing
|
||||
|
||||
> TLDR; We are creating signing as a public good and are commoditizing it to make it cheaper and better.
|
||||
|
||||
While we are in full-on building mode with Documenso, I think a lot about the big picture of what we are attempting to do. One phrase that keeps popping up is, "We are commodifying signing." Let's dig deeper into what that means.
|
||||
|
||||
Let's start with why we are doing this. Documenso's mission is to solve the domain of signing once and for all for everyone. In so many calls, I hear stories about how organizations build their own solution because the existing ones are too expensive or need to be more flexible. That means not hundreds but probably thousands of companies worldwide have done the same. This is simply wasting humanity's time. Since digital signing systems are understood well enough that seemingly "everyone" can build them, given enough pain, It's time to do it once correctly.
|
||||
|
||||
## Is signing already a commodity?
|
||||
|
||||
> In economics, a **commodity** is an economic good, usually a resource, that has explicitly full or substantial fungibility: that is, the market treats instances of the good as equivalent or nearly so with no regard to who produced them.
|
||||
|
||||
That sounds like the signing market today. There is no shortage of signing providers, and you can get similar signing services from many places. So why is this different from what we want, and why does this not satisfy the market?
|
||||
|
||||
- Signing is expensive and painful when you are locked into your vendor, and they charge by signing volume.
|
||||
- Signing is also expensive and painful when you have to build it yourself since no vendor fits your requirements or you are not allowed to
|
||||
|
||||
To understand why, we need to look at the landscape as it is today:
|
||||
|
||||
- **Commodity**: Signing SaaS
|
||||
- **Private Goods**: Signing Code Base, Regulatory Know-How
|
||||
- **Public Goods**: Web Tech, Digital Signature Algorithms and Standards
|
||||
|
||||
What the current players have done is to commodify the listed public goods into commercial products:
|
||||
|
||||
> […]the action and process of transforming goods, services, ideas, nature, personal information, people, or animals into commodities.
|
||||
> (Let's ignore the end of that list for now and what it says about humanity, yikes)
|
||||
|
||||
While this paradigm brought digital signing to many businesses worldwide, we aim for a different future. To solve signing once and for all, we need to achieve two core points:
|
||||
|
||||
- Making it cheaper so it's profitable for everyone to use
|
||||
- Making it more accessible so everyone can use it (e.g. regulated industries) and flexible enough (extendable, open).
|
||||
|
||||
To achieve this, we must transform the landscape to look like this:
|
||||
|
||||
- **Commodities**: Enterprise Components, Support, Hosting, Self-Host Licenses
|
||||
- **Public Goods**: (no longer private): OS (Open Source) Signing Code Base, OS Regulatory Know-How
|
||||
- **Public Goods**: OS Web Tech, Digital Signature Algorithms and Standards
|
||||
|
||||
## Raising the Bar
|
||||
|
||||
Before creating a commodity, we are raising the bar of what the underlying public good is. Having an open source singing framework you can extend, self-host, and understand makes the resulting solution much more accessible and extendable for everyone. Now for the final feat of making signing cheaper:
|
||||
|
||||
As we have seen, signing has already been commodified. But since it was done by a closed source and, frankly, a very opaque industry, no downward price spiral has ensued. By building Documenso open source with an open culture, we can pierce the veil and trigger what the space has been missing for a long time: Commoditization. If you had to read that again, so did I:
|
||||
|
||||
> In business literature, **commoditization** is defined as the process by which goods that have economic value and are distinguishable in terms of attributes (uniqueness or brand) become simple commodities in the eyes of the market or consumers.
|
||||
|
||||
By only selling what creates value for the customer (hosting a highly available service, keeping it compliant, supporting with technical issues and challenges, preparing industry-specific components), we are commoditizing signing since everyone can do it now: The resources enabling it are public goods, aka. open source. A leveled playing field, as described above, is the perfect environment for a community-first, technology-first, and value-first company like Documenso to flourish.
|
||||
|
||||
## Changing the Game
|
||||
|
||||
In this new world, a company needing signing (literally every company) can decide if the ROI (Return on Investment) of building signing themselves is greater than simply paying for the value-added activities they will need anyway. Pricing our offering not on volume but fixed is a nice additional wedge into the market we intend to use here.
|
||||
|
||||
The market dynamic now changes to who can offer the greatest value added to the public goods, driving the price down as this can be done much more efficiently than locking customers into closed source SaaS. Documenso, being a lean company, which we intend to stay with for a long time, will help kickstart this effect. Open Source capital efficiency is real. Our planned enterprise components, hosting support, and partner ecosystem will all leverage this effect.
|
||||
|
||||
We will grow our community around the public good, the open-source repo, and create an ecosystem around the commodities built on top of it (components, hosting, compliance, support). We will solve signing once and for all, and the world will be better for it. Onwards.
|
||||
|
||||
As always, feel free to connect on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord) if you have any questions or comments.
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,96 +0,0 @@
|
||||
---
|
||||
title: Creating an Efficient Statement of Work Approval Process with Documenso
|
||||
description: Submitting statements of work can be a drag on morale and project efficiency. Let's look at how to create a modern, low-friction workflow for this.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-07-23
|
||||
tags:
|
||||
- Freelancer
|
||||
- Statement of Work
|
||||
- Productivity
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/sov.webp"
|
||||
width="1400"
|
||||
height="884"
|
||||
alt="Working papers image"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">Fine-tune your process using custom role for everyone involved.</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; Statements of Work detail what needs to be done. Automate sending and approving them using Documenso and Zapier.
|
||||
|
||||
## What is a Statement of Work
|
||||
|
||||
A statement of work is a detailed document that outlines what needs to be done in a project. It covers the project's scope, objectives, and deliverables, laying out all the tasks, deadlines, and milestones. The statement of work also spells out who’s responsible for what, ensuring everyone’s on the same page. It’s a roadmap that keeps both clients and service providers aligned and ensures the project stays on track from start to finish.
|
||||
|
||||
In the context of freelance work, the statement of work is a document that outlines the details of a project between a freelancer and their client. It's a concrete work to be agreed upon and tracked after completion. The statement of work is created after the [proposal is accepted](https://documen.so/freelance-proposal) and the [contract signed](https://documen.so/freelance-contract).
|
||||
|
||||
## What does a good workflow look like?
|
||||
|
||||
### 1. Create the statement of work
|
||||
|
||||
The team at Zapier created a [excellent guide](https://zapier.com/blog/statement-of-work-template/), which goes into the statement of work. There is a short checklist:
|
||||
|
||||
- Project Context/ Current Scope
|
||||
- Objectives for this piece of work
|
||||
- Scope (tasks, activities, and limits)
|
||||
- Requirements (e.g., technical and regulatory)
|
||||
- Deliverables to be created
|
||||
- Roles and Responsibilities
|
||||
|
||||
### 2. Get approval from subject matter experts (optional)
|
||||
|
||||
Since a statements of work can be very technical, having professionals from either side approve it first can be sensible. This can avoid double or unnecessary work and minimize the chances of misunderstandings. If this makes sense, it depends heavily on the scale of the project and the level of insight of the professional providing it.
|
||||
|
||||
### 3. Let the client sign off
|
||||
|
||||
Having the client sign off on the concrete work is the central step of the statement of work workflow. Assuming the document’s content is correct, getting the go-ahead ensures everyone is aligned and clear on what should and will be worked on.
|
||||
|
||||
### 4. Inform other Stakeholders (optional)
|
||||
|
||||
Depending on the scale of the organizations working together, other people may need to be kept in the loop. This could be accounting on either side, project managers, or other interested parties.
|
||||
|
||||
## Fine-Tuning the Flow with Custom Roles
|
||||
|
||||
<figure>
|
||||
<MdxNextImage src="/blog/roles.webp" width="1400" height="884" alt="Documenso Roles UI" />
|
||||
<figcaption className="text-center">
|
||||
Let's take a look at what it would look like with Documenso.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
### 1. Creating the Document: Templates vs. Custom Document
|
||||
|
||||
[Creating a template](https://docs.documenso.com/users/templates) can make sense if you submit statements of work regularly. If you create a Documenso Template, you can add [dynamic text and number fields](https://docs.documenso.com/users/signing-documents/fields) to be filled out when using the template. Another approach to this is creating a template on a document service like Google Docs, filling out a new copy, and uploading the custom-created document to Documenso.
|
||||
|
||||
Different parts of this process can be automated using the [Zapier Documenso Integration](https://documen.so/zapier) as desired:
|
||||
|
||||
- Automatically sending out a template to be filled out and signed
|
||||
- Creating a document in Documenso from a newly created document in Google Docs
|
||||
- Triggering sending a document created from either template or automation
|
||||
|
||||
### 2. Approvals
|
||||
|
||||
Looping in subject matter experts can easily be done using the approver role. This role allows you to complete a document without blocking the signing. This means the client can sign a document, even if the approval is not yet in place, removing friction. However, having the approval denied will stop the document from being completed and let everyone know there are corrections to be made. A software version of this is possible, having the expert in a viewer role and marking the document as seen without the option to block.
|
||||
|
||||
### 3. Signers
|
||||
|
||||
Looping in the client is done by adding one or more signer roles. Signer roles require recipients to place at least one signature to fulfill their part in the flow.roles
|
||||
|
||||
### 4. BCC
|
||||
|
||||
You can add one or several BCC roles to inform interested parties, e.g., accounting or project managers. As the process finishes, BCC recipients receive a copy of the completed document (assuming it completes and is not blocked). Using BCC roles automates filling in everyone who is only interested in the outcome and wants to avoid involvement in the steps leading up to it.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Streamlining your statement of work approval process with Documenso can significantly improve productivity and ease. Using templates, dynamic fields, and Zapier integrations, you can create a smooth, efficient workflow from start to finish. Adding roles for experts, signers, and BCC recipients tailors the process to fit your project's needs, ensuring everyone stays on the same page.
|
||||
|
||||
An efficient SOW process saves time and improves communication, letting you focus on delivering great work. We're excited to hear your thoughts and experiences—reach out on [Twitter / X](https://twitter.com/eltimuro) (DMs are open) or [Discord](https://documen.so/discord) if you have any questions, ideas, or comments.
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,85 +0,0 @@
|
||||
---
|
||||
title: 'Customer Story Prisma: 4 Reasons why Prisma chose Documenso for Signatures'
|
||||
description: We are happy to welcome Prisma, another OSS company, as a customer. Read here why they choose us.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-09-26
|
||||
tags:
|
||||
- Prisma
|
||||
- Customer Story
|
||||
- Open Source
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/prisma.png"
|
||||
width="1200"
|
||||
height="675"
|
||||
alt="Primsa Landing Page We simplify database migration, connection pooling, database queries, and readable data models."
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Prisma uses Documenso for collaborative team signing.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; Prisma is now using Documenso, and [we added visibility scopes](https://docs.documenso.com/users/document-visibility)
|
||||
|
||||
# Prisma
|
||||
|
||||
Prisma is an open-source company known for its modern OSS ORM (Object-Relational Mapping) tools that simplify database interactions for developers. Their flagship product, Prisma ORM, provides a type-safe way to query databases like PostgreSQL, MySQL, and many more. With the addition of Prisma Studio, an intuitive database management interface, Prisma makes it easier and more efficient for developers to work with databases. With their new additions, Prisma Pulse and Accelerate, you can react to real-time database changes and optimize your queries. And they are completely [open source](https://github.com/prisma/prisma)!
|
||||
|
||||
# We choose Prisma too!
|
||||
|
||||
I discovered Prisma when planning the tech stack for the [first version of Documenso](https://github.com/documenso/documenso/releases/tag/0.9-developer-preview). Prisma has felt natural to use since day one and has been the base of our database architecture ever since. It's great to see them develop and grow with us.
|
||||
|
||||
# Why they choose us
|
||||
|
||||
## 1. Signature Flows
|
||||
|
||||
Documenso signing flows are highly configurable, designed to adapt to the needs of any document signing process. Whether you're working with different roles, varying settings, or specific delivery methods, Documenso offers the flexibility to suit your requirements. You can choose to send documents via email, share a manual link, generate a link through the API, or even use a static direct link for quick access—all while ensuring a smooth signing experience.
|
||||
|
||||
Additionally, you can create templates to streamline and reuse common workflows, saving valuable time. Direct link templates enable users to drive the flow themselves, providing a straightforward path for signing. For a seamless experience, Documenso also allows you to embed the signing process directly into your website, ensuring an uninterrupted, integrated workflow tailored to your needs.
|
||||
|
||||
## 2. Modern UX
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/dsux.png"
|
||||
width="1200"
|
||||
height="675"
|
||||
alt="A completed document in Documenso, ready to download."
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
We call Documenso's design "Happy Minimalism"
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
We’ve crafted Documenso with a sleek, modern interface that makes it incredibly easy to use. Whether you’re signing documents, managing workflows, or fine-tuning settings, its intuitive design allows you to accomplish tasks quickly and effortlessly. More than just powerful, Documenso is a pleasure to navigate—designed to be accessible to everyone, no matter their level of tech experience.
|
||||
|
||||
## 3. Teams
|
||||
|
||||
### Teamwork Makes the Dream Work
|
||||
|
||||
Documenso makes teamwork a breeze with its team management features. You can easily set up and organize teams, making it simple to share and manage documents and workflows together. This is a lifesaver for larger organizations or teams spread across different departments, ensuring everyone stays in sync and on track. Different visibility scopes ensure private documents stay private and others are shared for easy collaboration.
|
||||
|
||||
### Document Visibility
|
||||
|
||||
Collaboration within a team often demands different levels of access to documents. For instance, the Documenso team at Prisma needed a way to set custom visibility on some documents while keeping others accessible to everyone. To address this need, we introduced role-based visibility scopes. This feature allows teams to manage documents more effectively. They can make certain documents visible only to managers or, in special cases, restricted to admins. This ensures sensitive information stays protected while general documents remain accessible to those who need them.
|
||||
|
||||
Learn more about visibility scopes and [how they can benefit your team here](https://docs.documenso.com/users/document-visibility).
|
||||
|
||||
## 4. OSS!
|
||||
|
||||
As you might know, we are open-source! This means you can peek under the hood, tweak things to your liking, and even contribute to making the platform better. We love the community-driven aspect of open-source, and it aligns perfectly with our goal to keep improving and innovating with input from our users.
|
||||
|
||||
So, whether you're looking to streamline your document workflows or just need a solid, reliable platform, Documenso has got your back. And we're thrilled to serve another OSS company and help make the space more open.
|
||||
|
||||
If you have any questions or comments, please reach out on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord).
|
||||
|
||||
Thinking about switching to a modern signing platform? Reach out anytime: [https://documen.so/sales](https://documen.so/sales)
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,198 +0,0 @@
|
||||
---
|
||||
title: 'Deploying Documenso with Vercel, Supabase and Resend'
|
||||
description: This is the first part of the new Building Documenso series, where I describe the challenges and design choices that we make while building the world’s most open signing platform.
|
||||
authorName: 'Ephraim Atta-Duncan'
|
||||
authorImage: '/blog/blog-author-duncan.jpeg'
|
||||
authorRole: 'Software Engineer Intern'
|
||||
date: 2023-09-08
|
||||
tags:
|
||||
- Open Source
|
||||
- Self Hosting
|
||||
- Tutorial
|
||||
---
|
||||
|
||||
In this article, we'll walk you through how to deploy and self-host Documenso using Vercel, Supabase, and Resend.
|
||||
|
||||
You'll learn:
|
||||
|
||||
- How to set up a Postgres database using Supabase,
|
||||
- How to install SMTP with Resend,
|
||||
- How to deploy your project with Vercel.
|
||||
|
||||
If you don't know what [Documenso](https://documenso.com/) is, it's an open-source alternative to DocuSign, with the mission to create an open signing infrastructure while embracing openness, cooperation, and transparency.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before we start, make sure you have a [GitHub](https://github.com/signup) account. You also need [Node.js](https://nodejs.org/en) and [npm](https://www.npmjs.com/) installed on your local machine (note: you also have the option to host it on a cloud environment using Gitpod for example; that would be another post). If you need accounts on Vercel, Supabase, and Resend, create them by visiting the [Vercel](https://vercel.com/), [Supabase](https://supabase.com/), and [Resend](https://resend.com/) websites.
|
||||
|
||||
Checklist:
|
||||
|
||||
- [ ] Have a GitHub account
|
||||
- [ ] Install Node.js
|
||||
- [ ] Install npm
|
||||
- [ ] Have a Vercel account
|
||||
- [ ] Have a Supabase account
|
||||
- [ ] Have a Resend account
|
||||
|
||||
## Step-by-Step guide to deploying Documenso with Vercel, Supabase, and Resend
|
||||
|
||||
To deploy Documenso, we'll take the following steps:
|
||||
|
||||
1. Fork the Documenso repository
|
||||
2. Clone the forked repository and install dependencies
|
||||
3. Create a new project on Supabase
|
||||
4. Copy the Supabase Postgres database connection URL
|
||||
5. Create a `.env` file
|
||||
6. Run the migration on the Supabase Postgres Database
|
||||
7. Get your SMTP Keys on Resend
|
||||
8. Create a new project on Vercel
|
||||
9. Add Environment Variables to your Vercel project
|
||||
|
||||
So, you're ready? Let’s dive in!
|
||||
|
||||
### Step 1: Fork the Documenso repository
|
||||
|
||||
Start by creating a fork of Documenso on GitHub. You can do this by visiting the [Documenso repository](https://github.com/documenso/documenso) and clicking on the 'Fork' button. (Also, star the repo!)
|
||||
|
||||

|
||||
|
||||
Choose your GitHub profile as the owner and click on 'Create fork' to create a fork of the repo.
|
||||
|
||||

|
||||
|
||||
### Step 2: Clone the forked repository and install dependencies
|
||||
|
||||
Clone the forked repository to your local machine in any directory of your choice. Open your terminal and enter the following commands:
|
||||
|
||||
```bash
|
||||
# Clone the repo using Github CLI
|
||||
gh repo clone [your_github_username]/documenso
|
||||
|
||||
# Clone the repo using Git
|
||||
git clone <https://github.com/[your_github_username]/documenso.git>
|
||||
```
|
||||
|
||||
You can now navigate into the directory and install the project’s dependencies:
|
||||
|
||||
```bash
|
||||
cd documenso
|
||||
npm install
|
||||
```
|
||||
|
||||
### Step 3: Create a new project on Supabase
|
||||
|
||||
Now, let's set up the database.
|
||||
|
||||
If you haven't already, create a new project on Supabase. This will automatically create a new Postgres database for you.
|
||||
|
||||
On your Supabase dashboard, click the '**New project**' button and choose your organization.
|
||||
|
||||
On the '**Create a new project**' page, set a database name of **documenso** and a secure password for your database. Choose a region closer to you, a pricing plan, and click on '**Create new project**' to create your project.
|
||||
|
||||

|
||||
|
||||
### Step 4: Copy the Supabase Postgres database connection URL
|
||||
|
||||
In your project, click the '**Settings**' icon at the bottom left.
|
||||
|
||||
Under the '**Project Settings**' section, click '**Database**' and scroll down to the '**Connection string**' section. Copy the '**URI**' and update it with the password you chose in the previous step.
|
||||
|
||||

|
||||
|
||||
### Step 5: Create a `.env` file
|
||||
|
||||
Create a `.env` file in the root of your project by copying the contents of the `.env.example` file.
|
||||
|
||||
Add the connection string you copied from your Supabase dashboard to the `DATABASE_URL` variable in the `.env` file.
|
||||
|
||||
The `.env` should look like this:
|
||||
|
||||
```bash
|
||||
DATABASE_URL="postgres://postgres:[YOUR-PASSWORD]@db.[YOUR-PROJECT-REF].supabase.co:5432/postgres"
|
||||
```
|
||||
|
||||
### Step 6: Run the migration on the Supabase Postgres Database
|
||||
|
||||
Run the migration on the Supabase Postgres Database using the following command:
|
||||
|
||||
```bash
|
||||
npx prisma migrate deploy
|
||||
```
|
||||
|
||||
### Step 7: Get your SMTP Keys on Resend
|
||||
|
||||
So, you've just cloned Documenso, installed dependencies on your local machine, and set your database using Supabase. Now, SMTP is missing. Emails won't go out! Let's fix it with Resend.
|
||||
|
||||
In the **[Resend](https://resend.com/)** dashboard, click 'Add API Key' to create a key for Resend SMTP.
|
||||
|
||||

|
||||
|
||||
Next, add and verify your domain in the '**Domains**' section on the sidebar. This will allow you to send emails from any address associated with your domain.
|
||||
|
||||

|
||||
|
||||
You can update your `.env` file with the following:
|
||||
|
||||
```jsx
|
||||
SMTP_MAIL_HOST = 'smtp.resend.com';
|
||||
SMTP_MAIL_PORT = '25';
|
||||
SMTP_MAIL_USER = 'resend';
|
||||
SMTP_MAIL_PASSWORD = 'YOUR_RESEND_API_KEY';
|
||||
MAIL_FROM = 'noreply@[YOUR_DOMAIN]';
|
||||
```
|
||||
|
||||
### Step 8: Create a new project on Vercel
|
||||
|
||||
You set the database with Supabase and are SMTP-ready with Resend. Almost there! The next step is to deploy the project — we'll use Vercel for that.
|
||||
|
||||
On your Vercel dashboard, create a new project using the forked project from your GitHub repositories. Select the project among the options and click '**Import**' to start running Documenso.
|
||||
|
||||

|
||||
|
||||
### Step 9: Add Environment Variables to your Vercel project
|
||||
|
||||
In the '**Configure Project**' page, adding the required Environmental Variables is essential to ensure the application deploys without any errors.
|
||||
|
||||
Specifically, for the `NEXT_PUBLIC_WEBAPP_URL` and `NEXTAUTH_URL` variables, you must add `.vercel.app` to your Project Name. This will form the deployment URL, which will be in the format: `https://[project_name].vercel.app`.
|
||||
|
||||
For example, in my case, the deployment URL is `https://documenso-supabase-web.vercel.app`.
|
||||
|
||||

|
||||
|
||||
This is a sample `.env` to deploy. Copy and paste it to auto-populate the fields and click ‘**Deploy.’** Now, you only need to wait for your project to deploy. You’re going live — enjoy!
|
||||
|
||||
```bash
|
||||
DATABASE_URL='postgresql://postgres:typeinastrongpassword@db.njuigobjlbteahssqbtw.supabase.co:5432/postgres'
|
||||
|
||||
NEXT_PUBLIC_WEBAPP_URL='https://documenso-supabase-web.vercel.app'
|
||||
NEXTAUTH_SECRET='something gibrish to encrypt your jwt tokens'
|
||||
NEXTAUTH_URL='https://documenso-supabase-web.vercel.app'
|
||||
|
||||
# Get a Sendgrid Api key here: <https://signup.sendgrid.com>
|
||||
SENDGRID_API_KEY=''
|
||||
|
||||
# Set SMTP credentials to use SMTP instead of the Sendgrid API.
|
||||
SMTP_MAIL_HOST='smtp.resend.com'
|
||||
SMTP_MAIL_PORT='25'
|
||||
SMTP_MAIL_USER='resend'
|
||||
SMTP_MAIL_PASSWORD='YOUR_RESEND_API_KEY'
|
||||
MAIL_FROM='noreply@[YOUR_DOMAIN]'
|
||||
|
||||
NEXT_PUBLIC_ALLOW_SIGNUP=true
|
||||
```
|
||||
|
||||
## Wrapping up
|
||||
|
||||

|
||||
|
||||
Congratulations! 🎉 You've successfully deployed Documenso using Vercel, Supabase, and Resend. You're now ready to create and sign your own documents with your self-hosted Documenso!
|
||||
|
||||
In this step-by-step guide, you learned how to:
|
||||
|
||||
- set up a Postgres database using Supabase,
|
||||
- install SMTP with Resend,
|
||||
- deploy your project with Vercel.
|
||||
|
||||
Over to you! How was the tutorial? If you enjoyed it, [please do share](https://twitter.com/documenso/status/1700141802693480482)! And if you have any questions or comments, please reach out to me on [Twitter / X](https://twitter.com/EphraimDuncan_) (DM open) or [Discord](https://documen.so/discord).
|
||||
|
||||
We're building an open-source alternative to DocuSign and welcome every contribution. Head over to the GitHub repository and [leave us a Star](https://github.com/documenso/documenso)!
|
||||
@ -1,49 +0,0 @@
|
||||
---
|
||||
title: Open Sourcing Documenso's Design
|
||||
description: It's day 1 of our first launch week. We are kicking it off by open sourcing Documenso's design system! Let's go..
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2023-09-25
|
||||
tags:
|
||||
- Design
|
||||
- Open Source
|
||||
- Community
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/designsystem.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="Documenso's Design System"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Documenso's Design System ✨
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; Our design system is OSS under MIT at [design.documenso.com](https://design.documenso.com)
|
||||
|
||||
Today, we are open sourcing our design system, lovingly crafted by [Thilo](https://twitter.com/thilokonzok). The system is public on Figma and will be available at [design.documenso.com](https://design.documenso.com) from here on out.
|
||||
We are publishing it under the MIT License so everyone can share, remix, and use it as it helps them most.
|
||||
|
||||
We chose to start our first launch week with a design topic to emphasize the role design will play in Documenso's company and community culture. As it is historically difficult to bring together open-source software with great design, this is our first step towards encouraging a more design-driven COSS (Commercial Open Source) movement.
|
||||
|
||||
## Designers Welcome
|
||||
|
||||
We added a designer role in our Discord to create a space for designers to explore and discuss design-related topics of Documenso and signing in general. In the future, we want to foster more coding contributions and start a design culture around the product. As it is much more difficult to incorporate design contributions, we have yet to find a clear plan of what that will look like. I would like to see contributions around stuff we are NOT working on. Designs in that area can inspire and start discussions without the complexities of implementing them immediately — a free-thinking space around everything Documenso. Having a free mandate to design without restriction can create many exciting ideas. Some Ideas worth exploring:
|
||||
|
||||
## Areas for design contributions
|
||||
|
||||
- Explorations of exciting aspects of signing and document handling:
|
||||
- What does signing look like when we no longer have skeuomorphic signatures?
|
||||
- What is signing if we move beyond paper-inspired documents?
|
||||
- What would the government process look like using Documenso?
|
||||
- Solutions Concepts for features further down the roadmap, e.g., Widgets in websites
|
||||
|
||||
These are fascinating ideas for explorative design. They won't be built 1:1 but shape how we think about signing and where it can go, which is even more critical. If you are interested in product design, you are invited to join our [Discord](https://documen.so/discord) and discuss the future of signing design or the future of Documenso's design system. Also let me know what you think on [X (formerly Twitter)](https://x.com/eltimuro).
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,67 +0,0 @@
|
||||
---
|
||||
title: The Early Adopters Plan
|
||||
description: Launch Week Day 4 and we are still early! Early enough for you to get a sweet deal for supporting Documenso's Mission. Join the movement and get a shiny early adopter account in the process.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2023-09-28
|
||||
tags:
|
||||
- Paid Plan
|
||||
- Metrics
|
||||
- Open Startup
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/early.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="XKCD: Bug"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
"Being early is, uh, good." -Unknown
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
> 🔔 UPDATE: We launched <a href="https://documen.so/day1" target="_blank">teams</a> and the early adopters plan will be replaced by the new teams pricing as soon as all availible early adopters seats are filled.
|
||||
|
||||
## Community-Driven Development
|
||||
|
||||
As we ramp up hiring and development speed for Documenso, I want to discuss how we plan to build its core version.
|
||||
As we want to be a highly community-driven product, we want to capture the thoughts and ideas of said community in two ways:
|
||||
|
||||
1. Everything we plan (i.e. documen.so/roadmap) and build (i.e. documen.so/repo) is public and open to comments and suggestions from everyone by design. We plan to have discussions, streams, and articles showcasing what we're up to, encouraging feedback and iterations on our plans.
|
||||
2. We're looking for 100 die-hard early adopters to get more deep hands-on feedback. If you want to be among the first to use and help shape Documenso, we have a special offer for you:
|
||||
|
||||
## The Early Adopter Plan
|
||||
|
||||
- All first 100 signups are entitled to the early adopter plan.
|
||||
- The plan includes everything we build in the next 12 months and unlimited<sup>1</sup> signatures
|
||||
- This plan is priced at $30/mo.
|
||||
- No matter what we add, the price is guaranteed for life as a thank you for supporting Documenso's mission<sup>2</sup>. And we plan to add a lot.
|
||||
- This also includes unlimited users<sup>3</sup> as part of the upcoming support for teams.
|
||||
- If you already claimed an early adopter account in the past and canceled, we are happy to reactivate your account with the early adopter pricing. Reach out to support@documenso.com
|
||||
|
||||
## Being an Early Adopter
|
||||
|
||||
Being eligible for the early adopter plan has no formal requirements like giving feedback or being active in the community. In good faith, we assume you sign the Documenso Supporter Pledge to be part of this. And if you want to use the newest version quietly, that's fine, too. Everything the die-hard community brings up will be carefully considered and prioritized <sup>4</sup>. Also, there will obviously be limited edition merch available for the first 100.
|
||||
Documenso currently runs the community reviewed 0.9.1 version. Getting from here to the globally loved and adopted signing tool we all deserve will take a lot of work, and we want you on board to help us create it. Join us in shaping the future of open signing and having fun doing it. [Malfunction Mania](https://documenso.com/blog/malfunction-mania) and releasing 1.0 will go a long way.
|
||||
|
||||
## Extending our open metrics
|
||||
|
||||
As part of our ongoing effort to be open and transparent in our doing, we are adding "Early Adopters" to our [/open page](https://documenso.com/open) page. After we exceed the early adopter slots, this metric will transition to "Customers". When no more early adopter seats can be claimed, the early adopter plan will transition to a standard paid plan. It will still be priced at $30/mo., but will no longer include upcoming features or unlimited seats.
|
||||
|
||||
If you have any questions or comments, please reach out on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord).
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
|
||||
\
|
||||
[1] Excluding signatures, we have to pay for i.e. third-party QES
|
||||
|
||||
[2] The Documenso Manifest
|
||||
|
||||
[3] Within reason. If you are unsure what that means, feel free to contact hi@documenso.com. But it should be fine if you don't plan to onboard a huge enterprise.
|
||||
|
||||
[4] We won't be able to build everything everyone asks for. But we firmly plan to listen and build in a way everyone's requirements are met as well as possible.
|
||||
@ -1,28 +0,0 @@
|
||||
---
|
||||
title: Jan 10th Email Provider Security Incident
|
||||
description: On January 10th, 2022, we were notified by our email provider that they had experienced a security incident.
|
||||
authorName: 'Lucas Smith'
|
||||
authorImage: '/blog/blog-author-lucas.png'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-01-17
|
||||
tags:
|
||||
- Security
|
||||
---
|
||||
|
||||
On January 10th, 2024 we were notified by our email provider that a security incident had occurred. This security incident which had started on January 7th led to a bad actor obtaining access to their database which contains ours and other customer’s data.
|
||||
|
||||
We understand that during this security incident the following has been accessed:
|
||||
|
||||
- Email addresses.
|
||||
- Metadata on emails sent excluding the email body.
|
||||
|
||||
While the incident is unfortunate we are pleased with the remediation and the processes that our email provider has put in place to help avoid this kind of situation in the future. Since the incident, our provider has rectified the issue and has engaged a security company to conduct an exhaustive investigation and to help improve their security posture moving forward.
|
||||
|
||||
We remain steadfast in our commitment to our current email provider, and will not be taking any further action with relation to changing providers.
|
||||
|
||||
We are now working with our legal counsel to ensure that we provide the appropriate notice to all our customers in each jurisdiction. If you have any further questions on this incident please feel free to contact our support team at [support@documenso.com](mailto:support@documenso.com).
|
||||
|
||||
We appreciate your ongoing support in this matter.
|
||||
|
||||
You can read more on the incident on our providers blog post below:
|
||||
[https://resend.com/blog/incident-report-for-january-10-2024](https://resend.com/blog/incident-report-for-january-10-2024)
|
||||
@ -1,86 +0,0 @@
|
||||
---
|
||||
title: Go Fork Yourself
|
||||
description: Curious about our take on open-source and code forking? Discover why we see forking not as a threat but as a vital part of the Open Source ecosystem.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-10-03
|
||||
tags:
|
||||
- Culture
|
||||
- Open Startup
|
||||
- Open Source
|
||||
---
|
||||
|
||||
> TLDR; At Documenso, we see OSS as co-owned by all. Forking—collaborative or not—is part of the open-source spirit.
|
||||
|
||||
## Freedom vs. Ownership
|
||||
|
||||
Recently, there has been a lot of debate on the subject of forks and the usage of OSS IP (Open Source Software Intellectual Property). While I mostly aim to stay out of these controversies (as there is no “winning”), I wanted to take this opportunity to share my views on IP and forking culture here at Documenso. I don’t presume this is the ideal path, but for me, it’s the only path that makes sense.
|
||||
|
||||
What these issues show foremost, in my opinion, is that the concept of Open Source is still evolving. I have heard many say, “Open Source is clearly defined” and that there is no ambiguity anymore. That may be true on the legal side, but there are vast differences in how these rules are interpreted and lived out. Here are a few questions to illustrate the point:
|
||||
|
||||
1. Is it okay to use an open-source project without ever giving back?
|
||||
2. Is it okay to fork (some might say copy) an OSS product and build something on top of it?
|
||||
3. Are we morally obliged to fight those who provide different answers to these questions than we do?
|
||||
|
||||
## Embracing Forks and Collaboration
|
||||
|
||||
Since starting Documenso, I’ve thought a lot about what it actually means to be Open Source for us. So far, it has been about openness in working with everyone, from contributors to customers and sharing our work transparently. For this, we have been richly rewarded with attention and reach. This collaborative give-and-take is what people commonly associate with being Open Source, and it seems ideal.
|
||||
|
||||
Yet, there are the questions mentioned above. And while these may be contentious, my take is straightforward:
|
||||
|
||||
1. Yes.
|
||||
2. Yes.
|
||||
3. No.
|
||||
|
||||
I say this because, to me, the principles of Open Source are rooted in freedom and collaboration. That means allowing others to use, improve, or even compete with what you’ve built without feeling possessive over the code. The beauty of Open Source lies in its openness—its ability to be forked, reused, and adapted by anyone.
|
||||
|
||||
You may answer these questions differently for your own reasons. One thing I’ve found lacking in the discourse is the fact that Open Source is still being treated as socially proprietary. If it’s under an open-source license, you can fork it and try to improve upon the original, and there’s nothing wrong with that. The same is true for closed-source startups. Yet in Open Source, there’s a notion that it’s somehow “dirty,” even though the license explicitly allows it.
|
||||
|
||||
## Forking in Action: Real-World Examples
|
||||
|
||||
When the team behind **Node.js** disagreed with its governance and pace of development, they forked the project to create **io.js**. This wasn’t seen as dirty but as a necessary push for change. In fact, the fork resulted in positive changes—better community governance and faster development—which eventually led to the merge of the two projects under the Node.js Foundation. It shows that forking can be a catalyst for improvement, not just competition.
|
||||
|
||||
## The Misconception of “Exploitative” Usage
|
||||
|
||||
However, sometimes forks don’t merge back but still bring positive change. A good example is **Jenkins**, which was forked from **Hudson** over disagreements in governance after Oracle acquired Sun Microsystems. Jenkins quickly overtook Hudson in terms of community support, development, and innovation. Rather than being seen as a hostile move, the fork enabled Jenkins to become a thriving project, better aligned with the open-source ethos of collaboration and transparency. It emphasizes that forking isn’t inherently exploitative; it can simply be a way to realize a project’s full potential.
|
||||
|
||||
And then there’s **MariaDB**, a fork of **MySQL**. After Oracle acquired MySQL, many in the community feared the project’s open-source nature could be compromised. The fork preserved its spirit, and MariaDB has since grown to become a popular and thriving database. It’s a reminder that sometimes, forking is not just acceptable—it’s necessary to uphold the values and freedoms of open-source software.
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/owncode.jpeg"
|
||||
width="1200"
|
||||
height="675"
|
||||
alt="Meme: If everyone owns the code, no one does."
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Funny Meme to drive the point home.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
My view is that the code is not “your” code, just as Documenso’s code is not “our” code. It’s been co-owned by the world ever since we published the repo under AGPL V3. That is the whole point. It’s finally not owned by anyone (cue the “everyone/no one” meme). Open Source is for everyone, even competitors. Yet, we are still treating the licenses as extensions of the old, proprietary world and defending perceived injustices based on that model.
|
||||
|
||||
> Side Note: Full compliance with all license and other legal rules is a given here.
|
||||
|
||||
## Documenso’s Approach: Co-Ownership and Community
|
||||
|
||||
So, if you want to fork Documenso and build a business on it, you can. Whether that’s a cool thing to do is another matter. Whether you do a better job than us is also another matter (you won’t). But if you do, I’ll be the first to join. But why not join us from the start since you already have the upside? We exist because we believe this to be the best way forward—not because we force it.
|
||||
|
||||
## The Bigger Picture: Open-Source as Progress
|
||||
|
||||
I’ve also thought a lot about question #3. I understand the impulse to fight anyone who doesn’t appreciate this collaborative approach, but there is no part of this model that backs that up. You are free to “exploit” as long as it’s in a way that adds value. The fallacy is in considering someone else using the OSS part for their business as treason, which it’s not. It’s the whole point.
|
||||
|
||||
While some might say this is theoretical and that reality is different, this is the version of Open Source on which we are building Documenso. The point here is that OSS companies must be resilient to handle forking and competition; without this resilience, an open source driven economy can’t thrive. The focus on freedom and collaboration means being prepared for forks and challenges as part of the growth, not as threats.
|
||||
|
||||
Of course, all of this applies to Documenso, the OSS project, not Documenso Inc., the company, which is very much a privately owned, for-profit entity. However, since the goal is to scale Documenso to the entire world, there is plenty of room to see everyone as co-owners of the Open Source project rather than as competitors. In the end, Open Source is about progress through freedom. If you don’t like how we run things, go fork yourself and hold us accountable. We don’t own this; we just happened to start it.
|
||||
|
||||
> Since this article is open source as well, you are free to fork it and change it here: [https://documen.so/repo](https://documen.so/repo)
|
||||
|
||||
If you have any questions or comments, please reach out on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord).
|
||||
|
||||
Thinking about switching to a modern signing platform? Reach out anytime: [https://documen.so/sales](https://documen.so/sales)
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,103 +0,0 @@
|
||||
---
|
||||
title: How Documenso Enhances Contract Management for Freelancers, Helping Them Close More Clients Efficiently
|
||||
description: Making it easy for the customer to sign the contract after they say yes is critical. Let take a look how Documenso can help.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-06-20
|
||||
tags:
|
||||
- Freelancer
|
||||
- Proposal
|
||||
- Productivity
|
||||
---
|
||||
|
||||
## Yes to Yes
|
||||
|
||||
> [Check out Part 1](https://documen.so/freelance-proposal) to learn about signing freelance proposals with Documenso and getting your first yes
|
||||
|
||||
A basic rule of sales is going from "yes to yes”. Outlining the main points of working together in a proposal is a good way to get to your first yes since it reduces details and focuses on the main points of the work at hand. After being on the same page about the work and getting the first yes, it's time to draw up a formal contract. While agreeing to the proposal has some weight as well, the legal contract formalizes the commitments of both sides in an enforceable way. Having clear legal terms on payments, unexpected cases, and even dissolving the partnership helps both parties to feel assured about what to expect.
|
||||
|
||||
### **Digital Signatures for the Win**
|
||||
|
||||
Digitally signing documents accelerates contract closure, enhancing both speed and security. Parties can review and sign documents within minutes, eliminating the days required for manual signatures or even weeks with traditional mail. Beyond these efficiency gains, digital signatures boost trust by making the process secure and auditable. Once signed, digital documents are immutable, and every step is logged.
|
||||
|
||||
Documenso simplifies this process, allowing you to send contracts effortlessly. As an open-source solution, our product's integrity and security are verifiable by anyone, which is why thousands of users rely on Documenso for their signing needs. Discover more at [https://documen.so/open](https://documen.so/open).
|
||||
|
||||
## Preparing the Contract
|
||||
|
||||
As a freelancer, obtaining a contract template ensures you have a standardized and professional agreement ready for new clients, helping to protect your interests and clarify project terms. While there are many good templates out there, be sure to verify that they fit your case since contracts are often very specific to a certain case. Always consider having your contract checked by a legal professional if it's a high-value transaction.
|
||||
|
||||
Here is a quick checklist of what your contract should include:
|
||||
|
||||
### Checklist
|
||||
|
||||
- Names and Addresses of you and your client
|
||||
- Scope of Work to be performed, deadlines and deliverables
|
||||
- Payment Terms, Payment Schedules, and Pricing
|
||||
- A clear timeline
|
||||
- Provisions for unexpected extra work
|
||||
- Intellectual Property Rights Provisions
|
||||
- Confidentiality and Non-Disclosure Agreements, if needed
|
||||
- Termination Clauses: Condition and terms when the contract can be terminated, including notice period and compensation
|
||||
- Indemnity and Liability
|
||||
- Dispute Resolution
|
||||
- Provisions ensuring changes can only be made in writing
|
||||
- Completeness Agreement: Both parties state this is the full extent of the agreement
|
||||
- Severability Clause ensuring minor errors will not endanger the whole contract
|
||||
- The signees with name, role, and date
|
||||
|
||||
## Getting the Signature
|
||||
|
||||
Once you have your contract ready, you can upload it and add recipients and signature fields. To add a more personal touch, consider adding a personal message to the signature request.
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/l1.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="Manually Copy Signature Link by Hovering of the Recipient"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Copy recipient links to send them for a personal touch manually.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
You can also copy the link for each recipient after sending it and send it via another channel e.g. WhatsApp with a personal message. To further customize the experience, you can define a redirect when your customer signs the contract to redirect them to a Cal.com Link to get started, a Thank You Page, or a Form.
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/l2.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="Redirect Link in Advanced Settings"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Redirect after Signing for a more personal experience.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
The more you add to the workflow, the more important it is to keep up to date with the process. Using Zapier, you can add a variety of notifications, from email to Discord messages, to keep a good overview and respond quickly. It's not just about getting the signatures; it's about creating the workflow that provides the best experience for you and your customers.
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/l3.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="Zapier Documenso Discord Integration"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Trigger any kind of notification with[Zapier](https://documen.so/zapier)
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
### Conclusion
|
||||
|
||||
Sending a contract to clients using Documenso makes the process fast and easy. Seeing if your contract was signed or even read helps you understand where you are in the process. You can use the [Documenso Free Plan](https://app.documenso.com/signup?utm_source=blog-freelancer-contract) to send 5 contracts per month. Digital signing in 2024 is the best practice for professionals seeking the most efficient way to get business done.
|
||||
|
||||
Let us know what you think and what we can improve. Connect with us on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord) if you have any questions or comments! We're always here and would love to hear from you :)
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,76 +0,0 @@
|
||||
---
|
||||
title: How Documenso Helps Freelancers Close More Clients Efficiently
|
||||
description: Reducing friction when sending proposals is critical to closing new clients. By using Documenso, freelancers can save time, enhance client interactions, and ultimately close more deals efficiently.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-06-14
|
||||
tags:
|
||||
- Freelancer
|
||||
- Proposal
|
||||
- Productivity
|
||||
---
|
||||
|
||||
Getting new clients, or maybe even your first client, to sign with you is at the very core of freelance work. Whether you develop software, create designs, or market products, it all starts with a signature from you and your future customer. Closing a customer usually means agreeing on a proposal first and then signing a formal agreement afterward. Signing proposals and contracts is fast, easy, and painless with Documenso, so let's take a look.
|
||||
|
||||
## Understanding Proposal and Contracts
|
||||
|
||||
### 1. Initial Proposal
|
||||
|
||||
> Agreeing on what needs to be done and terms for payment
|
||||
|
||||
A proposal will include the scope of the work (what does the customer want done?), desired deliverables (documents, code, features, videos, etc.), timelines, payment terms (one-time, monthly, per hour), and prices (e.g. $60/ hour, $5k one-time). A proposal is important for both sides to be clear about the goal and the terms that apply. Customers usually decide based on the proposal if your offer is what they want.
|
||||
|
||||
### 2. Formal Contract
|
||||
|
||||
> After the client signs the proposal, a contract can be signed, formalizing the agreement and adding detailed legal terms.
|
||||
|
||||
Once the terms are agreed upon, a more formal document should specify the terms of working together, especially legal details such as confidentiality, indemnification, governing law, etc. The contract provides clarity on legal details for both sides and formalizes their claims.
|
||||
|
||||
Sending one or even multiple documents to a potential client and having them send them back signed (in the worst case, they send it via actual mail) is time-consuming for both sides. It also introduces friction at a time when making it as easy as possible for your potential client to say yes should be your number one goal.
|
||||
|
||||
### **Digital Signatures for the Win**
|
||||
|
||||
Signing documents digitally makes closing proposals and contracts faster and more secure. Each party can review and sign the documents in minutes instead of days (inserting the signatures manually via PDF editor) or even weeks (using conventional mail). Apart from the efficiency gains, signing digitally also increases trust by making the process more secure and auditable. Digitally signed documents can’t be changed after the fact, and every step of the process is logged.
|
||||
|
||||
Documenso lets you reap these benefits by sending proposals and contracts with minimal effort. Being open source, the whole world can verify our product and how we deliver on these promises, which is why thousands of users already trust Documenso for their signing needs: [https://documen.so/open](https://documen.so/open).
|
||||
|
||||
## Preparing the Proposal
|
||||
|
||||
If you already have a proposal template, create a new version for your client and export it to PDF. If your tool doesn’t support that, your system's “PDF printer” lets you create a PDF from almost any tool by using the print function. If you do not have a template yet, you can find a lot of content and guides on the matter through a quick Google search. Here is a quick checklist of what your proposal should cover:
|
||||
|
||||
- A clear and concise title
|
||||
- Your contact information
|
||||
- Date of the proposal/ validity period
|
||||
- Experience, qualifications, and prior relevant projects
|
||||
- A summary of the project
|
||||
- A detailed description of the project
|
||||
- Goals, outcomes, and deliverables
|
||||
- Tasks and activities to achieve the goals and outcomes
|
||||
- A timeline with milestones and deadlines
|
||||
- Pricing terms and payment schedule
|
||||
- Summary of major terms for the coming contract
|
||||
|
||||
## Sending the Proposal
|
||||
|
||||
If you don’t have a Documenso Account yet, you can [create one for free](https://documen.so/signup?utm_source=blog-freelancer-proposal). Once you sign up, you can upload your proposal PDF by simply dragging it into the upload area. Add your potential client as a recipient, add a signature field, and you are done! You can track the status of your proposal simply by clicking the Document in the overview. Documenso will also notify you once the proposal is signed.
|
||||
|
||||
<video
|
||||
id="vid"
|
||||
width="100%"
|
||||
src="https://github.com/documenso/design/assets/1309312/050a1501-b562-4b1e-97b5-a46fc0da8246"
|
||||
autoPlay
|
||||
loop
|
||||
muted
|
||||
></video>
|
||||
|
||||
### Conclusion
|
||||
|
||||
Sending a proposal to potential clients using Documenso makes getting to the first “yes” fast and easy. Seeing if your proposal was signed or even read helps you to get a feel for where you are in the process. You can use the [Documenso Free Plan](https://app.documenso.com/signup?utm_source=blog-freelancer-proposal) to send 5 proposals per month. Digital Signing in 2024 is the best practice for all professionals looking for the most efficient way to get business done.
|
||||
|
||||
> [Check out Part 2](https://documen.so/freelance-contract) to learn about signing freelance contracts with Documenso.
|
||||
|
||||
Let us know what you think and what we can improve. Which field types are you missing? Connect with us on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord) if you have any questions or comments! We're always here and would love to hear from you :)
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,599 +0,0 @@
|
||||
---
|
||||
title: 'Enhancing Document Signing: Introducing 5 New Advanced Fields'
|
||||
description: "Explore Documenso's new advanced signing fields, including improved text fields, numbers, radio buttons, checkboxes, and dropdowns. Learn about the development challenges we overcame and how these additions provide greater flexibility for document signing."
|
||||
authorName: 'Catalin Pit'
|
||||
authorImage: '/blog/blog-author-catalin.webp'
|
||||
authorRole: 'I like to code and write'
|
||||
date: 2024-08-09
|
||||
tags:
|
||||
- Signing fields
|
||||
- Development
|
||||
---
|
||||
|
||||
Until recently, Documenso provided a set of 5 fields for document signing: signature, email, name, date, and a text field for additional information. While these fields covered the basic requirements for document signing, we recognized the need for more flexibility and variety.
|
||||
|
||||
As a result, we've decided to introduce several additional fields, such as:
|
||||
|
||||
- _(an improved)_ Text field
|
||||
- Number field
|
||||
- Radio field
|
||||
- Checkbox field
|
||||
- Dropdown/Select field
|
||||
|
||||
These new fields bring more flexibility and variety to Documenso. As the document owner, they allow you to gather more specific or extra information from the signers.
|
||||
|
||||
## New Fields Introduction
|
||||
|
||||
Let's take a closer look at each new field type.
|
||||
|
||||
### Text Field
|
||||
|
||||
While the text field was previously available, it could not be configured. It was a simple input box where signers could enter a single line of text.
|
||||
|
||||
The image illustrates the old text field in the document editor.
|
||||
|
||||

|
||||
|
||||
The revamped text field now offers a range of configuration options, allowing you to:
|
||||
|
||||
- Add a label, placeholder, default text, and character limit
|
||||
- Set the field as required or read-only
|
||||
|
||||

|
||||
|
||||
On the signing side, the field remained mostly the same visually. The only thing that changed is the functionality, which needs to take into consideration the validation rules. For example, if the field is required, the signer must enter a value to sign it. Or, if the field has a character limit, the value entered by the signer shouldn't exceed the limit.
|
||||
|
||||
The image below illustrates four different text fields with various configurations.
|
||||
|
||||

|
||||
|
||||
The first text field has no default value ("Add text") or configuration. You can sign the field by entering any text.
|
||||
|
||||

|
||||
|
||||
The second text field, "label-1"/"text-1", has the following configurations:
|
||||
|
||||
- Label
|
||||
- Placeholder
|
||||
- Default text
|
||||
- Character limit
|
||||
|
||||
Since there is a default value, the field auto-signs with that value. However, you can re-sign the field with a new value that doesn't exceed the character limit.
|
||||
|
||||

|
||||
|
||||
The third field, "label-2"/"text-2", has the same configurations as the second one, with one addition - the `required` option is checked. When the field is marked as `required`, you must sign it before completing the document.
|
||||
|
||||
Apart from that, it works like the second field.
|
||||
|
||||

|
||||
|
||||
The fourth field, "label-3"/"text-3", has the same configurations as the second one, with one addition—`read-only` is checked. That means the field auto-signs with the default value, and you cannot modify it.
|
||||
|
||||
#### Unsigned Fields
|
||||
|
||||
You can unsign a field to change the value and sign it again. The unsigned state of the field varies depending on its configuration:
|
||||
|
||||
- If the field has a label, it displays it instead of "Add text" when unsigned.
|
||||
- If the field has a default value, the default value will be shown when unsigned.
|
||||
- If the field has both a label and a default value, the label will take precedence and be displayed when unsigned.
|
||||
|
||||
The image below shows the unsigned state of the text fields.
|
||||
|
||||

|
||||
|
||||
The only exception is the fourth, read-only field, which cannot be unsigned or modified.
|
||||
|
||||
### Number Field
|
||||
|
||||
We also introduced a new "Number" field for inserting and signing documents with numeric values. This field helps collect quantities, measurements, and other data best represented as numbers.
|
||||
|
||||

|
||||
|
||||
The "Number" field offers a range of configuration options, which allows you to:
|
||||
|
||||
- Set a label, placeholder and default value
|
||||
- Specify the number format
|
||||
- Mark the field as _required_ or _read-only_
|
||||
- Specify minimum and maximum values
|
||||
|
||||
The Number field looks and works similarly to the Text field. The difference is that it accepts only numeric values and has 2 additional configurations: the number format and the minimum and maximum values.
|
||||
|
||||
### Radio Field
|
||||
|
||||
Radio buttons allow signers to select a single option from a pre-defined list the document owner sets.
|
||||
|
||||
Before sending the document for signing, you must add at least one radio option, which can contain a string or an empty value and can be checked or unchecked. However, it's important to note that only one option can be checked at a time.
|
||||
|
||||
When it comes to field configuration, you can mark the field as _required_ or _read-only_.
|
||||
|
||||

|
||||
|
||||
The image below shows what the signer sees after the document is sent for signing.
|
||||
|
||||

|
||||
|
||||
Note: The image is modified to display both the unsigned and signed states of the field.
|
||||
|
||||
Since the field has a preselected option (option `radio-val-2-checked`), it will automatically sign with that value and appear like the field marked with the number 1.
|
||||
|
||||
If the field is not read-only, the signer can:
|
||||
|
||||
- Unsign the field and choose another option by clicking on it.
|
||||
- Re-sign with the default value by refreshing the page when the field is unsigned.
|
||||
|
||||
However, if the field is marked as read-only, the signer cannot modify the preselected value.
|
||||
|
||||
### Dropdown/Select Field
|
||||
|
||||
We have also introduced a new "Dropdown/Select" field that allows signers to pick an option from a pre-defined list of choices. This field type is ideal for scenarios with limited valid options, such as selecting a country, state, or category.
|
||||
|
||||
When setting up a "Dropdown/Select" field, you can:
|
||||
|
||||
- Add multiple options
|
||||
- Mark the field as _required_ or _read-only_
|
||||
- Pick a default option from the list of choices
|
||||
|
||||

|
||||
|
||||
On the signing page, the "Dropdown/Select" field appears as shown below:
|
||||
|
||||

|
||||
|
||||
Here's how the "Dropdown/Select" field works:
|
||||
|
||||
- If no default value is set, the field will not auto-sign. The signer must click on the field and select an option from the dropdown list to sign it.
|
||||
- After signing, the field displays the selected value, similar to a signed text field.
|
||||
- If the field is marked as required, signers must select a value before completing the signing process.
|
||||
- If the field is marked as read-only, signers can view the selected value but cannot modify it.
|
||||
|
||||
### Checkbox Field
|
||||
|
||||
The last field introduced is the "Checkbox" field, which allows signers to select multiple options from a pre-defined list. This field is helpful for scenarios where signers need to choose multiple items or agree to several terms and conditions, for example.
|
||||
|
||||
Before sending the document for signing, you must add at least one checkbox option. This option can contain a string or an empty value and can be checked or unchecked. Unlike the "Radio" field, the "Checkbox" field can have multiple checked options.
|
||||
|
||||
Like other fields, you can mark the "Checkbox" as _required_ or _read-only_. In addition to that, it also has a validation field, and you can specify how many checkboxes the signer should sign:
|
||||
|
||||
- Select at least X _(a number from 1 to 10)_
|
||||
- Select at most X _(a number from 1 to 10)_
|
||||
- Select exactly X _(a number from 1 to 10)_
|
||||
|
||||

|
||||
|
||||
When a signer receives the document, they will see the "Checkbox" field as shown below:
|
||||
|
||||

|
||||
|
||||
The image illustrates both field states - signed and un-signed. In this example, the 'Checkbox' field has two options checked by default, so it auto-signs.
|
||||
|
||||
The field marked '1' appears when the signer visits the page for the first time or when the user refreshes the page and no option is selected. The field marked '2' displays the cleared state, where all choices have been deselected. This shows how the field looks when a user clears all selections.
|
||||
|
||||
In this example, no validation rule has been set, allowing the signer to select any options. However, when a validation rule is applied, signers must meet the specified criteria to complete the signing process.
|
||||
|
||||
## Development Challenges
|
||||
|
||||
The introduction of these new fields wasn't without its challenges. The main challenges were:
|
||||
|
||||
- Deciding how to store the new information for the fields in the database
|
||||
- Differentiation of recipients using colours
|
||||
- Storing the advanced settings for the local fields on the frontend
|
||||
- Implementing the Checkbox and Radio fields
|
||||
|
||||
### 1st Challenge: Store New Field Information
|
||||
|
||||
The first challenge was deciding how to store the extra information for each new field in the database. Each field has unique properties, with only `required` and `read-only` shared by all the advanced fields.
|
||||
|
||||
The existing `Field` model in the database looks like this:
|
||||
|
||||
```js
|
||||
model Field {
|
||||
id Int @id @default(autoincrement())
|
||||
secondaryId String @unique @default(cuid())
|
||||
documentId Int?
|
||||
templateId Int?
|
||||
recipientId Int
|
||||
type FieldType
|
||||
page Int
|
||||
positionX Decimal @default(0)
|
||||
positionY Decimal @default(0)
|
||||
width Decimal @default(-1)
|
||||
height Decimal @default(-1)
|
||||
customText String
|
||||
inserted Boolean
|
||||
Document Document? @relation(fields: [documentId], references: [id], onDelete: Cascade)
|
||||
Template Template? @relation(fields: [templateId], references: [id], onDelete: Cascade)
|
||||
Recipient Recipient @relation(fields: [recipientId], references: [id], onDelete: Cascade)
|
||||
Signature Signature?
|
||||
|
||||
@@index([documentId])
|
||||
@@index([templateId])
|
||||
@@index([recipientId])
|
||||
}
|
||||
```
|
||||
|
||||
Initially, we considered creating a new `FieldMeta` table with columns for each field property. However, this approach has 2 issues.
|
||||
|
||||
First, the advanced fields only share two common properties: `required` and `read-only`. Since all the other properties are unique to each field type, this would result in many nullable columns in the `FieldMeta` model.
|
||||
|
||||
Secondly, creating a new database table with columns for each field property and the associated relationships would increase the database complexity.
|
||||
|
||||
As a result, we decided to look for another solution that would better work with our use case.
|
||||
|
||||
### Solution: JSONB Field
|
||||
|
||||
Since the advanced settings data is unique to each field, we decided to store it as JSON using PostgreSQL's `JSONB` data type. We added a new optional `fieldMeta` property of type `JSONB` to the Field model:
|
||||
|
||||
```js
|
||||
model Field {
|
||||
id Int @id @default(autoincrement())
|
||||
secondaryId String @unique @default(cuid())
|
||||
documentId Int?
|
||||
templateId Int?
|
||||
recipientId Int
|
||||
type FieldType
|
||||
page Int
|
||||
positionX Decimal @default(0)
|
||||
positionY Decimal @default(0)
|
||||
width Decimal @default(-1)
|
||||
height Decimal @default(-1)
|
||||
customText String
|
||||
inserted Boolean
|
||||
Document Document? @relation(fields: [documentId], references: [id], onDelete: Cascade)
|
||||
Template Template? @relation(fields: [templateId], references: [id], onDelete: Cascade)
|
||||
Recipient Recipient @relation(fields: [recipientId], references: [id], onDelete: Cascade)
|
||||
Signature Signature?
|
||||
fieldMeta Json? <<<<<----- added this
|
||||
|
||||
@@index([documentId])
|
||||
@@index([templateId])
|
||||
@@index([recipientId])
|
||||
}
|
||||
```
|
||||
|
||||
This approach allows us to store each field's settings as a JSON object. We use Zod schemas to parse and validate the field metadata when reading from or writing to the database to ensure data integrity.
|
||||
|
||||
This approach has several benefits:
|
||||
|
||||
- **Consistency**: The application uses the same Zod schema to retrieve and insert data into the database. That means the data is consistent throughout the app.
|
||||
- **Type safety**: By parsing the data with Zod, we can guarantee that the data matches the expected types and structure. We can also use Zod's `infer` utility to enable strong typing and autocompletion.
|
||||
- **Better error handling**: Zod provides thorough error messages indicating which part of the data is invalid. That makes it easier & faster to debug and fix issues.
|
||||
- **Maintainability**: Reusing the same Zod schema for retrieving and inserting data into the database makes the data structure easier to maintain.
|
||||
|
||||
However, using `JSONB` also has drawbacks like data querying. Since the data is stored as JSON (more specifically, in binary format), complex queries can be less efficient compared to querying normalized relational data. On top of that, querying data requires specific operators and functions, such as `->`, `->>`, `@>`, and `?`. This makes the querying more verbose and less intuitive, and hence, it requires more finesse.
|
||||
|
||||
Another drawback is the storage overhead. `JSONB` data is stored in a binary format, which can result in some storage overhead compared to normalized relational data. In cases where the JSON data is large or contains a lot of redundant information, the storage overhead can be significant.
|
||||
|
||||
Despite these drawbacks, the `JSONB` type suits our use case, as the field meta information is relatively small and doesn't require complex querying. The flexibility of `JSONB` matches the dynamic nature of the fieldMeta field.
|
||||
|
||||
> Postgres provides 2 fields for storing JSON data — `json` and `jsonb`. For more information, you can [check out the documentation](https://www.postgresql.org/docs/current/datatype-json.html).
|
||||
|
||||
### 2nd Challenge: Storing Fields' Advanced Settings on Frontend
|
||||
|
||||
The next challenge was finding the best way to store the advanced field settings entered by users.
|
||||
|
||||
Currently, the app only saves the fields and associated settings to the database when the user moves to the next step.
|
||||
|
||||

|
||||
|
||||
The fields are stored locally until the user proceeds to the next step. This means all fields and their settings are lost when the user:
|
||||
|
||||
- Closes the advanced settings tab
|
||||
- Refreshes the page
|
||||
- Closes the tab
|
||||
- Navigates to the previous step
|
||||
|
||||
In the future, we plan to improve this flow and save the fields on blur, preserving user data even if they navigate away. However, until then, we needed a solution to save the advanced settings when the user closes the settings tab.
|
||||
|
||||
### Solution: Local Storage
|
||||
|
||||
Our temporary solution is to store the advanced settings in local storage, as the fields are only available locally. If the fields were saved in the database, we could store the advanced settings alongside them.
|
||||
|
||||

|
||||
|
||||
Since the fields are not saved in the database, we must persist the data until the user moves to the next step, at which point the data is saved to the database. Storing the data in local storage allows users to open, close, and configure various fields in the advanced settings tab without losing information.
|
||||
|
||||
When the user proceeds to the next step, the fields and their advanced settings are saved into the database, and the local storage is cleared.
|
||||
|
||||
We also recognized the dangers of saving data to local storage, as users could modify it and break the application. As a result, we have implemented extensive checks on both the backend and frontend, in addition to parsing and validating data with Zod.
|
||||
|
||||
However, this solution has limitations. The data is still lost when the user:
|
||||
|
||||
- Refreshes the page
|
||||
- Navigates to the previous step
|
||||
- Closes the browser
|
||||
|
||||
In these cases, the fields are wiped from the document. A future improvement to save fields to the database on blur will solve this issue.
|
||||
|
||||
### 3rd Challenge: Radio and Checkbox Fields
|
||||
|
||||
Implementing the Radio and Checkbox fields was challenging from both logical and design perspectives. Both fields can contain empty and non-empty values, and the Checkbox field allows users to select multiple empty/non-empty values.
|
||||
|
||||

|
||||
|
||||
The image above shows the Radio and Checkbox fields in the document editor. The Radio field on the left-hand side has 4 options, 1 of which is checked. The Checkbox field on the right-hand side has 4 options, 2 of which are checked.
|
||||
|
||||
The Radio field was easier to implement because users can only select one option, resulting in simpler logic. The signer clicks on an option to choose it, and the field auto-signs with that value. To change the selection, the user clicks another option, un-signing the field and re-signing it with the new value.
|
||||
|
||||
The Checkbox field was more challenging because:
|
||||
|
||||
- Signers can select multiple options simultaneously, resulting in the field containing multiple values.
|
||||
- It can have validation rules (e.g., selecting at least, at most, or exactly X options).
|
||||
- Users can check/uncheck options by clicking them or clear the field with a button.
|
||||
|
||||
These factors make the Checkbox field more complex and challenging to implement correctly.
|
||||
|
||||
### Solution
|
||||
|
||||
Instead of focusing on a specific solution, we'll discuss the general implementation and its most challenging aspects. I'll include a link to the complete implementation for each field so you can check it out.
|
||||
|
||||
**Radio Field**
|
||||
|
||||
The way signing works for the Radio field is to pull the data from the database and display the available options. If the field has a default value set by the document sender, it auto-signs with that value.
|
||||
|
||||
```ts
|
||||
...
|
||||
const values = parsedFieldMeta.values?.map((item) => ({
|
||||
...item,
|
||||
value: item.value.length > 0 ? item.value : `empty-value-${item.id}`,
|
||||
}));
|
||||
...
|
||||
const shouldAutoSignField =
|
||||
(!field.inserted && selectedOption) ||
|
||||
(!field.inserted && defaultValue) ||
|
||||
(!field.inserted && parsedFieldMeta.readOnly && defaultValue);
|
||||
...
|
||||
|
||||
useEffect(() => {
|
||||
if (shouldAutoSignField) {
|
||||
void executeActionAuthProcedure({
|
||||
onReauthFormSubmit: async (authOptions) => await onSign(authOptions),
|
||||
actionTarget: field.type,
|
||||
});
|
||||
}
|
||||
}, [selectedOption, field]);
|
||||
```
|
||||
|
||||
> You can see the complete implementation of the radio field in the [radio-field.tsx](<https://github.com/documenso/documenso/blob/main/apps/web/src/app/(signing)/sign/%5Btoken%5D/radio-field.tsx>) file.
|
||||
|
||||
If the field is not read-only and the user clicks on another option, the field un-signs and re-signs with the new value. Read-only fields cannot be modified.
|
||||
|
||||
The value is saved in the database whenever the field is signed, whether by auto-signing or user. Similarly, the value is removed from the database when the field is unsigned.
|
||||
|
||||
Since the Radio field can contain empty values, we map over the values and replace the empty ones with a unique string `empty-value-${item.id}`. This is because the empty string is not a valid value for the field, and we need to differentiate between empty and non-empty values.
|
||||
|
||||
**Checkbox Field**
|
||||
|
||||
The Checkbox field implementation is similar to the Radio field, with the main differences being:
|
||||
|
||||
- Checkbox fields can contain multiple values.
|
||||
- Checkbox fields have validation rules that need to be enforced.
|
||||
|
||||
```ts
|
||||
...
|
||||
const values = parsedFieldMeta.values?.map((item) => ({
|
||||
...item,
|
||||
value: item.value.length > 0 ? item.value : `empty-value-${item.id}`,
|
||||
}));
|
||||
|
||||
const [checkedValues, setCheckedValues] = useState(
|
||||
values
|
||||
?.map((item) =>
|
||||
item.checked ? (item.value.length > 0 ? item.value : `empty-value-${item.id}`) : '',
|
||||
)
|
||||
.filter(Boolean) || [],
|
||||
);
|
||||
...
|
||||
```
|
||||
|
||||
As with the Radio field, we map over the values and replace empty ones with a unique string. We also keep track of the checked values to display the field correctly and validate them against the validation rules.
|
||||
|
||||
```ts
|
||||
...
|
||||
const values = parsedFieldMeta.values?.map((item) => ({
|
||||
...item,
|
||||
value: item.value.length > 0 ? item.value : `empty-value-${item.id}`,
|
||||
}));
|
||||
|
||||
const [checkedValues, setCheckedValues] = useState(
|
||||
values
|
||||
?.map((item) =>
|
||||
item.checked ? (item.value.length > 0 ? item.value : `empty-value-${item.id}`) : '',
|
||||
)
|
||||
.filter(Boolean) || [],
|
||||
);
|
||||
|
||||
const checkboxValidationRule = parsedFieldMeta.validationRule;
|
||||
const checkboxValidationLength = parsedFieldMeta.validationLength;
|
||||
const validationSign = checkboxValidationSigns.find(
|
||||
(sign) => sign.label === checkboxValidationRule,
|
||||
);
|
||||
...
|
||||
```
|
||||
|
||||
Then, we retrieve the validation rule and length from the database and find the corresponding validation sign (e.g., ">=", "=", "\<=") based on the rule label. The `checkboxValidationSigns` array maps rule labels to their corresponding signs.
|
||||
|
||||
```ts
|
||||
export const checkboxValidationSigns = [
|
||||
{
|
||||
label: 'Select at least',
|
||||
value: '>=',
|
||||
},
|
||||
{
|
||||
label: 'Select exactly',
|
||||
value: '=',
|
||||
},
|
||||
{
|
||||
label: 'Select at most',
|
||||
value: '<=',
|
||||
},
|
||||
];
|
||||
```
|
||||
|
||||
We then check if the length condition is met based on the validation rule, sign, and length. If met, the user can proceed with signing the field. Otherwise, they need to select the correct number of options.
|
||||
|
||||
```ts
|
||||
...
|
||||
const values = parsedFieldMeta.values?.map((item) => ({
|
||||
...item,
|
||||
value: item.value.length > 0 ? item.value : `empty-value-${item.id}`,
|
||||
}));
|
||||
|
||||
const [checkedValues, setCheckedValues] = useState(
|
||||
values
|
||||
?.map((item) =>
|
||||
item.checked ? (item.value.length > 0 ? item.value : `empty-value-${item.id}`) : '',
|
||||
)
|
||||
.filter(Boolean) || [],
|
||||
);
|
||||
|
||||
const checkboxValidationRule = parsedFieldMeta.validationRule;
|
||||
const checkboxValidationLength = parsedFieldMeta.validationLength;
|
||||
const validationSign = checkboxValidationSigns.find(
|
||||
(sign) => sign.label === checkboxValidationRule,
|
||||
);
|
||||
|
||||
const isLengthConditionMet = useMemo(() => {
|
||||
if (!validationSign) return true;
|
||||
return (
|
||||
(validationSign.value === '>=' && checkedValues.length >= (checkboxValidationLength || 0)) ||
|
||||
(validationSign.value === '=' && checkedValues.length === (checkboxValidationLength || 0)) ||
|
||||
(validationSign.value === '<=' && checkedValues.length <= (checkboxValidationLength || 0))
|
||||
);
|
||||
}, [checkedValues, validationSign, checkboxValidationLength]);
|
||||
...
|
||||
```
|
||||
|
||||
In summary, the Checkbox field allows signers to select multiple options, with the field automatically signing based on these selections. Signers can un-sign the field by deselecting options or clearing all selections. The system enforces validation rules throughout this process, ensuring signers select the required number of options to sign the field successfully.
|
||||
|
||||
> You can see the complete implementation of the checkbox field in the [checkbox-field.tsx](<https://github.com/documenso/documenso/blob/main/apps/web/src/app/(signing)/sign/%5Btoken%5D/checkbox-field.tsx>) file.
|
||||
|
||||
### 4th Challenge: Recipients' Colors
|
||||
|
||||
Another challenge we faced was using colours to differentiate recipients. We needed to dynamically generate and reuse the same Tailwind classes across several components. However, TailwindCSS only includes the CSS classes used in the project, discarding unused ones from the final build. This resulted in colours not being applied to the components, as the classes were not used in the code.
|
||||
|
||||
The images below illustrate the recipients' colours in 2 different states.
|
||||
|
||||
In the first image, the "Signature" field on the right is in the active state (blue), triggered when the user clicks the field to drag it onto the document. The signature field on the left, placed on the document, is in the normal state.
|
||||
|
||||
The first image illustrates the "Signature" field in the active state, triggered when the user clicks on it.
|
||||
|
||||

|
||||
|
||||
The second image shows the "Signature" field in the normal state.
|
||||
|
||||

|
||||
|
||||
The document editor consists of various components (fields, recipients, etc.), meaning the same colours and code are reused across multiple components.
|
||||
|
||||
```ts
|
||||
export const combinedStyles = {
|
||||
'orange-500': {
|
||||
ringColor: 'ring-orange-500/30 ring-offset-orange-500',
|
||||
borderWithHover: 'border-orange-500 hover:border-orange-500',
|
||||
...,
|
||||
},
|
||||
'green-500': {
|
||||
ringColor: 'ring-green-500/30 ring-offset-green-500',
|
||||
borderWithHover: 'border-green-500 hover:border-green-500',
|
||||
...,
|
||||
},
|
||||
'blue-500': {
|
||||
ringColor: 'ring-blue-500/30 ring-offset-blue-500',
|
||||
borderWithHover: 'border-blue-500 hover:border-blue-500',
|
||||
...,
|
||||
'gray-500': {
|
||||
ringColor: 'ring-gray-500/30 ring-offset-gray-500',
|
||||
borderWithHover: 'border-gray-500 hover:border-gray-500',
|
||||
...,
|
||||
},
|
||||
...,
|
||||
};
|
||||
|
||||
export const MyComponent = () => {
|
||||
const selectedSignerStyles = useSelectedSignerStyles(selectedSigner, combinedStyles);
|
||||
|
||||
return (
|
||||
<div
|
||||
className={cn(
|
||||
selectedSigner ? selectedSignerStyles.ringClass : selectedSignerStyles.borderClass,
|
||||
)}
|
||||
>
|
||||
<h1>Hello</h1>
|
||||
</div>
|
||||
);
|
||||
};
|
||||
```
|
||||
|
||||
The code above shows a naive solution using a `combinedStyles` object containing TailwindCSS classes for various component styles (ring, border, hover, etc.).
|
||||
|
||||
Components would use custom hooks to apply appropriate styles based on the selected recipient. For example, recipient 1 would use `green-500` styles, turning all related elements green.
|
||||
|
||||

|
||||
|
||||
The problem with this approach is that we can't import the `combinedStyles` object into other components because TailwindCSS will remove the unused classes. That means we had to copy and paste the same object into multiple files. As a result, it pollutes the codebase with duplicated code, which makes it harder to maintain and scale the code. As the application grows, the `combinedStyles` object will become larger and more complex. Moreover, it's not very flexible, as it doesn't allow for easy customization of the colours.
|
||||
|
||||
While this approach works, there is a more efficient and scalable solution.
|
||||
|
||||
### Solution: Modularise the Logic and Use CSS Variables
|
||||
|
||||
To address the challenge of reusing colours across components, we moved the colours and associated hooks to a separate file, defining styles only in this file and accessing them from components through custom hooks.
|
||||
|
||||
```ts
|
||||
export const SIGNER_COLOR_STYLES = {
|
||||
green: {
|
||||
default: {
|
||||
background: 'bg-[hsl(var(--signer-green))]',
|
||||
base: 'rounded-lg shadow-[0_0_0_5px_hsl(var(--signer-green)/10%),0_0_0_2px_hsl(var(--signer-green)/60%),0_0_0_0.5px_hsl(var(--signer-green))]',
|
||||
fieldItem:
|
||||
'group/field-item p-2 border-none ring-none hover:bg-gradient-to-r hover:from-[hsl(var(--signer-green))]/10 hover:to-[hsl(var(--signer-green))]/10',
|
||||
fieldItemInitials:
|
||||
'opacity-0 transition duration-200 group-hover/field-item:opacity-100 group-hover/field-item:bg-[hsl(var(--signer-green))]',
|
||||
comboxBoxItem: 'hover:bg-[hsl(var(--signer-green)/15%)] active:bg-[hsl(var(--signer-green)/15%)]',
|
||||
},
|
||||
},
|
||||
|
||||
...
|
||||
};
|
||||
|
||||
export type CombinedStylesKey = keyof typeof SIGNER_COLOR_STYLES;
|
||||
|
||||
export const AVAILABLE_SIGNER_COLORS = [
|
||||
'green',
|
||||
'blue',
|
||||
'purple',
|
||||
'orange',
|
||||
'yellow',
|
||||
'pink',
|
||||
] as const satisfies CombinedStylesKey[];
|
||||
|
||||
export const useSignerColors = (index: number) => {
|
||||
const key = AVAILABLE_SIGNER_COLORS[index % AVAILABLE_SIGNER_COLORS.length];
|
||||
|
||||
return SIGNER_COLOR_STYLES[key];
|
||||
};
|
||||
|
||||
export const getSignerColorStyles = (index: number) => {
|
||||
return useSignerColors(index);
|
||||
};
|
||||
```
|
||||
|
||||
> The file was truncated for readability. You can see the complete code in the [signer-colors.ts](https://github.com/documenso/documenso/blob/main/packages/ui/lib/signer-colors.ts) file from the Documenso repository.
|
||||
|
||||
The `SIGNER_COLOR_STYLES` object contains the styles for each colour, such as the background, border, and hover colours. Based on the signer's index, the `useSignerColors` hook gets the styles for a specific colour. The `getSignerColorStyles` function is a helper function that returns the styles for a particular signer.
|
||||
|
||||
Now, the components can access the colours and styles using custom hooks. For example, to get the styles for a specific signer, the component can call the `useSignerColors` hook with the signer's index.
|
||||
|
||||
```ts
|
||||
const signerStyles = useSignerColors(recipientIndex);
|
||||
```
|
||||
|
||||
The hook will return the styles for that signer, which can then be applied to the component. For example, you can access the signer's background colour using `signerStyles.default.background`.
|
||||
|
||||
This approach makes managing the colours and styles easier, as they are defined in a single file. Changing or adding colours can be done in one place, making the code more modular and reusable.
|
||||
|
||||
We also opted for CSS variables to define colours, allowing more flexibility and consistency in styling. A single CSS variable for each colour can cover a wide range of states without relying on multiple TailwindCSS classes. For example, you can easily set the opacity and lightness of colour without using multiple classes. CSS variables help align colours with our brand guidelines while simplifying the overall styling process.
|
||||
|
||||
## The End
|
||||
|
||||
We're happy to see the new advanced fields released because they offer our users more flexibility, variety, and customization options. Implementing the new fields came with its challenges, but we overcame them and learned from them. We're excited to continue enhancing Documenso and providing our users with the best document signing experience.
|
||||
@ -1,72 +0,0 @@
|
||||
---
|
||||
title: 'Introducing Embedding Support for Documenso'
|
||||
description: 'Embedding is now here! Learn how we built it and how it can be used to bring e-signing to your own applications.'
|
||||
authorName: 'Lucas Smith'
|
||||
authorImage: '/blog/blog-author-lucas.png'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-09-06
|
||||
tags:
|
||||
- Development
|
||||
---
|
||||
|
||||
When we first launched Documenso, one of the most requested features was embedding. We knew it was important and aligned with our desire to not just be a e-signing application but to instead provide the e-signature infrastructure for the web and beyond.
|
||||
|
||||
With that said, we decided to hold off initially so we could focus on building a solid, well-featured core application. Looking back, this was definitely the right call. Embedding is only as good as the features behind it, and we didn't want to release something that wasn't ready to meet user and developer expectations.
|
||||
|
||||
Over the past year, we've been busy adding tons of new features and reaching new levels of compliance, like 21 CFR Part 11. We've also introduced [new fields](/blog/introducing-advanced-signing-fields), [built out an API](/blog/public-api), [added webhooks, integrations with Zapier](/blog/launch-week-2-day-4), and a lot more.
|
||||
|
||||
Now that we've laid a solid foundation, it's finally time to focus on embedding, the top-requested feature from both our users and those self-hosting our platform.
|
||||
|
||||
## Why Embedding Took Time
|
||||
|
||||
In previous projects, I’ve often seen embedding built by bundling components for use in a client’s website or app. This method gives users maximum flexibility for styling and behavior, while avoiding certain cross-origin issues. However, it can also introduce problems like code conflicts or performance bottlenecks. For example, third-party tools such as Google Tag Manager (GTM) or other marketing scripts can interfere with your SDK. Additionally, the SDK must remain lightweight to avoid slowing down the client’s page.
|
||||
|
||||
For Documenso, we decided to explore a different approach. After carefully researching our options, we opted for an iframe-based solution. While iframes are typically less flexible—especially when it comes to theming or passing pre-filled data containing personally identifiable information (PII)—we identified ways to mitigate these concerns.
|
||||
|
||||
One of the biggest challenges was ensuring that we could pass sensitive data, like emails for pre-filling forms, without exposing PII to our server. To solve this, we used [fragment identifiers](https://developer.mozilla.org/en-US/docs/Web/API/URL/hash) in the URL, which are processed client-side and never sent in network requests. This method ensures that PII is protected and not logged by our server or any intermediate web services.
|
||||
|
||||
### Using the PostMessage API for Communication
|
||||
|
||||
To maintain a high level of interactivity, our iframes communicate with the parent window using the [postMessage API](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage). This allows us to notify the parent app when specific events occur inside the iframe, creating a more dynamic user experience and bridging the gap between our iframe-based solution and typical fat SDKs.
|
||||
|
||||
Additionally, props are passed into the iframe via the [fragment identifier](https://developer.mozilla.org/en-US/docs/Web/API/URL/hash) of the URL. This avoids the need for complex two-way data synchronization between the parent and child frames, making the system stable and more reliable.
|
||||
|
||||
### Building the Embeds with Mitosis
|
||||
|
||||
Given that our iframe solution is quite lightweight, we saw this as a great opportunity to experiment with [Mitosis](https://mitosis.builder.io/) which would let us do something truly special. For those unfamiliar, Mitosis is a project by Builder.io that lets you write components once and then transpile them into a variety of frameworks like React, Vue, and Svelte.
|
||||
|
||||
We used Mitosis to build two key components: a direct template embed and a document signing embed. The direct template allows users to use a template as if it were an evergreen document—meaning that, when someone completes the template, a new document is automatically generated. This is the use case we expect most users to adopt for embedding. For more advanced workflows, we also offer a document signing embed, which can handle multi-recipient workflows and other complex scenarios intended for use in deeper, rich integrations.
|
||||
|
||||
Mitosis allowed us to quickly target several popular frameworks, including [React](https://www.npmjs.com/package/@documenso/embed-react), [Preact](https://www.npmjs.com/package/@documenso/embed-preact), [Vue](https://www.npmjs.com/package/@documenso/embed-vue), [Svelte](https://www.npmjs.com/package/@documenso/embed-svelte), and [SolidJS](https://www.npmjs.com/package/@documenso/embed-solid).
|
||||
|
||||
I had also hoped to include Angular, but while Mitosis makes it really easy to transpile component, we still have to take care of bundling and packaging the resulting component ourselves. While the above frameworks can all be bundled using Vite.js, Angular still has it's own set of tooling that we would need to learn and use. Given this constraint we opted to put Angular on hold for now while we wait for the newer Vite.js support to mature.
|
||||
|
||||
### Challenges and Lessons with Mitosis and more
|
||||
|
||||
While our experience with Mitosis was largely positive, there were some challenges along the way. For instance, certain state properties with the same names as props caused issues during the transpilation process, leading to type errors and unexpected transpilation results with some targets.
|
||||
|
||||
This was also a challenge since our initial implementation of the two components had some minor separation of concerns which also resulted in some transpilation issues with some targets. We addressed this by removing the separation of concerns for now since it was mostly for show rather than out of necessity.
|
||||
|
||||
On top of that, packaging and publishing the embeds posed its own set of challenges, particularly given the growing complexity of JavaScript package management. Tools like [Publint](https://www.npmjs.com/package/publint) helped streamline the process by ensuring we followed best practices for both CommonJS and ESM formats.
|
||||
|
||||
### To the Future, The Documenso Platform
|
||||
|
||||
With the embedding feature now in place, we're excited to continue expanding Documenso's capabilities. Embeds are just the beginning of what we're calling the Documenso platform. Through our user research, we've learned that while many businesses appreciate having a flexible e-signature solution, they're even more interested in using our tools to build signing functionality directly into their own apps—without worrying about the technical complexities of compliance and security that come with e-signing.
|
||||
|
||||
Over the coming months, we'll be working on enhancing our API, strengthening integrations with tools like Zapier, and improving our webhook system. Our goal is to give users the ability to embed e-signatures and document management wherever they need it, whether that's through self-hosting or by using Documenso as a platform. We can't wait to see how our users and self-hosters leverage these new capabilities!
|
||||
|
||||
### Ready to Get Started?
|
||||
|
||||
If you're ready to embed document signing into your own app or website, check out our [Embedding Documentation](https://docs.documenso.com/developers/embedding?utm_source=blog&utm_campaign=introducing-embedding) to see how easy it is to get started. You'll find everything you need to get started today!
|
||||
|
||||
<video
|
||||
src="/blog/introducing-embedding/embedding-demo.mp4"
|
||||
className="aspect-video w-full"
|
||||
autoPlay
|
||||
loop
|
||||
controls
|
||||
/>
|
||||
|
||||
We're always here to help! If you have questions or need support, join our [Discord](https://documen.so/discord) or [book a demo](https://documen.so/book-a-demo). We'd love to hear how you're using Documenso or wanting to use Documenso to enhance your workflow.
|
||||
|
||||
Stay tuned for more updates as we continue to evolve the Documenso platform and make it even easier to bring document signing into your workflows.
|
||||
@ -1,64 +0,0 @@
|
||||
---
|
||||
title: Launch Week II - Day 1 - Teams
|
||||
description: Teams for Documenso are here. And they come free for early adopters!
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-02-26
|
||||
tags:
|
||||
- Launch Week
|
||||
- Teams
|
||||
- Early Adopter Perks
|
||||
---
|
||||
|
||||
<video
|
||||
id="vid"
|
||||
width="100%"
|
||||
src="https://github.com/documenso/design/assets/1309312/12a85ec7-20bb-4813-9714-e4da42c9cfba"
|
||||
autoPlay
|
||||
loop
|
||||
muted
|
||||
></video>
|
||||
|
||||
> TLDR; Docucmenso now supports teams that share documents, templates and a team mail address. Early Adopter get UNLIMITED<sup>1</sup> Users.
|
||||
|
||||
## Kicking off Launch Week II - "Connected"
|
||||
|
||||
The day has come! Roughly 5 months after kicked off our first launch week with open sourcing our design and Malfunction Mania, Launch Week #2 is here 🎉 This Launch Week's theme is "connected", since this is all about connecting humans, machines and documents.
|
||||
|
||||
Working with documents and getting that signature is a team sport. This is why we are kicking it off today with a very long-awaited feature: Documenso now supports teams!
|
||||
|
||||
## Introducing Teams for Documenso
|
||||
|
||||
You can now create teams next to your personal account: Simply invite your colleagues, and you can include everyone you like in working with your documents. With teams, you can:
|
||||
|
||||
- Send unlimited signature requests with unlimited recipients
|
||||
- Create, view, edit and sign documents owned by the team
|
||||
- Define a dedicated team email, to receive signing requests into a team inbox for the owner to sign
|
||||
- Manage team roles: Member (Create+Edit), Managers (+Manage Team Members), Owner (+Transfer Team +Delete Team + Sign Documents sent to team email)
|
||||
|
||||
## Pricing
|
||||
|
||||
Together with Teams, we are announcing the new teams pricing:
|
||||
|
||||
- $10 per seat per month
|
||||
- 5 seats minimum
|
||||
- You can add seats dynamically as needed
|
||||
|
||||
This pricing will take effect, as soon as the early adopter seats run out. Want to check out teams: [https://documen.so/teams](https://documen.so/teams).
|
||||
|
||||
## Early Adopter Perks
|
||||
|
||||
There is one more point on pricing I have been looking forward to for a long time:
|
||||
|
||||
All early adopter plans now include **UNLIMITED teams and users**<sup>1</sup> . We appreciate your support so far very much, and I'm happy to announce this first of more early adopter perks to come. We have roughly 48 early adopter plans left, so if you plan to onboard your team, now is a great time to [grab your early adopter seat.](https://documen.so/claim-early-adopters-plan)
|
||||
|
||||
We are eager to hear from all teams users how you like this addition and what we can add to make it even better. Connect with us on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord) if you have any questions or comments! We're always here, and we would love to hear from you :)
|
||||
|
||||
> 🚨 We need you help to help us to make this the biggest launch week yet: <a href="https://twitter.com/intent/tweet?text=It's @Documenso Launch Week Day 1! Teams just dropped. Check it out https://documen.so/day1 🚀"> Support us on Twitter </a> or anywhere to spread awareness for open signing! The best posts will receive merch codes 👀
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
|
||||
\
|
||||
[1] Within reason. If you are unsure what that means, feel free to contact hi@documenso.com and ask for clarification if it's more than 100.
|
||||
@ -1,76 +0,0 @@
|
||||
---
|
||||
title: Launch Week II - Day 2 - Templates
|
||||
description: Templates help you prepare regular documents faster. And you can share them with your team!
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-02-27
|
||||
tags:
|
||||
- Launch Week
|
||||
- Templates
|
||||
---
|
||||
|
||||
<video
|
||||
id="vid"
|
||||
width="100%"
|
||||
src="https://github.com/documenso/design/assets/1309312/c9504db1-26b7-4033-88ed-a95cabd02e92"
|
||||
autoPlay
|
||||
loop
|
||||
muted
|
||||
></video>
|
||||
|
||||
> TLDR; You can now reuse documents via templates. More field types coming soon as well.
|
||||
|
||||
## Introducing Templates
|
||||
|
||||
It's day 2 of Launch Week, everybody 🙌 After introducing [Teams](https://documenso.com/blog/launch-week-2-day-1) yesterday, today we are looking at making Documenso faster for daily use:
|
||||
We are launching templates for Documenso! Templates are an easy way to reuse documents you send out often with just a few clicks. With templates, you can:
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/quickfill.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="Template recipients quick fill view"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Quickly fill out recipients, when creating from a template
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
- Save often-uploaded documents for reuse
|
||||
- Pre-define fields, so you just have to send the document
|
||||
- Quickly fill out recipients and roles for new documents
|
||||
- Share templates with your team to make working together even easier
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/template.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="Create from template view"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
POV: You are a diligent german and create custom receipts with Documenso
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
## Pricing
|
||||
|
||||
Templates are **included in all Documenso Plans!** That includes our free tier: The limit of 5 documents per month still applies, but you are free to reach it with less friction using templates. Sharing templates with other users is only possible with the teams plan. If you want to share templates with people not in your team, we might have something coming up later this week 👀
|
||||
|
||||
## What's Next for Templates
|
||||
|
||||
We have a lot of great stuff coming up for templates as well:
|
||||
|
||||
- More Field Types are in the pipeline
|
||||
- Sharing Templates Externally 👀
|
||||
|
||||
Check out templates [here](https://documen.so/templates) and let us know what you think and what we can improve. Which field types are you missing? Connect with us on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord) if you have any questions or comments! We're always here and would love to hear from you :)
|
||||
|
||||
> 🚨 We need you help to help us to make this the biggest launch week yet: <a href="https://twitter.com/intent/tweet?text=It's @Documenso Launch Week Day 2! They just launched templates, and I'm pumped 🎉🚀🚀🚀. Check it out https://documen.so/day2"> Support us on Twitter </a> or anywhere to spread awareness for open signing! The best posts will receive merch codes 👀
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,53 +0,0 @@
|
||||
---
|
||||
title: Launch Week II - Day 3 - API
|
||||
description: Documenso's mission is to create a plattform developers all around the world can build upon. Today we are releasing the first version of our public API, included in all plans!
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-02-28
|
||||
tags:
|
||||
- Launch Week
|
||||
- API
|
||||
---
|
||||
|
||||
<video
|
||||
id="vid"
|
||||
width="100%"
|
||||
src="https://github.com/documenso/design/assets/1309312/cb74d6cb-a127-4cac-a166-ad6b56c6140d"
|
||||
autoPlay
|
||||
loop
|
||||
muted
|
||||
></video>
|
||||
|
||||
> TLDR; The public API is now availible for all plans.
|
||||
|
||||
## Introducing the public Documenso API
|
||||
|
||||
Launch. Week. Day. 3 🎉 Documenso's mission is to create a platform that developers all around the world can build upon. Today we are releasing the first version of our public API, and we are pumped. Since this is the first version, we focused on the basics. With the new API you can:
|
||||
|
||||
- Get Documents (Individual or all Accessible)
|
||||
- Upload Documents
|
||||
- Delete Documents
|
||||
- Create Documents from Templates
|
||||
- Trigger Sending Documents for Singing
|
||||
|
||||
You can check out the detailed API documentation here:
|
||||
|
||||
> API DOCUMENTATION: [https://app.documenso.com/api/v1/openapi](https://app.documenso.com/api/v1/openapi)
|
||||
|
||||
## Pricing
|
||||
|
||||
We are building Documenso to be an open and extendable platform; therefore the API is included in all current plans. The API is authenticated via auth tokens, which every user can create at no extra cost, as can teams. Existing limits still apply (i.e., the number of included documents for the free plan). While we don't have all the details yet, we don't intend to price the API usage in itself (rather the accounts using it) since we want you to build on Documenso without being smothered by API costs.
|
||||
|
||||
> Try the API here for free: [https://documen.so/api](https://documen.so/api)
|
||||
|
||||
## What's next for the API
|
||||
|
||||
You tell us. This is by far the most requested feature, so we would like to hear from you. What should we add? How can we integrate even better?
|
||||
|
||||
Connect with us on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord) if you have any questions or comments! We're always here and would love to hear from you :)
|
||||
|
||||
> 🚨 We need you help to help us to make this the biggest launch week yet: <a href="https://twitter.com/intent/tweet?text=It's @Documenso Launch Week Day 3! The public API is here 👀 Check it out https://documen.so/day3"> Support us on Twitter </a> or anywhere to spread awareness for open signing! The best posts will receive merch codes 👀
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,63 +0,0 @@
|
||||
---
|
||||
title: Launch Week II - Day 4 - Webhooks and Zapier
|
||||
description: If you want to integrate Documenso without fiddling with the API, we got you as well. You can now integrate Documenso via Zapier, included in all plans!
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-02-29
|
||||
tags:
|
||||
- Launch Week
|
||||
- Zapier
|
||||
- Webhooks
|
||||
---
|
||||
|
||||
<video
|
||||
id="vid"
|
||||
width="100%"
|
||||
src="https://github.com/documenso/design/assets/1309312/3b60789d-8d27-4c66-ae5c-179e33c2e3e6"
|
||||
autoPlay
|
||||
loop
|
||||
muted
|
||||
></video>
|
||||
|
||||
> TLDR; Zapier Integration is now available for all plans.
|
||||
|
||||
## Introducing Zapier for Documenso
|
||||
|
||||
Day 4 🥳 Yesterday we introduced our [public API](https://documen.so/day3) for developers to build on Documenso. If you are not a developer or simple want a quicker integration this is for you: Documenso now support Zapier Integrations! Just connect your Documenso account via a simple login flow with Zapier and you will have access to Zapier's universe of integrations 💫 The integration currently supports:
|
||||
|
||||
- Document Created ([https://documen.so/zapier-created](https://documen.so/zapier-created))
|
||||
- Document Sent ([Chttps://documen.so/zapier-sent](https://documen.so/zapier-sent))
|
||||
- Document Opened ([https://documen.so/zapier-opened](https://documen.so/zapier-opened))
|
||||
- Document Signed ([https://documen.so/zapier-signed](https://documen.so/zapier-signed))
|
||||
- Document Completed ([https://documen.so/zapier-completed](https://documen.so/zapier-completed))
|
||||
|
||||
> ⚡️ You can create your own Zaps here: https://zapier.com/apps/documenso/integrations
|
||||
|
||||
Each event comes with extensive meta-data for you to use in Zapier. Missing something? Reach out on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord). We're always here and would love to hear from you :)
|
||||
|
||||
## Also Introducing for Documenso: Webhooks
|
||||
|
||||
To build the Zapier Integration, we needed a good webhooks concept, so we added that as well. Together with your Zaps, you can also now create customer webhooks in Documenso. You can try webhooks here for free: [https://documen.so/webhooks](https://documen.so/webhooks)
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/hooks.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="Webhooks UI"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Create unlimited custom webhooks with each plan.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
## Pricing
|
||||
|
||||
Just like the API, we consider the Zapier integration and webhooks part of the open Documenso platform. Zapier is **available for all Documenso plans**, including free! [Login now](https://documen.so/login) to check it out.
|
||||
|
||||
> 🚨 We need you help to help us to make this the biggest launch week yet: <a href="https://twitter.com/intent/tweet?text=It's @Documenso Launch Week Day 4! Documenso now supports @Zapier 🤯 https://documen.so/day4"> Support us on Twitter </a> or anywhere to spread awareness for open signing! The best posts will receive merch codes 👀
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,61 +0,0 @@
|
||||
---
|
||||
title: Launch Week II - Day 5 - Documenso Profiles
|
||||
description: Documenso profiles allow you to send signing links to people so they can sign anytime and see who you are. Documenso Profile Usernames can be claimed starting today. Long ones free, short ones paid. Profiles will launch as soon as they are shiny.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-03-01
|
||||
tags:
|
||||
- Launch Week
|
||||
- Profiles
|
||||
---
|
||||
|
||||
<video
|
||||
id="vid"
|
||||
width="100%"
|
||||
src="https://github.com/documenso/design/assets/1309312/89643ae2-2aa9-484c-a522-a0e35097c469"
|
||||
autoPlay
|
||||
loop
|
||||
muted
|
||||
></video>
|
||||
|
||||
> TLDR; Documenso profiles allow you to send signing links to people so they can sign anytime and see who you are. Documenso Profile Usernames can be claimed starting today. Long ones free, short ones paid. Profiles launch as soon as they are shiny.
|
||||
|
||||
## Introducing Documenso Profile Links
|
||||
|
||||
Day 5 - The Finale 🔥
|
||||
|
||||
Signing documents has always been between humans, and signing something together should be as frictionless as possible. It should also be async, so you don't force your counterpart to jog to their device to send something when you are ready. Today we are announcing the new Documenso Profiles:
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/profile.png"
|
||||
width="1260"
|
||||
height="813"
|
||||
alt="Timur's Documenso Profile"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Async > Sync: Add public templates to your Documenso Link and let people sign whenever they are ready.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
Documenso profiles work with your existing templates. You can just add them to your public profile to let everyone with your link sign them. With profiles, we want to bring back the human aspect of signing.
|
||||
|
||||
By making profiles public, you can always access what your counterparty offers and make them more visible in the process. Long-term, we plan to add more to profiles to help you ensure the person you are dealing with is who they claim to be. Documenso wants to be the trust layer of the internet, and we want to start at the very fundamental level: The individual transaction.
|
||||
|
||||
Profiles are our first step towards bringing more trust into everything, simply by making the use of signing more frictionless. As there is more and more content of questionable origin out there, we want to support you in making it clear what you send out and what not.
|
||||
|
||||
## Pricing and Claiming
|
||||
|
||||
Documenso profile username can be claimed starting today. Documenso profiles will launch as soon as we are happy with the details ✨
|
||||
|
||||
- Long usernames (6 characters or more) come free with every account, e.g. **documenso.com/u/timurercan**
|
||||
- Short usernames (5 characters or fewer) or less require any paid account ([Early Adopter](https://documen.so/claim-early-adopters-plan), [Teams](https://documen.so/teams) or Enterprise): **e.g., documenso.com/u/timur**
|
||||
|
||||
You can claim your username here: [https://documen.so/claim](https://documen.so/claim)
|
||||
|
||||
> 🚨 We need you help to help us to make this the biggest launch week yet: <a href="https://twitter.com/intent/tweet?text=It's @Documenso Launch Week Day 5! You can now claim your username for the upcoming profile links 😮 https://documen.so/day5"> Support us on Twitter </a> or anywhere to spread awareness for open signing! The best posts will receive merch codes 👀
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,115 +0,0 @@
|
||||
---
|
||||
title: Moving from Linear to GitHub & LIVE Roadmap 2.0
|
||||
description: We are leaving linear and are going all in on GitHub. Here is how we do it.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-01-10
|
||||
tags:
|
||||
- GitHub
|
||||
- Backlog
|
||||
- Roadmap
|
||||
---
|
||||
|
||||
# From Linear to GitHub
|
||||
|
||||
> TLDR; We are leaving Linear and are using only GitHub going forward. We no longer communicate feature timelines, only what we are working on and what's next.
|
||||
|
||||
If you follow us, you know we have been in full-on build mode. We are building, the community is building, it's great. Building is our daily business, so we think a lot about improving our approach to doing it.
|
||||
Our most recent approach is to reduce the number of tools and platforms we use. Every tool we use
|
||||
|
||||
- Reduces the average time you spend on the tool
|
||||
- Reduces your focus
|
||||
- Increases mental load to keep all points of interest in mind
|
||||
|
||||
We thought about where we spend the most time, and hardly surprising: it's GitHub. Not only do we spend a lot of time there, but we also WANT to spend a lot of time there because:
|
||||
|
||||
- It's where the community contributes, and we are all about community
|
||||
- It's where we show the world what we are working on
|
||||
|
||||
# The old structure
|
||||
|
||||
So far, we have been using Linear for our Backlog/ Task Management and synced issues we want to showcase or work on with the community via synclinear.com. Not only did we have our development issues there, but since
|
||||
we have our own resident founding designer, we created a proper design backlog to structure our design workflows.
|
||||
|
||||
# The new structure
|
||||
|
||||
We moved everything to GitHub once we realized our focus was already there. This has a few key benefits:
|
||||
|
||||
- Reducing dilution of attention and time: You can hang out on GitHub without risk of missing much
|
||||
- Putting different aspects of Documenso close to each other: Development, Design, Community
|
||||
- Keep long-term, niche, and very abstract issues out of the main repo so we don't get desensitized by large issue numbers
|
||||
|
||||
To achieve this, we created a few GitHub repositories to host issues, with the main repository remaining the central point of interest, especially for the community.
|
||||
|
||||
## 1. Main Repository - Day to day Issues and the shorter-term roadmap (LIVE Roadmap 2.0)
|
||||
|
||||
> [github.com/documenso/documenso](https://github.com/documenso/documenso)
|
||||
|
||||
Apart from the source code of the Documenso app and website, the main repo houses issues raised by the community and issues where we invite the community to participate.
|
||||
With the overhauling of our issue management, we are also updating our progress communication. While the software and product development process is highly complex,
|
||||
we try to give as much insight into what we do as possible. To that end, we went through 3 phases, three being what we do now.
|
||||
|
||||
1. **One extensive roadmap**: Initially we had one roadmap and were (very) slowly checking off boxes there (via a "Roadmap" milestone). While this is easy, it's also pretty imprecise and not practical as the project grows
|
||||
2. **Estimated releases per quarter**: To give better guidance, we tried communicating our goals for the quarter; a pretty big window we thought we could roughly "hit". While the idea of not being too detailed was good, it is tough to estimate when some significant things are done if you do a lot of minor/ other things in parallel,
|
||||
like working with the community and tuning things you go. Hitting time targets is tricky because there may be better things to do than sticking to that time target. This is always much easier to grasp for the people closely involved. The fallacy is to assume the thing you plan for exists in a vacuum.
|
||||
3. Since we do not want to limit ourselves in choosing the most effective course but still give some insight into what's going on and what's coming up, we updated the live roadmap [https://documen.so/live](https://documen.so/live). It now shows what we are currently working on and what we plan on doing next. We do not provide
|
||||
a specific timeline anymore since we couldn't even if we wanted to. Of course, we set our short-term goals based on what's best for the community. We give updates on the issues being worked on as well as possible.
|
||||
|
||||
## 2. Public Backlog - The longer-term roadmap
|
||||
|
||||
> [github.com/documenso/backlog](https://github.com/documenso/backlog)
|
||||
|
||||
The public backlog houses everything we want to build eventually. We do not provide a specific timeline of when that might happen. If we decide against something, it will be removed from the public backlog, as we consider this our long-term vision for Documenso. If you are interested in something on the roadmap, comment on the issue or post on Discord. This helps us gauge interest in specific features.
|
||||
**Issues in the public backlog are not** available to be worked on. For issues to work on, please check the main repository issues. The issues found here are scoped broader since they are not meant for immediate execution but rather give a sense of where Documenso is going and what we consider part of our domain.
|
||||
|
||||
## 3. Internal Backlog
|
||||
|
||||
> github.com/documenso/backlog-internal
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/gh1.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="GitHub: Development Board"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Our internal Kanban for development
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
This serves as the direct replacement for our Linear backlog. Here, we manage issues that are either too small or short-term for inclusion in the long-term roadmap, yet too specialized or fundamental to be integrated into the main repository. Our development Kanban board is implemented using a GitHub project.
|
||||
|
||||
## 4. Internal Design Backlog
|
||||
|
||||
> github.com/documenso/design-internal
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/gh2.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="GitHub: Design Board"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Our internal Kanban for design
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
This is the design equivalent of the internal backlog. The internal design backlog houses our design projects that include the exploration of new features, detailed UI designs, and improving the platform overall.
|
||||
It's similar to the Kanban board for the development backlog.
|
||||
|
||||
## 5. Public Design Repository
|
||||
|
||||
> [github.com/documenso/backlog-design](https://github.com/documenso/design)
|
||||
|
||||
While the internal design backlog also existed in Linear, the public design repository is new. Since designing in the open is tricky, we opted to publish the detailed design artifacts with the corresponding feature instead.
|
||||
We already have design.documenso.com housing our general design system. Here, we will publish the specifics of how we applied this to each feature. We will publish the first artifacts here soon, what may be in the cards can be found on the [LIVE Roadmap](https://documen.so/live).
|
||||
|
||||
Feel free to connect with us on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord) if you have any questions or comments! We're always here to help and would love to hear from you :)
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,75 +0,0 @@
|
||||
---
|
||||
title: The 🔴 LIVE Roadmap
|
||||
description: It's the Launch Week Day finale, Day 5! We are going out with a bang and introducing the 🔴 LIVE roadmap, featuring our next Product Hunt Launch - Free Singleplayer Documenso - Sign without creating an account!
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2023-09-29
|
||||
tags:
|
||||
- Free Plan
|
||||
- Launch
|
||||
- Roadmap
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/roadmap.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="XKCD: Bug"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
"Being early is, uh, good." -Unknown
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; We are launching a [🔴 LIVE roadmap](https://documen.so/launches), that gets updated regularly.\
|
||||
> First upcoming launch: A free single signer experience.
|
||||
|
||||
## The Road Ahead
|
||||
|
||||
It's been quite a week, launching our [design system](https://documenso.com/blog/design-system), [kicking of a Malfunction Mania](https://documenso.com/blog/malfunction-mania), a [shiny new contributor perk](https://documenso.com/blog/shop) and our [early adopter deal](https://documenso.com/blog/early-adopters). After discussing Version 1.0 a lot, we want to close the week by looking ahead. As an open company, we want transparency about what we are working on and what to expect next. Especially for our Early Adopters, we want to paint a clear picture of what to expect in the near term.
|
||||
|
||||
Communicating software development progress and goals is historically tricky because of it's complex nature. Exact release dates are notoriously unreliable; if they are not, they force a particular style of development, forcing the team to make tradeoffs on scope and quality.
|
||||
|
||||
To give an appropriate insight into our work, we are launching our new [🔴 LIVE roadmap](https://documen.so/launches) today:
|
||||
|
||||
- A List of quarterly development and feature goals
|
||||
- That gets updated regularly (bi-weekly)
|
||||
- Has up-to-date insights from the team on where we stand
|
||||
|
||||
**While there are some great features planned, one stands out: Single Player Mode!**
|
||||
|
||||
## Announcing Documenso Singleplayer Mode
|
||||
|
||||
<a href="https://www.producthunt.com/products/documenso" target="_blank">
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/sp5.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center font-bold">
|
||||
🚨 We are going back to Product Hunt! Are you ready, player one?
|
||||
</figcaption>
|
||||
</figure>
|
||||
</a>
|
||||
|
||||
Single Player Mode will be a free, loginless signing experience for single signers. If you hate creating an account to sign a single, once-in-a-while-document yourself as much as we do, we've got you. Our new free tier will accompany Singleplayer. While you don't HAVE to create an account to sign sth. quickly, you can. A free tier Documenso Account will give you the following:
|
||||
|
||||
- A place to store all your sent and received Documenso-signed documents
|
||||
- Free forever
|
||||
- Unlimited recipients
|
||||
- 5 free signatures per month (for now, excluding third party types like QES)
|
||||
- The use of templates, as soon as we [release](https://documen.so/launches) them
|
||||
|
||||
Singleplayer will launch in the first half of October, shortly after the release of 1.0, **[ON PRODUCT HUNT!](https://www.producthunt.com/products/documenso)** That's right, we are going back to Product Hunt to kick of this new phase of Documenso and you are invited to join us once again :)
|
||||
|
||||
**[Subscribe on PH](https://www.producthunt.com/products/documenso)** to be notified when we launch.
|
||||
|
||||
If you have any questions or comments, please reach out on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord).
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,57 +0,0 @@
|
||||
---
|
||||
title: Announcing Malfunction Mania
|
||||
description: Launch Week Day 2 Y'all! We're getting ready to release Documenso 1.0! Join in on the fun of making sure the open-source alternative to DocuSign is on point. We're calling a 'MALFUNCTION MANIA.'
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2023-09-26
|
||||
tags:
|
||||
- Testing
|
||||
- Rewrite
|
||||
- Bounties
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/mm.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="Malfunctioning Documenso Logo in broken colors"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
We're calling a MALFUNCTION MANIA! 🚨
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; Documenso 1.0 is in the [staging environment](https://documen.so/staging). Go check it out.
|
||||
|
||||
It's been a minute since Lucas proclaimed, ["We're doing a rewrite"](https://documenso.com/blog/why-were-doing-a-rewrite), and many of you have been asking when the new version will be available. I'm happy to say that the wait has come to an end. The work on Documenso 1.0 has reached a level we feel comfortable going into the next phase with. We had a lot of community feedback, contributions, and moral support to get us this far, which is why we're excited to announce the most extensive community project yet:
|
||||
|
||||
As Documenso 1.0 just hit the staging environment, we're calling a MALFUNCTION MANIA. An enormous, public testing phase, where we invite everyone to try out the new version, hunt down, report, and fix any malfunctions (aka bugs), and give feedback before release. Malfunction Mania will happen alongside our internal testing, and by combining the two, we want to ensure the best possible release we can have for Version 1.0. We know many of you have been eager to contribute; this is your chance (the first of many to come).
|
||||
|
||||
## As part of Malfunction Mania, we're offering special bug bounties
|
||||
|
||||
- We award $25 - $100 per report/ issue/ fix, depending on the severity and if the problem is already known
|
||||
- Bounties will be awarded for fixing reported or other critical issues via accepted Pull Requests (PR)
|
||||
- Just reporting issues in a reproducible way can also be awarded
|
||||
- Smaller but notable contributions like minor issues and documentation will be awarded with exclusive merch as we see fit.
|
||||
|
||||
## What you can do
|
||||
|
||||
- Head over to the [staging environment](https://documen.so/staging), check out the new version and give it a spin;
|
||||
- Check out the [source code](https://github.com/documenso/documenso) on GitHub and look it over;
|
||||
- Spin up the new version locally and try it out.
|
||||
|
||||
## How to get the bounties
|
||||
|
||||
- Report bugs by creating an issue here: [documen.so/issues](https://documen.so/issues);
|
||||
- Fix bugs by creating a Pull Request (PR);
|
||||
- Look over and add missing documentation/ Quickstarts and other useful resources.
|
||||
|
||||
Best from Hamburg
|
||||
Timur
|
||||
|
||||
We don't have a specific end date for Malfunction Mania. We plan to move the staging version into the production environment by the end of the month once we're happy with the results. Bug reports and fixes are, of course, always welcome going forward.
|
||||
|
||||
**[Follow Documenso on Twitter / X](https://documen.so/tw) and [join the Discord server](https://documen.so/discord) to get the latest about Malfunction Mania.**
|
||||
@ -1,31 +0,0 @@
|
||||
---
|
||||
title: The Documenso Manifest
|
||||
description: Signing documents is a fundamental building block of private, economic, and government interactions. Access to easy and secure signing to participate in society should therefore be a fundamental right for everyone. The technology to enable this should be accessible and widespread.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2023-07-13
|
||||
tags:
|
||||
- Manifesto
|
||||
- Open Source
|
||||
- Vision
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/blog-banner-manifest.jpeg"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="The Documenso Manifest blog banner"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Documenso — The Open Source DocuSign Alternative.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
Signing documents is a fundamental building block of private, economic, and government interactions. Access to easy and secure signing to participate in society should therefore be a fundamental right for everyone. The technology to enable this should be accessible and widespread.
|
||||
|
||||
We know that open source is the key to solving this need once and for all to benefit all humankind. Using open source kickstarts innovation by putting the open sharing of ideas and solutions first. With Documenso, we will create an open and globally accessible signing platform to empower users, customers, and developers to fulfill their needs. Documenso is built by and for the global community, listening and implementing what is needed. Being transparent with the code and the processes that use it brings trust and security to the platform.
|
||||
|
||||
We build Documenso for longevity and scale by embracing the capital efficiency and inclusiveness of the Commercial Open Source (COSS) movement. We are building a global commodity for the world.
|
||||
@ -1,56 +0,0 @@
|
||||
---
|
||||
title: Preview the next Documenso
|
||||
description: We're redesigning Documenso by making it more elegant and appropriately playful. Here's a sneak peek.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2023-08-21
|
||||
tags:
|
||||
- Design
|
||||
- Preview
|
||||
---
|
||||
|
||||
Since we launched [Documenso 0.9 on Product Hunt](https://producthunt.com/products/documenso#documenso) last May, the team's been hard at work behind the scenes to ramp up development and design to deliver an excellent next version.
|
||||
|
||||
Last week, Lucas shared the reasoning how [why we're doing a rewrite](https://documenso.com/blog/why-were-doing-a-rewrite).
|
||||
|
||||
Today, I'm pleased to share with you a preview of the next Documenso.
|
||||
|
||||
## Preview the next Documenso
|
||||
|
||||
We redesigned the whole signing flow to make it more appealing and more convenient.
|
||||
|
||||
We improved the overall look and feel by making it more elegant and appropriately playful. Focused on the task at hand, but explicitly enjoying doing it.
|
||||
|
||||
**We call it happy minimalism.**
|
||||
|
||||
We paid particular attention to the moment of signing, which should be celebrated.
|
||||
|
||||
The image below is the final bloom of the completion celebration we added:
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/blog-fig-preview-documenso.webp"
|
||||
width="2000"
|
||||
height="1268"
|
||||
alt="Figure 1"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">"You've signed a new document."</figcaption>
|
||||
</figure>
|
||||
|
||||
## Kicking off a new phase of collaboration
|
||||
|
||||
This preview also is the kickoff for a new phase of how we collaborate with the community.
|
||||
|
||||
We recently [switched to Discord](https://documenso.com/blog/switching-from-slack-to-discord) to set up a more developer-friendly, community-driven environment, and we just released the [public roadmap](https://documen.so/launches).
|
||||
|
||||
As always, if you have any questions or feedback, please reach out. We love to hear from you.
|
||||
|
||||
Best from Hamburg,
|
||||
|
||||
Timur
|
||||
|
||||
Make sure to [star the GitHub repository](https://documen.so/github), [follow us on X](http://documen.so/twitter) and [join the Discord server](https://documen.so/discord) to keep up to date with all things Documenso.
|
||||
|
||||
We're building a beautiful, open-source alternative to DocuSign.
|
||||
@ -1,38 +0,0 @@
|
||||
---
|
||||
title: Announcing Pre-Seed and Open Metrics
|
||||
description: We are excited to report the closing of our Pre-Seed round. You can find the juicy details on our new /open page. Yes, it was signed using Documenso.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2023-08-17
|
||||
tags:
|
||||
- Funding
|
||||
- Metrics
|
||||
- Open Startup
|
||||
---
|
||||
|
||||
Today I'm happy to announce that we closed a \$1.25M Pre-Seed round for Documenso, bringing our total funding to \$1.54M. The round actually closed last month, we just were sneaky about it.
|
||||
|
||||
## Two more for the road (to open signing)
|
||||
|
||||
We're ecstatic to welcome [OSS Capital](https://twitter.com/osscapital) and especially [Joseph Jacks](https://twitter.com/JosephJacks_) to the inner circle of the open signing revolution. We're also fortunate to be joined by Orrick's very own [John Harrison](https://www.linkedin.com/in/john-harrison-a1213b9/) and his legal experience. For those who are wondering, yes, the round was, of course, signed using Documenso.
|
||||
|
||||
## Open Source, Open Metrics
|
||||
|
||||
If you follow us, you know we're firmly committed to the open source values of openness and transparency. For us, this includes not only the code side of things but also the business. As we aim to build trust among our investors, customers, and partners, we want to be open about what's going on. We also want to allow everyone to learn from our data and choices, just as we did from so many other COSS (Commercial Open Source) startups. The term "Open Startup" isn't precisely defined (and probably will never be, just like startup). There is however a [great write-up](https://cal.com/blog/open-startup) about the basics by the founder of our favorite open source scheduling tool Cal.com.
|
||||
|
||||
The two main takeaways are:
|
||||
|
||||
- "Any Startup that shares its metrics as open as technically and operationally possible is an Open Startup."
|
||||
- "Why should I care? Frankly speaking, Open Startups have a tough time screwing you over."
|
||||
|
||||
The more open the culture, the less shady stuff is going on. While this may sound trivial, the implications are profound. A new generation of organizations, operating more ethically and responsibly simply because everything is out in the open.
|
||||
|
||||
For us, there are two sides to being an Open Startup:
|
||||
|
||||
- The company side: Sharing Financial KPIs like growth, funding, team structure, salary, internal processes, and tools.
|
||||
- The product side: Sharing insights and data like usage, reach, and GitHub activity.
|
||||
|
||||
Both sides aim to contribute to the global knowledge base of how startups work, specifically COSS startups. As we see more and more COSS, best practices and business insights should be broadly available to let the space mature. As we contribute code to the global community, we also contribute our business knowledge to help bring about even more COSS.
|
||||
|
||||
Starting today, we're releasing a lot of our data as part of the Open Startup movement. You can find the juicy details on our funding and more here: [documen.so/open](https://documen.so/open)
|
||||
@ -1,64 +0,0 @@
|
||||
---
|
||||
title: Project Babel
|
||||
description: We are announcing Project Babel - an initiative to support all languages of the world on Documenso.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-11-08
|
||||
tags:
|
||||
- Languages
|
||||
- Community
|
||||
- Open Source
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/babel.png"
|
||||
width="800"
|
||||
height="800"
|
||||
alt=""
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">The tower of Babel to add some Gravitas to this project.</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; We are opening up translations to the community. Read this to add a language: https://documen.so/babel-fish
|
||||
|
||||
## Announcing Project Babel: Powering Documenso with Global Language Support
|
||||
|
||||
At Documenso, we believe that open source is more than just a software philosophy—it’s a way to build solutions that are open to all. Now, we’re happy to take that mission further with Project Babel, a community-driven initiative designed to bring worldwide language support to the Documenso platform. This project aims to enable Documenso to support as many languages as possible.
|
||||
|
||||
## Why Language Support Matters
|
||||
|
||||
We already have customers from 36 different countries and are seeing traffic from even more. When it comes to critical tools like signature platforms, having a user interface in your native language can make all the difference. No matter who and where you are, your team deserves tools that are fully accessible and intuitive. That’s why we’re making it our goal to support every language, and we need your help to make it happen! We’re building Documenso as a truly global public commodity.
|
||||
|
||||
## The Vision Behind Project Babel
|
||||
|
||||
The goal of Project Babel is simple but bold: We want to out-ship and out-customize every other document signing tool worldwide. How? By leveraging the collective power of our global community.
|
||||
|
||||
Unlike closed-source software, where localization means waiting for updates from the core team, Project Babel lets anyone contribute a new language, improve an existing translation, or customize the experience to meet local cultural nuances. This flexibility isn’t just a bonus—it’s the baseline for truly global products.
|
||||
|
||||
Through Project Babel, you can help make Documenso the most inclusive e-signature tool. Whether by adding a language you speak or fine-tuning existing translations, you’re shaping a platform that works for everyone, everywhere.
|
||||
|
||||
## How You Can Contribute
|
||||
|
||||
We’ve created a simple GitHub-based contribution flow to get started. We’ll improve the flow and user experience as the project progresses. As always, your contributions are highly valued.
|
||||
|
||||
Check out the contribution guide here: [https://documen.so/babel-fish](https://documen.so/babel-fish)
|
||||
|
||||
## Open Source Makes It Possible
|
||||
|
||||
Closed-source solutions can’t keep up with the speed or depth of customization that open source offers. While other companies might take months or years to localize their products, Documenso can adapt and grow in real-time, thanks to contributions from our community. Whether it’s a small regional dialect or a widely spoken language, Project Babel ensures that Documenso evolves to meet the needs of people everywhere.
|
||||
|
||||
> More importantly, this initiative empowers users. It allows you to control your software experience, ensuring it reflects your culture, language, and unique needs.
|
||||
|
||||
Project Babel is more than a localization effort—it’s the first step toward democratizing access to highly customized software for everyone, no matter where they are or what language they speak. We’re incredibly excited about this initiative, but it can only succeed with your participation. We invite you to join us in making Documenso the most linguistically inclusive platform out there.
|
||||
|
||||
Ready to get started? Check out the full tutorial and become part of the Babel community today! Let’s build open signing for the world: https://documen.so/babel-fish
|
||||
|
||||
If you have any questions or comments, reach out on [Twitter / X](https://twitter.com/eltimuro) (DMs open) or [Discord](https://documen.so/discord).
|
||||
|
||||
Thinking about switching to a modern signing platform? Reach out anytime: [https://documen.so/sales](https://documen.so/sales)
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,292 +0,0 @@
|
||||
---
|
||||
title: 'Building the Documenso Public API - The Why and How'
|
||||
description: 'This article talks about the need for the public API and the process of building it. It also discusses the requirements we had to meet and the constraints we had to work within.'
|
||||
authorName: 'Catalin'
|
||||
authorImage: '/blog/blog-author-catalin.webp'
|
||||
authorRole: 'I like to code and write'
|
||||
date: 2024-03-08
|
||||
tags:
|
||||
- Development
|
||||
- API
|
||||
---
|
||||
|
||||
This article covers the process of building the public API for Documenso. It starts by explaining why the API was needed for a digital document signing company in the first place. Then, it'll dive into the steps we took to build it. Lastly, it'll present the requirements we had to meet and the constraints we had to work within.
|
||||
|
||||
## Why the public API
|
||||
|
||||
We decided to build the public API to open a new way of interacting with Documenso. While the web app does the job well, there are use cases where it's not enough. In those cases, the users might want to interact with the platform programmatically. Usually, that's for integrating Documenso with other applications.
|
||||
|
||||
With the new public API that's now possible. You can integrate Documenso's functionalities within other applications to automate tasks, create custom solutions, and build custom workflows, to name just a few.
|
||||
|
||||
The API provides 12 endpoints at the time of writing this article:
|
||||
|
||||
- (GET) `/api/v1/documents` - retrieve all the documents
|
||||
- (POST) `/api/v1/documents` - upload a new document and getting a presigned URL
|
||||
- (GET) `/api/v1/documents/{id}` - fetch a specific document
|
||||
- (DELETE) `/api/v1/documents/{id}` - delete a specific document
|
||||
- (POST) `/api/v1/templates/{templateId}/create-document` - create a new document from an existing template
|
||||
- (POST) `/api/v1/documents/{id}/send` - send a document for signing
|
||||
- (POST) `/api/v1/documents/{id}/recipients` - create a document recipient
|
||||
- (PATCH) `/api/v1/documents/{id}/recipients/{recipientId}` - update the details of a document recipient
|
||||
- (DELETE) `/api/v1/documents/{id}/recipients/{recipientId}` - delete a specific recipient from a document
|
||||
- (POST) `/api/v1/documents/{id}/fields` - create a field for a document
|
||||
- (PATCH) `/api/v1/documents/{id}/fields` - update the details of a document field
|
||||
- (DELETE) `/api/v1/documents/{id}/fields` - delete a field from a document
|
||||
|
||||
> Check out the [API documentation](https://app.documenso.com/api/v1/openapi).
|
||||
|
||||
Moreover, it also enables us to enhance the platform by bringing other integrations to Documenso, such as Zapier.
|
||||
|
||||
In conclusion, the new public API extends Documenso's capabilities, provides more flexibility for users, and opens up a broader world of possibilities.
|
||||
|
||||
## Picking the right approach & tech
|
||||
|
||||
Once we decided to build the API, we had to choose the approach and technologies to use. There were 2 options:
|
||||
|
||||
1. Build an additional application
|
||||
2. Launch the API in the existing codebase
|
||||
|
||||
### 1. Build an additional application
|
||||
|
||||
That would mean creating a new codebase and building the API from scratch. Having a separate app for the API would result in benefits such as:
|
||||
|
||||
- lower latency responses
|
||||
- supporting larger field uploads
|
||||
- separation between the apps (Documenso and the API)
|
||||
- customizability and flexibility
|
||||
- easier testing and debugging
|
||||
|
||||
This approach has significant benefits. However, one major drawback is that it requires additional resources.
|
||||
|
||||
We'd have to spend a lot of time just on the core stuff, such as building and configuring the basic server. After that, we'd spend time implementing the endpoints and authorization, among other things. When the building is done, there will be another application to deploy and manage. All of this would stretch our already limited resources.
|
||||
|
||||
So, we asked ourselves if there is another way of doing it without sacrificing the API quality and the developer experience.
|
||||
|
||||
### 2. Launch the API in the existing codebase
|
||||
|
||||
The other option was to launch the API in the existing codebase. Rather than writing everything from scratch, we could use most of our existing code.
|
||||
|
||||
Since we're using tRPC for our internal API (backend), we looked for solutions that work well with tRPC. We narrowed down the choices to:
|
||||
|
||||
- [trpc-openapi](https://github.com/jlalmes/trpc-openapi)
|
||||
- [ts-rest](https://ts-rest.com/)
|
||||
|
||||
Both technologies allow you to build public APIs. The `trpc-openapi` technology allows you to easily turn tRPC procedures into REST endpoints. It's more like a plugin for tRPC.
|
||||
|
||||
On the other hand, `ts-rest` is more of a standalone solution. `ts-rest` enables you to create a contract for the API, which can be used both on the client and server. You can consume and implement the contract in your application, thus providing end-to-end type safety and RPC-like client.
|
||||
|
||||
> You can see a [comparison between trpc-openapi and ts-rest](https://catalins.tech/public-api-trpc/) here.
|
||||
|
||||
So, the main difference between the 2 is that `trpc-openapi` is like a plugin that extends tRPC's capabilities, whereas `ts-rest` provides the tools for building a standalone API.
|
||||
|
||||
### Our choice
|
||||
|
||||
After analyzing and comparing the 2 options, we decided to go with `ts-rest` because of its benefits. Here's a paragraph from the `ts-rest` documentation that hits the nail on the head:
|
||||
|
||||
> tRPC has many plugins to solve this issue by mapping the API implementation to a REST-like API, however, these approaches are often a bit clunky and reduce the safety of the system overall, ts-rest does this heavy lifting in the client and server implementations rather than requiring a second layer of abstraction and API endpoint(s) to be defined.
|
||||
|
||||
## API Requirements
|
||||
|
||||
We defined the following requirements for the API:
|
||||
|
||||
- The API should use path-based versioning (e.g. `/v1`)
|
||||
- The system should use bearer tokens for API authentication
|
||||
- The API token should be a random string of 32 to 40 characters
|
||||
- The system should hash the token and store the hashed value
|
||||
- The system should only display the API token when it's created
|
||||
- The API should have self-generated documentation like Swagger
|
||||
- Users should be able to create an API key
|
||||
- Users should be able to choose a token name
|
||||
- Users should be able to choose an expiration date for the token
|
||||
- User should be able to choose between 7 days, 1 month, 3 months, 6 months, 12 months, never
|
||||
- System should display all the user's tokens in the settings page
|
||||
- System should display the token name, creation date, expiration date and a delete button
|
||||
- Users should be able to delete an API key
|
||||
- Users should be able to retrieve all the documents from their account
|
||||
- Users should be able to upload a new document
|
||||
- Users should receive an S3 pre-signed URL after a successful upload
|
||||
- Users should be able to retrieve a specific document from their account by its id
|
||||
- Users should be able to delete a specific document from their account by its id
|
||||
- Users should be able to create a new document from an existing document template
|
||||
- Users should be able to send a document for signing to 1 or more recipients
|
||||
- Users should be able to create a recipient for a document
|
||||
- Users should be able to update the details of a recipient
|
||||
- Users should be able to delete a recipient from a document
|
||||
- Users should be able to create a field (e.g. signature, email, name, date) for a document
|
||||
- Users should be able to update a field for a document
|
||||
- Users should be able to delete a field from a document
|
||||
|
||||
## Constraints
|
||||
|
||||
We also faced the following constraints while developing the API:
|
||||
|
||||
**1. Resources**
|
||||
|
||||
Limited resources were one of the main constraints. We're a new startup with a relatively small team. Building and maintaining an additional application would strain our limited resources.
|
||||
|
||||
**2. Technology stack**
|
||||
|
||||
Another constraint was the technology stack. Our tech stack includes TypeScript, Prisma, and tRPC, among others. We also use Vercel for hosting.
|
||||
|
||||
As a result, we wanted to use technologies we are comfortable with. This allowed us to leverage our existing knowledge and ensured consistency across our applications.
|
||||
|
||||
Using familiar technologies also meant we could develop the API faster, as we didn't have to spend time learning new technologies. We could also leverage existing code and tools used in our main application.
|
||||
|
||||
It's worth mentioning that this is not a permanent decision. We're open to moving the API to another codebase/tech stack when it makes sense (e.g. API is heavily used and needs better performance).
|
||||
|
||||
**3. File uploads**
|
||||
|
||||
Due to our current architecture, we support file uploads with a maximum size of 50 MB. To circumvent this, we created an additional step for uploading documents.
|
||||
|
||||
Users make a POST request to the `/api/v1/documents` endpoint and the API responds with an S3 pre-signed URL. The users then make a 2nd request to the pre-signed URL with their document.
|
||||
|
||||
## How we built the API
|
||||
|
||||

|
||||
|
||||
Our codebase is a monorepo, so we created a new API package in the `packages` directory. It contains both the API implementation and its documentation. The main 2 blocks of the implementation consist of the API contract and the code for the API endpoints.
|
||||
|
||||

|
||||
|
||||
In a few words, the API contract defines the API structure, the format of the requests and responses, how to authenticate API calls, the available endpoints and their associated HTTP verbs. You can explore the [API contract](https://github.com/documenso/documenso/blob/main/packages/api/v1/contract.ts) on GitHub.
|
||||
|
||||
Then, there's the implementation part, which is the actual code for each endpoint defined in the API contract. The implementation is where the API contract is brought to life and made functional.
|
||||
|
||||
Let's take the endpoint `/api/v1/documents` as an example.
|
||||
|
||||
```ts
|
||||
export const ApiContractV1 = c.router(
|
||||
{
|
||||
getDocuments: {
|
||||
method: 'GET',
|
||||
path: '/api/v1/documents',
|
||||
query: ZGetDocumentsQuerySchema,
|
||||
responses: {
|
||||
200: ZSuccessfulResponseSchema,
|
||||
401: ZUnsuccessfulResponseSchema,
|
||||
404: ZUnsuccessfulResponseSchema,
|
||||
},
|
||||
summary: 'Get all documents',
|
||||
},
|
||||
...
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
The API contract specifies the following things for `getDocuments`:
|
||||
|
||||
- the allowed HTTP request method is GET, so trying to make a POST request, for example, results in an error
|
||||
- the path is `/api/v1/documents`
|
||||
- the query parameters the user can pass with the request
|
||||
- in this case - `page` and `perPage`
|
||||
- the allowed responses and their schema
|
||||
- `200` returns an object containing an array of all documents and a field `totalPages`, which is self-explanatory
|
||||
- `401` returns an object with a message such as "Unauthorized"
|
||||
- `404` returns an object with a message such as "Not found"
|
||||
|
||||
The implementation of this endpoint needs to match the contract completely; otherwise, `ts-rest` will complain, and your API might not work as intended.
|
||||
|
||||
The `getDocuments` function from the `implementation.ts` file runs when the user hits the endpoint.
|
||||
|
||||
```ts
|
||||
export const ApiContractV1Implementation = createNextRoute(ApiContractV1, {
|
||||
getDocuments: authenticatedMiddleware(async (args, user, team) => {
|
||||
const page = Number(args.query.page) || 1;
|
||||
const perPage = Number(args.query.perPage) || 10;
|
||||
|
||||
const { data: documents, totalPages } = await findDocuments({
|
||||
page,
|
||||
perPage,
|
||||
userId: user.id,
|
||||
teamId: team?.id,
|
||||
});
|
||||
|
||||
return {
|
||||
status: 200,
|
||||
body: {
|
||||
documents,
|
||||
totalPages,
|
||||
},
|
||||
};
|
||||
}),
|
||||
...
|
||||
});
|
||||
```
|
||||
|
||||
There is a middleware, too, `authenticatedMiddleware`, that handles the authentication for API requests. It ensures that the API token exists and the token used has the appropriate privileges for the resource it accesses.
|
||||
|
||||
That's how the other endpoints work as well. The code differs, but the principles are the same. You can explore the [API implementation](https://github.com/documenso/documenso/blob/main/packages/api/v1/implementation.ts) and the [middleware code](https://github.com/documenso/documenso/blob/main/packages/api/v1/middleware/authenticated.ts) on GitHub.
|
||||
|
||||
### Documentation
|
||||
|
||||
For the documentation, we decided to use Swagger UI, which automatically generates the documentation from the OpenAPI specification.
|
||||
|
||||
The OpenAPI specification describes an API containing the available endpoints and their HTTP request methods, authentication methods, and so on. Its purpose is to help both machines and humans understand the API without having to look at the code.
|
||||
The Documenso OpenAPI specification is live [here](https://documenso.com/api/v1/openapi.json).
|
||||
|
||||
Thankfully, `ts-rest` makes it seamless to generate the OpenAPI specification.
|
||||
|
||||
```ts
|
||||
import { generateOpenApi } from '@ts-rest/open-api';
|
||||
|
||||
import { ApiContractV1 } from './contract';
|
||||
|
||||
export const OpenAPIV1 = generateOpenApi(
|
||||
ApiContractV1,
|
||||
{
|
||||
info: {
|
||||
title: 'Documenso API',
|
||||
version: '1.0.0',
|
||||
description: 'The Documenso API for retrieving, creating, updating and deleting documents.',
|
||||
},
|
||||
},
|
||||
{
|
||||
setOperationId: true,
|
||||
},
|
||||
);
|
||||
```
|
||||
|
||||
Then, the Swagger UI takes the OpenAPI specification as a prop and generates the documentation. The code below shows the component responsible for generating the documentation.
|
||||
|
||||
```ts
|
||||
'use client';
|
||||
|
||||
import SwaggerUI from 'swagger-ui-react';
|
||||
import 'swagger-ui-react/swagger-ui.css';
|
||||
|
||||
import { OpenAPIV1 } from '@documenso/api/v1/openapi';
|
||||
|
||||
export const OpenApiDocsPage = () => {
|
||||
return <SwaggerUI spec={OpenAPIV1} displayOperationId={true} />;
|
||||
};
|
||||
|
||||
export default OpenApiDocsPage;
|
||||
```
|
||||
|
||||
Lastly, we create an API endpoint to display the Swagger documentation. The code below dynamically imports the `OpenApiDocsPage` component and displays it.
|
||||
|
||||
```ts
|
||||
'use client';
|
||||
|
||||
import dynamic from 'next/dynamic';
|
||||
|
||||
const Docs = dynamic(async () => import('@documenso/api/v1/api-documentation'), {
|
||||
ssr: false,
|
||||
});
|
||||
|
||||
export default function OpenApiDocsPage() {
|
||||
return <Docs />;
|
||||
}
|
||||
```
|
||||
|
||||
You can access and play around with the documentation at [documenso.com/api/v1/openapi](https://documenso.com/api/v1/openapi). You should see a page like the one shown in the screenshot below.
|
||||
|
||||

|
||||
|
||||
> This article shows how to [generate Swagger documentation for a Next.js API](https://catalins.tech/generate-swagger-documentation-next-js-api/).
|
||||
|
||||
So, that's how we went about building the first iteration of the public API after taking into consideration all the constraints and the current needs. The [GitHub pull request for the API](https://github.com/documenso/documenso/pull/674) is publicly available on GitHub. You can go through it at your own pace.
|
||||
|
||||
## Conclusion
|
||||
|
||||
The current architecture and approach work well for our current stage and needs. However, as we continue to grow and evolve, our architecture and approach will likely need to adapt. We monitor API usage and performance regularly and collect feedback from users. This enables us to find areas for improvement, understand our users' needs, and make informed decisions about the next steps.
|
||||
@ -1,56 +0,0 @@
|
||||
---
|
||||
title: 'Embracing the Future and Moving Back Again: From Server Actions to tRPC'
|
||||
description: 'This article talks about the need for the public API and the process of building it. It also talks about the requirements, constraints, challenges and lessons learnt from building it.'
|
||||
authorName: 'Lucas Smith'
|
||||
authorImage: '/blog/blog-author-lucas.png'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-03-07
|
||||
tags:
|
||||
- Development
|
||||
---
|
||||
|
||||
On October 26, 2022, during the Next.js Conf, Vercel unveiled Next.js 13, introducing a bunch of new features and a whole new paradigm shift for creating Next.js apps.
|
||||
|
||||
React Server Components (RSCs) have been known for some time but haven't yet been implemented in a React meta-framework. With Next.js now adding them, the world of server-side rendering React applications was about to change.
|
||||
|
||||
## The promise of React Server Components
|
||||
|
||||
Described by Vercel as a tool for writing UIs rendered or optionally cached on the server, RSC promised direct integration with databases and server-specific capabilities, a departure from the typical React and SSR models.
|
||||
|
||||
This feature initially appeared as a game-changer, promising simpler data fetching and routing, thanks to async server components and additional nested layout support.
|
||||
|
||||
After experimenting with it for about six months on other projects, I came to the conclusion that while it was a little rough at the edges, it was indeed a game changer and something that should be adopted in Next.js projects moving forward.
|
||||
|
||||
## A new new paradigm: Server Actions
|
||||
|
||||
Vercel didn't stop at adding Server Components. A short while after the initial Next.js 13 release, they introduced "Server Actions." Server Actions allow for the calling of server-side functions without API routes, reducing the amount of ceremony required for adding a new mutation or event to your application.
|
||||
|
||||
## Betting on new technology
|
||||
|
||||
Following the release of both Server Actions and Server Components, we at Documenso embarked on a rewrite of the application. We had accumulated a bit of technical debt from the initial MVP, which was best shed as we also improved the design with help from our new designer.
|
||||
|
||||
Having had much success with Server Components on other projects, I opted to go all in on both Server Components and Server Actions for the new version of the application. I was excited to see how much simpler and more efficient the application would be with these new technologies.
|
||||
|
||||
Following our relaunch, we felt quite happy with our choices of server actions, which even let us cocktail certain client—and server-side logic into a single component without needing a bunch of effort on our end.
|
||||
|
||||
## Navigating challenges with Server Actions
|
||||
|
||||
While initially successful, we soon encountered issues with Server Actions, particularly when monitoring the application. Unfortunately, server actions make it much harder to monitor network requests and identify failed server actions since they use the route that they are currently on.
|
||||
|
||||
Despite this issue, things were manageable; however, a critical issue arose when the usage of server actions caused bundle corruption, resulting in a top-level await insertion that would cause builds and tests to fail.
|
||||
|
||||
This last issue was a deal breaker since it highlighted how much magic we were relying on with server actions. I like to avoid adding more magic where possible since, with bundlers and meta-frameworks, we are already handing off a lot of heavy lifting and getting a lot of magic in return.
|
||||
|
||||
## Going all in on tRPC
|
||||
|
||||
My quick and final solution to the issues we were facing was to fully embrace [tRPC](https://trpc.io/), which we already used in other app areas. The migration took less than a day and resolved all our issues while adding a lot more visibility to failing actions since they now had a dedicated API route.
|
||||
|
||||
For those unfamiliar with tRPC, it is a framework for building end-to-end typesafe APIs with TypeScript and Next.js. It's an awesome library that lets you call your defined API safely within the client, causing build time errors when things inevitably drift.
|
||||
|
||||
I've been a big fan of tRPC for some time now, so the decision to drop server actions and instead use more of tRPC was easy for me.
|
||||
|
||||
## Lessons learned and the future
|
||||
|
||||
While I believe server actions are a great idea, and I'm sure they will be improved in the future, I've relearned the lesson that it's best to avoid magic where possible.
|
||||
|
||||
This doesn't mean we won't consider moving certain things back to server actions in the future. But for now, we will wait and watch how others use them and how they evolve.
|
||||
@ -1,64 +0,0 @@
|
||||
---
|
||||
title: Merch Mania
|
||||
description: Happy Launch Week Day 3. The limited edition "Malfunction Mania" shirt is here. Grab it, while you can.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2023-09-27
|
||||
tags:
|
||||
- Merch
|
||||
- Rewrite
|
||||
- Bounties
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/mania-shirt.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="Malfunctioning Mania Themed Documenso Shirt"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
The Limited Edition "Malfunction Mania" Shirt - Only during Malfunction Mania
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; We have a fancy limited edition shirt. Contribute to [Malfunction Mania](https://documenso.com/blog/malfunction-mania) to get one.
|
||||
|
||||
We kicked off [Malfunction Mania](https://documenso.com/blog/malfunction-mania) yesterday, and the first [issues](https://github.com/documenso/documenso/issues) are coming in. As mentioned, there will be dollar bounties, but we also wanted to celebrate entering the final stage of version 1.0 with something special. This is why we created this limited edition shirt. It will only be available during the runtime of Malfunction Mania. We have yet to set an exact end date, the next event in October, however, is looming, ready to end MM.
|
||||
|
||||
## Documenso Merch Shop
|
||||
|
||||
The shirt will be available in our [merch shop](https://documen.so/shop) via a unique discount code. While the shirt will be gone after Malfunction Mania, the shop is here to stay and provide a well-deserved reward for great community members and contributors. All items can be earned by contributing to Documenso.
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/shop.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="Malfunctioning Mania Themed Documenso Shirt"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Merch at Documenso is always given to those who deserve it.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
## How earn the shirt
|
||||
|
||||
If you have been following us, you know we are not big on formalities but highly value rewarding merit. That being said, any worthwhile contribution has a chance to get one. To inspire, here are a few ideas on how to contribute to securing one:
|
||||
|
||||
- Report a bug with detailed reproduction details
|
||||
- Fix a bug (you or somebody else reported)
|
||||
- Analyze and describe a usability or user experience shortcoming
|
||||
- Test the product in a systematic and least somewhat documented way
|
||||
- Engage in discussion about the current version and its choices
|
||||
- Raise awareness for Malfunction Mania and try out the [version currently in staging](https://documen.so/staging)
|
||||
- Review the version with a video, stream, or screenshots and post about it
|
||||
- Review existing or create missing documentation
|
||||
|
||||
Best from Hamburg
|
||||
Timur
|
||||
|
||||
**[Follow Documenso on Twitter / X](https://documen.so/tw) and [join the Discord server](https://documen.so/discord) to get the latest updates about Malfunction Mania.**
|
||||
@ -1,95 +0,0 @@
|
||||
---
|
||||
title: How to Sign an NDA online (fast)
|
||||
description: Signing an NDA with Documenso direct links is amazingly fast. Let’s look at how to make it even faster.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-06-27
|
||||
tags:
|
||||
- NDA
|
||||
- Direct Links
|
||||
- Productivity
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/nda.jpg"
|
||||
width="1400"
|
||||
height="884"
|
||||
alt="Direct Links in Templates List View"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">A generic document saying "NDA" to underline this article is about NDAs.</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; Documenso makes sending NDAs faster, faster with templates, and even still faster using direct links.
|
||||
|
||||
## What is an NDA?
|
||||
|
||||
An NDA, or non-disclosure agreement, is a legal contract that establishes a confidential relationship. The parties involved agree not to disclose information covered by the agreement. NDAs are often used to protect sensitive information or trade secrets and to ensure that such information isn't made public by the recipient without permission. They are commonly used in business settings, such as during negotiations or when new employees are hired who will have access to proprietary information.
|
||||
|
||||
## Do I need an NDA?
|
||||
|
||||
> Disclaimer: This is not legal advice, and the most important legal questions are often ultra-case-specific and should be discussed with a legal professional
|
||||
|
||||
There is a solid amount of debate around the question of whether an NDA actually protects anyone and is worth the friction. Investors scoff at the idea of a startup requiring them to sign an NDA before disclosing their "billion dollar idea" as they see hundreds of them and are aware that without proper execution, there is nothing to protect.
|
||||
|
||||
In another classical example, a big company and a small company e.g. a startup, sign an NDA before going into detail for partnership talks. While this seems prudent, given the resource asymmetry, the startup probably won't be able to litigate against breach of contract successfully. If Microsoft (not saying they do) breaks your NDA, you will hardly sue them into a settlement.
|
||||
|
||||
That being said, as with most contracts, NDAs can be useful if both parties keep the spirit of the agreement. In this case, detailing in writing what can and cannot be disclosed is good for managing expectations and building trust. NDAs are also common practice in merger and acquisition projects and are often part of hiring critical roles within a company.
|
||||
|
||||
### Level 1: Basic Signing
|
||||
|
||||
If you need to sign an NDA, signing it with Documenso is incredibly fast already. Let's take a look at how to make it even faster. Simply uploading and sending is the most straightforward way to get this done. It works like this:
|
||||
|
||||
- Upload the NDA PDF template
|
||||
- Add the recipients
|
||||
- place the signature fields
|
||||
- Hit send
|
||||
- Sign the NDA while or after waiting for your counterpart to sign
|
||||
|
||||
<video
|
||||
id="vid"
|
||||
width="100%"
|
||||
src="https://github.com/documenso/design/raw/main/blog/nda1.webm"
|
||||
autoPlay
|
||||
loop
|
||||
muted
|
||||
controls
|
||||
></video>
|
||||
|
||||
### Level 2: Using Templates
|
||||
|
||||
If you have to sign the same NDA multiple times with different people, you can create a template to save time. Creating a template is just as easy as creating a document, just skipping the sending step. After creating the template for your NDA, you can create a signable document with just 1 click. Simply fill in the recipient email, and you are done.
|
||||
|
||||
> Pro Tip: Check "Send Document" to immediately send it after filling out the recipient if you are familiar with the template.
|
||||
|
||||
<video
|
||||
id="vid"
|
||||
width="100%"
|
||||
src="https://github.com/documenso/design/raw/main/blog/nda2.webm"
|
||||
autoPlay
|
||||
loop
|
||||
muted
|
||||
controls
|
||||
></video>
|
||||
<figcaption className="text-center">
|
||||
You can send out templates without even going through the full flow.
|
||||
</figcaption>
|
||||
|
||||
### Level 3: Using a Direct Link
|
||||
|
||||
Using a pre-defined template is pretty fast, but can we make it even faster? Yes, we can! By adding a direct link to your NDA template and publishing it (internally or even externally). A [Direct Link](http://documenso.com/blog/announcing-direct-links) lets people sign your NDA without you lifting a finger. Everyone with access to the link can sign it at any time, making discussions of who sends what when a thing of the past. You can use Direct links with a pre-signed template for maximum convenience or with a second signer/ approver from your side to keep control over the process.
|
||||
|
||||
You can try it here and [sign a demo NDA](https://documen.so/demo-nda) with me.
|
||||
|
||||
> Pro Tip: Use [Zapier](https://documen.so/zapier) to get notified of that platform of your choice as soon as someone signs your link.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Signing NDAs is not always effective, but it can be necessary, so be sure to use a tool to make it easy and fast. Documenso is a great DocuSign alternative that helps you get it done. If you need to get an NDA out today, you can use the [Documenso Free plan](https://documen.so/free), which gives you 5 signatures per month and 3 Direct Link templates.
|
||||
|
||||
As always, we want to hear from you on [Twitter / X](https://twitter.com/eltimuro) (DMs are open) or [Discord](https://documen.so/discord) if you have any questions, ideas, or comments.
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,52 +0,0 @@
|
||||
---
|
||||
title: Sunsetting the Early Adopters Plan
|
||||
description: We reached or Early Adopter cap and not transition to our regular pricing 🎉
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-06-12
|
||||
tags:
|
||||
- Early Adopters
|
||||
- Pricing
|
||||
- Open Startup
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/sunset.jpg"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="A beautiful sunset as a metaphor for the Early Adopter phase ending"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
"Being early is, uh, good." -Unknown
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; The Early Adopters Plan ended, and we have a new pricing. If you are an Early Adopter, reach out for a Discord community badge 🏅
|
||||
|
||||
# The End of the Beginning
|
||||
|
||||
12 months, 13 releases, and 344 merged pull requests after announcing the Early Adopter plan in our first-ever launch week, and we hit the cap of 100. Documenso has changed and grown a lot since then. For us, this is a great milestone towards our broader mission of bringing open signing to the world since now we are joined by a community consisting of contributors and early customers all around the world.
|
||||
|
||||
# The New Plans
|
||||
|
||||
Starting today, we are sunsetting the Early Adopter Plan in favor of our new, more nuanced pricing model. The Early Adopter plan will succeeded by the **Individual plan**, which is still priced at $30/mo. The Individual plans will still include unlimited signatures and recipients since this aligns with our core belief of empowering our users wherever possible. If you managed to grab an Early Adopter plan, reach out on X or Discord to receive a special community badge. Early Adopters are meant to get preferential treatment where possible.
|
||||
|
||||
Previously soft-launched as part of Early Adopters, we are officially introducing the **Team Plan** to our pricing for customers requiring multi-user accounts. Priced at $50/ mo. for 5 users, this plan offers unlimited signature volume as well. Additional users can be added for $10/mo. as needed. We have carefully crafted the billing of teams to ensure that dynamic changes are accurately reflected at the end of each billing cycle, providing you with a fair-value pricing structure.
|
||||
|
||||
Our **Free Plan** stays unchanged, offering coverage to casual users and an easy way to try out Documenso or start developing.
|
||||
|
||||
Check out our [new pricing page here](https://documen.so/pricing). We also updated our [open page](https://documen.so/open) to reflect the end of Early Adopters. The metric now counts active subscriptions from Individuals and Teams.
|
||||
|
||||
# API Access
|
||||
|
||||
All plans include access to the API as per our philosophy, making Documenso an open platform, and allowing everyone to build on it, no matter how big or small. Besides the Free Plan's 5 signatures per month limit, the API does not have access restrictions. Even the free plan can keep using the API after using its signature volume for non-signing operations like reading, editing, and even creating documents. Since the individual plan technically allows for running a Fortune 500 company for $30/ mo., plan we are adding a fair use clause here: You are free to use the API "a lot" if you are a big organization trying to stay on the Individual Plan we will ask to have a word about upgrading (which might make sense anyway considering your requirements). Fair use excludes Early Adopters, which we consider limitless by any measure. If you need clarification on whether your case is covered under fair use, you can contact us on Discord or support@documenso.com. It's probably fine, though.
|
||||
|
||||
We also have a lot in the pipeline, and we are excited to share everything with you soon. A Big Shoutout to all Early Adopters. We salute you, and you will receive the preferred treatment where possible.
|
||||
|
||||
If you have any questions or comments, please reach out on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord).
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,136 +0,0 @@
|
||||
---
|
||||
title: Switching to Discord
|
||||
description: The Documenso community is growing and we feel the need to have a more community and developer-friendly environment. We're switching to Discord.
|
||||
authorName: 'Flo Merian'
|
||||
authorImage: '/blog/blog-author-flo.jpeg'
|
||||
authorRole: 'Go-to-market'
|
||||
date: 2023-08-02
|
||||
tags:
|
||||
- Announcement
|
||||
- Community
|
||||
---
|
||||
|
||||
We’re switching to Discord.
|
||||
|
||||
Documenso is an open-source DocuSign alternative, built with community and transparency in mind.
|
||||
|
||||
So, when we started working on the project, we quickly set up a Slack workspace to start engaging with community members.
|
||||
|
||||
As the community grows (reached 2K stars on GitHub and 100 community members on Slack), we felt the need to set up a more community-friendly environment.
|
||||
|
||||
The Documenso team is growing, too. [Lucas joined Timur](https://twitter.com/ElTimuro/status/1648608988391514112), then [Ephraim](https://twitter.com/documenso/status/1662418374243041280) and [David](https://github.com/dguyen) recently joined the journey. We want to stay in touch with the community as much as possible and avoid context-switching to focus on work, support, and fun.
|
||||
|
||||
We’re an open-source project and focus on building a great developer experience. So, when we thought of a Slack replacement, community and developer-friendly, Discord was an obvious choice — not to mention that it would help us keep up with [OSS friends](https://documen.so/oss), too.
|
||||
|
||||
So, we’re switching all conversations, team and community-wide, to Discord.
|
||||
|
||||
In this post, we won’t debate _why_ we’re switching — Slack vs. Discord is a long-lasting debate with pros and cons, and fans on both sides. There are great [stories](https://blog.meilisearch.com/from-slack-to-discord-our-migration/) and [threads](https://twitter.com/McPizza0/status/1655519558600470528) on the topic. We just don’t want to write yet another story here.
|
||||
|
||||
Instead, we’ll focus on _how_ we plan to make the switch.
|
||||
|
||||
## Who is this story for?
|
||||
|
||||
First, we wrote this post for the team so we’re ready for the switch. Then we post it online because we value transparency and thought it might help the community.
|
||||
|
||||
For community members, this story would help you understand how we plan to make the switch and give you the guidance to fully embrace the new experience.
|
||||
|
||||
For founders and makers who would like to switch too, in one way or another, this story would help you handle the transition with a detailed guide.
|
||||
|
||||
## Switching to Discord
|
||||
|
||||
We’re switching to Discord, step by step. First, we’re moving team conversations, then we’re moving the community with a 15-day buffering.
|
||||
|
||||
The detailed plan goes like this:
|
||||
|
||||
- 2023-07-25 `t=0`: Timur starts setting up the Discord server and sends invites to the team.
|
||||
- 2023-07-26 `t+1`: The team switches to Discord. The objective is to get used to the product and to customize it to feel at home and, when we’re ready to welcome the community, to make new members feel at home, too.
|
||||
- 2023-08-02 `t+8`: We announce to the community the upcoming changes in the different channels — GitHub, Twitter, and Slack.
|
||||
|
||||
- **GitHub**
|
||||
|
||||
- Create new Pull Request
|
||||
- Add story to the blog
|
||||
- Update link to the community
|
||||
```
|
||||
https://documen.so/discord
|
||||
```
|
||||
- Start a new Discussion
|
||||
|
||||
```markdown
|
||||
Happy Wednesday!
|
||||
|
||||
TL,DR: We’re switching to Discord. [Join the fun!](https://documen.so/discord)
|
||||
|
||||
We want to build a beautiful, open-source DocuSign alternative. As we're growing (reached 2.3K Stars), we feel the need to have a more community- and developer-friendly environment to share ideas, support, and memes.
|
||||
|
||||
Make sure to join the server to keep up to date on all things Documenso.
|
||||
|
||||
Oh and, spoiler alert, there may be some swag there 👀
|
||||
|
||||
See you there!
|
||||
Flo
|
||||
```
|
||||
|
||||
- **Twitter**
|
||||
|
||||
- [Tweet the announcement](https://twitter.com/documenso/status/1686719482096766977)
|
||||
- Pin Tweet
|
||||
- Update link in bio
|
||||
|
||||
```
|
||||
The Open Source DocuSign Alternative.
|
||||
|
||||
http://documen.so/github
|
||||
http://documen.so/discord
|
||||
http://documen.so/manifest
|
||||
ㅤ
|
||||
```
|
||||
|
||||
- **Slack**
|
||||
|
||||
- Post message in `#general`
|
||||
|
||||
```markdown
|
||||
Happy Wednesday!
|
||||
|
||||
TL,DR: We’re switching to Discord. [Join the fun!](https://documen.so/discord)
|
||||
|
||||
We want to build a beautiful, open-source DocuSign alternative. As we're growing (reached 2.3K Stars), we feel the need to have a more community- and developer-friendly environment to share ideas, support, and memes.
|
||||
|
||||
Make sure to [join the server](https://documen.so/discord) to keep up to date on all things Documenso.
|
||||
|
||||
Oh and, spoiler alert, there may be some swag there 👀
|
||||
|
||||
See you there!
|
||||
Flo
|
||||
```
|
||||
|
||||
- Pin post
|
||||
- Set topic and description
|
||||
```
|
||||
We're switching to Discord. Join the fun: https://documen.so/discord
|
||||
```
|
||||
- Archive channels: `#code-review` `#how-to` `#meet-and-greet` `#random-memes` `#self-hosting` `#support`
|
||||
|
||||
- 2023-08-09 `t+15`: 7 days later, we send a reminder on Slack.
|
||||
|
||||
- **Slack**
|
||||
|
||||
- Schedule reminder in `#general`
|
||||
|
||||
```
|
||||
Friendly reminder: we're switching to Discord and will soon disconnect this Slack workspace.
|
||||
|
||||
Join the fun! https://documen.so/discord
|
||||
```
|
||||
|
||||
- 2023-08-16 `t+22`: 15 days later, we’re making the final edits to the Slack workspace.
|
||||
- **Slack**
|
||||
- [Edit posting permissions](https://app.slack.com/slackhelp/en-US/360004635551) in `#general`
|
||||
- Disconnect Slack
|
||||
|
||||
## Final thoughts
|
||||
|
||||
- We’re at the very, early stage on our journey to building a beautiful, open-source DocuSign alternative. We want to build a great developer experience with the open-source community and, switching to Discord, we want to set up the foundations of an open, safe place for community members to get in touch, brainstorm ideas, and have fun.
|
||||
- It doesn’t mean we won’t ever switch back to Slack. The tools of today aren’t the ones of tomorrow. We don’t delete the Slack workspace, we archive it, and keep the `documenso` handle. May it be just an _au revoir?_
|
||||
- For now, we’re pushing forward and are eager to welcome you on Discord. Make sure to [join the server](https://documen.so/discord) in order to keep up to date on all things Documenso. See you there!
|
||||
@ -1,54 +0,0 @@
|
||||
---
|
||||
title: Top 3 Signing Efficiency Hacks for Freelancers
|
||||
description: Streamlining signing contracts and paperwork is crucial for freelancers looking to save time and focus on their business. Take a look at these 3 tips on how Documenso can help you.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-07-04
|
||||
tags:
|
||||
- Productivity
|
||||
- Zapier
|
||||
- Direct Links
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/zen.webp"
|
||||
width="1400"
|
||||
height="884"
|
||||
alt="Direct Links in Templates List View"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">Documenso helps you reduce your cognitive load while running your business.</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; Set up notifications using Zapier, use a redirect to send users to the next step, and start working async with direct links.
|
||||
|
||||
Signing all the paperwork of a freelance business can be a headache. Besides adding to the daily workload, it can pull much focus from your core tasks. Let's take a look at how Documenso can help you keep the cognitive load of admin tasks to a minimum:
|
||||
|
||||
## Tip 1: Set Up Notifications
|
||||
|
||||
> At Documenso, we pipe almost everything relevant into Discord. This helps us naturally keep track and start conversations.
|
||||
|
||||
Getting customers and partners to sign off on critical agreements is no easy feat. It's even harder when keeping track forces you to switch between channels (email, WhatsApp, Discord, Slack, Notion, etc.). Setting up custom notifications for read or signed documents can help you keep track naturally. Using the Documenso [Zapier Integration](https://documen.so/zapier) lets you funnel important document events to the place where your focus is. Pipe send, read, and sign notifications directly to your Telegram account. Keep up to date on the go. Sync document completion events to your CRM. Ideally, a signed document does not give you any "homework”. Besides, you are already busy getting started on the actual work.
|
||||
|
||||
## Tip 2: Use Redirects
|
||||
|
||||
Your client signed the deal? Your designer signed their statement of work? Great. Don't risk losing steam getting from one step to the next. Your customers and partners have just as much noise around them as you. Help them to stay on task by doing the next thing easily. Documenso lets you set up redirects to send signers to where they need to go next. Send your newest customer to a booking page for onboarding. Forward your designer to the next briefing you prepared. Keeping up flow is critical; sending everyone where they need to go while in focus mode helps get things done faster.
|
||||
|
||||
## Tip 3: Go Async with Direct Links
|
||||
|
||||
> Try Direct Links by signing our [Supporters Pledge](https://documen.so/pledge)
|
||||
|
||||
Your customer wanting to approve an additional budget is great. It’s so great. In fact, you want to get on it as soon as possible and not have a calm moment until you send them something to sign. Even if you are fast, you are not mind-ready, though. So, what if your customers could do it whenever they like?
|
||||
|
||||
Direct Links lets you set up proposal templates and contracts, which are ready to sign anytime. You can include them in your [initial proposal](https://documen.so/freelance-proposal) or on your [public profile](https://documen.so/profiles). This way, customers can get more of your offering whenever they want.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Setting up notifications, redirects, and direct signing links using your favorite open source DocuSign alternative helps streamline your business and reduce the cognitive load of managing it. You can get everything mentioned here plus 5 free monthly signatures in the [Documenso Free Plan](https://documen.so/free).
|
||||
|
||||
As always, we want to hear from you on [Twitter / X](https://twitter.com/eltimuro) (DMs are open) or [Discord](https://documen.so/discord) if you have any questions, ideas, or comments.
|
||||
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,68 +0,0 @@
|
||||
---
|
||||
title: Why I started Documenso
|
||||
description: I started Documenso because I wanted to build a modern tech company in a growing space with a mission bigger than money, I overpaid for a SSL cert 13 years ago, like encryption and want to help make the internet/ world more open.
|
||||
authorName: 'Timur Ercan'
|
||||
authorImage: '/blog/blog-author-timur.jpeg'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2024-02-06
|
||||
tags:
|
||||
- Founders
|
||||
- Mission
|
||||
- Open Source
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/burgers.jpeg"
|
||||
width="650"
|
||||
height="100"
|
||||
alt="Burgers, drinks on a table between friends."
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Not the burger from the story. But it could be as well, the place is pretty generic.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; I started Documenso because I wanted to build a modern tech company in a growing space with a mission bigger than money, I overpaid for a SSL cert 13 years ago, like encryption, and wanted to help make the world/ Internet more open.
|
||||
|
||||
It's hard to pinpoint when I decided to start Documenso. I first uttered the word "Documenso" while sitting in a restaurant with [Felix](https://twitter.com/flxmgdnz), eating a burger and discussing what's next in late 2022. Shortly after, I sat down with a can of caffeine and started building [Documenso 0.9](https://github.com/documenso/documenso/releases/tag/0.9-developer-preview). Starting Documenso is the most deliberate business decision I ever made. It was deliberate from the personal side and deliberate from the business side.
|
||||
|
||||
Looking at the personal side, I've had some time off and was actively looking for my next move. Looking back, I stumbled into my first company. Less so with the second one, but I joined my co-founders and did not develop the core concept myself. While coming up with Documenso, I was deliberately looking for a few things, based on my previous experiences:
|
||||
|
||||
- An entrepreneurial space that was a big enough opportunity
|
||||
- A huge macro trend, lifting everything in it's space
|
||||
- A mode of working that fits my flow (which, luckily for me, is pretty close to the modern startup/ tech scene)
|
||||
- A more significant impact to be made than just earning lots of money (though there is nothing wrong with that)
|
||||
|
||||
Quick shoutout to everyone feeling even a pinch of imposter syndrome while calling themselves a founder. It was after ten years, slightly after starting Documenso, that I started doing it in my head without cringing. So cut yourself some slack. Considering how long I've been doing this, I would have earned the internal title sooner, and so do you. After grappling with my identity for a second, as is customary for founders, my decision to start this journey came quickly.
|
||||
|
||||
Aside from the personal dimension, I had a clear mindset of what I wanted. The criteria I describe below clicked into place one after another, in no particular order. Having experienced no market demand and a very gritty, grindy market, I was looking for something more fundamental. Something basic, infrastructure-like, with a huge demand. A growing market deeply rooted in the ever-increasing digitalization of the world.
|
||||
|
||||
And to be honest, I just always liked digital signature tools. It's a product that is easy enough to comprehend and build but complex and impactful enough to satisfy a hard need. It's a product you can build very product-driven since the market and domain are well understood. So when asked about what's next for me, I literally said, "Digital, um, let's say… signatures". As it turns out, my first gut feeling was spot on, but how spot on I only realized when I started researching the space. An open source document signing company happens to be the perfect intersection of all the criteria and personal preferences I described above; it's pretty amazing, actually:
|
||||
|
||||
- The global signing market is enormous and rapidly growing
|
||||
- To put it bluntly, the signing space is vast and dominated by one outdated player. Outdated in terms of tech, pricing, and ecosystem
|
||||
- The signing space is also ridiculously opaque for a space based on open web tech, open encryption tech, and open signing standards. Even by closed-source standards
|
||||
- We are currently seeing a renaissance for commercial open source startups, combining venture founder financials with open source mechanics
|
||||
- Rebuilding a fundamental infrastructure as open source with a meaningful scale has a profoundly transformative effect on any space
|
||||
- Working in open source requires being open, cooperative, and inclusive. It also requires quite a bit of context jumping, "going with the flow," and empathy
|
||||
- Apart from fixing the signing space, making Documenso successful would be another domino tile toward open source eating the world, which is great for everyone
|
||||
|
||||
Building a company is so complex it can't be planned out. Basing it on great fundamentals and the expected dynamics is the best founders can do, in my humble opinion. After these fundamental decisions, you are (almost) just along for the ride and need to focus on solving the "conventional" problems of starting a company the best you can. With digital signatures hitting so many points of my personal and professional checklist, this already was a great fit. What got me excited at first, though, apart from the perspective of drinking caffeine and coding, was this:
|
||||
|
||||
Roughly 13 years ago, I was launching my first product. We obviously wanted SSL encryption on the product site, so I had to buy an SSL certificate. ~$200ish, two years validity, from VeriSign, I think. Apart from it being ridiculously complicated to get, it bothered me that we had basically paid $200 for what is essentially a long number someone generated. SSL wasn't even that widespread back then because it was mainly considered important for e-commerce, no wonder considering it cost so much. "Why would I encrypt a blog?". Fast forward to today, and everyone can get a free SSL cert courtesy of [Let's Encrypt](https://letsencrypt.org/) and browsers are basically blocking unencrypted sites. Mostly, it is even built into hosting platforms, so you barely even notice as a developer.
|
||||
|
||||
I had forgotten all about that story until I realized this is where signing is today. A global need fulfilled only by a closed ecosystem, not really state-of-the-art companies, leading to, let's call it, steep prices. I had considered Let's Encrypt a pillar of the open internet for so long that I forgot that they weren't always there. One day, someone said, let's make the internet better. Signing is another domain that should have had an open ecosystem for a long time. Another parallel to that story is the fact that the cryptographic certificates you need for document signing are also stuck in the "pre-Let's Encrypt world." Free document signing certificates via "Let's Sign" are now another to-do on the [long-term roadmap](https://documen.so/roadmap) list for the open signing ecosystem. Effecting this change in any way is a huge driver for me.
|
||||
|
||||
Apart from my personal gripes with the corporate certificate industry, I have always found encryption fascinating. It's such a fundamental force in society when you think about it: Secure Communication, Secure Commerce, and even [internet native, open source money (Bitcoin)](https://github.com/bitcoin/bitcoin) were created using a bit of smart math. All these examples are expressions of very fundamental human behaviors that should be enabled and protected by open infrastructures.
|
||||
|
||||
I never told rthis to anyone before, but since starting Documenso, I realized that I underestimated the impact and importance of open source for quite some time. When I was in University, I distantly remember my mindset of "yeah, open source is nice, but the great, commercially successful products used in the real world are built by closed companies (aka Microsoft)" _shudder_ It was never really a conscious thought, but enough that I started learning MS Silverlight before plain Javascript. It was slowly, over time, that I realized that open web standards are superior to closed ones, and even later, I understood the same holds true for all software. Open source fixes something in the economy I find hard to articulate. I did my best in [Commodifying Signing](https://documenso.com/blog/commodifying-signing).
|
||||
|
||||
To wrap this up, Documenso happens to be the perfect storm of market opportunity, my interests, and my passions. Creating a company in which people want to work for the long term while tackling these issues is a critical side quest of Documenso. This is not only about building the next generation of signing tech; it's also about doing our part to normalize open, healthy, efficient working cultures and tackling relevant problems.
|
||||
|
||||
As always, feel free to connect on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord) if you have any questions, comments, thoughts or feelings.
|
||||
|
||||
\
|
||||
Best from Hamburg\
|
||||
Timur
|
||||
@ -1,113 +0,0 @@
|
||||
---
|
||||
title: Why we're doing a rewrite
|
||||
description: As we move beyond MVP and onto creating the open signing infrastructure we all deserve we need to take a quick pit-stop.
|
||||
authorName: 'Lucas Smith'
|
||||
authorImage: '/blog/blog-author-lucas.png'
|
||||
authorRole: 'Co-Founder'
|
||||
date: 2023-08-05
|
||||
tags:
|
||||
- Community
|
||||
- Development
|
||||
---
|
||||
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/blog-banner-rewrite.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="Next generation documenso"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
The next generation of Documenso and signing infrastructure.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
> TLDR; We're rewriting Documenso to move on from our MVP foundations and create an even better base for the project. This rewrite will provide us the opportunity to fix a few things within the project while enabling a faster development process moving forward.
|
||||
|
||||
# Introduction
|
||||
|
||||
At Documenso, we're building the next generation of signing infrastructure with a focus on making it inclusive and accessible for all. To do this we need to ensure that the software we write is also inclusive and accessible and for this reason we’ve decided to take a step back and perform a _quick_ rewrite.
|
||||
|
||||
Although we've achieved validated MVP status and gained paying customers, we're still quite far from our goal of creating a trusted, open signing experience. To move closer to that future, we need to step back and focus on the project's foundations to ensure we can solve all the items we set out to on our current homepage.
|
||||
|
||||
Fortunately, this wasn't a case of someone joining the team and proposing a rewrite due to a lack of understanding of the codebase and context surrounding it. Prior to joining Documenso as a co-founder, I had spent an extensive amount of time within the Documenso codebase and had a fairly intimate understanding of what was happening for the most part. This knowledge allowed me to make the fair and simultaneously hard call to take a quick pause so we can rebuild our current foundations to enable accessibility and a faster delivery time in the future.
|
||||
|
||||
# The Reasoning: TypeScript
|
||||
|
||||
Our primary reason for the rewrite is to better leverage the tools and technologies we've already chosen, namely TypeScript. While Documenso currently uses TypeScript, it's not fully taking advantage of its safety features, such as generics and type guards.
|
||||
|
||||
The codebase currently has several instances of `any` types, which is expected when working in an unknown domain where object models aren't fully understood before exploration and experimentation. These `any`s initially sped up development, but have since become a hindrance due to the lack of type information, combined with prop drilling. As a result, it's necessary to go through a lot of context to understand the root of any given issue.
|
||||
|
||||
The rewrite is using TypeScript to its full potential, ensuring that every interaction is strongly typed, both through general TypeScript tooling and the introduction of [Zod](https://github.com/colinhacks/zod), a validation library with excellent TypeScript support. With these choices, we can ensure that the codebase is robust to various inputs and states, as most issues will be caught during compile time and flagged within a developer's IDE.
|
||||
|
||||
# The Reasoning: Stronger API contracts
|
||||
|
||||
In line with our pattern of creating strongly typed contracts, we've decided to use [tRPC](https://github.com/trpc/trpc) for our internal API. This enables us to share types between our frontend and backend and establish a solid contract for interactions between the two. This is in contrast to the currently untyped API endpoints in Documenso, which are accessed using the `fetch` API that is itself untyped.
|
||||
|
||||
Using tRPC drastically reduces the chance of failures resulting from mundane things like argument or response shape changes during updates and upgrades. We made this decision easily because tRPC is a mature technology with no signs of losing momentum any time soon.
|
||||
|
||||
Additionally, many of our open-source friends have made the same choice for similar reasons.
|
||||
|
||||
# The Reasoning: Choosing exciting technologies
|
||||
|
||||
Although we already work with what I consider to be a fun stack that includes Next.js, Prisma, Tailwind, and more, it's no secret that contributors enjoy working with new technologies that benefit them in their own careers and projects.
|
||||
|
||||
To take advantage of this, we have decided to use Next.js 13 and React's new server component and actions architecture. Server components are currently popular among developers, with many loving and hating them at the same time.
|
||||
|
||||
I have personally worked with server components and actions since they were first released in October 2022 and have dealt with most of the hiccups and limitations along the way. Now, in July 2023, I believe they are in a much more stable place and are ready to be adopted, with their benefits being recognised by many.
|
||||
|
||||
By choosing to use server components and actions, we hope to encourage the community to participate more than they otherwise might. However, we are only choosing this because it has become more mature and stable. We will not choose things that are less likely to become the de-facto solution in the future, as we do not wish to inherit a pile of tech debt later on.
|
||||
|
||||
# The Reasoning: Allowing concurrent work
|
||||
|
||||
Another compelling reason for the rewrite was to effectively modularise code so we can work on features concurrently and without issue. This means extracting as much as possible out of components, API handlers and more and into a set of methods and functions that attempt to focus on just one thing.
|
||||
|
||||
In performing this work we should be able to easily make refactors and other changes to various parts of the code without stepping on each others feet, this also grants us the ability to upgrade or deprecate items as required by sticking to the contract of the previous method.
|
||||
|
||||
Additionally, this makes testing a much easier task as we can focus more on units of work rather than extensive end to end testing although we aim to have both, just not straight away.
|
||||
|
||||
# The Reasoning: Licensing of work
|
||||
|
||||
Another major reasoning for the rewrite is to ensure that all work performed on the project by both our internal team and external contributors is licensed in a way that benefits the project long-term. Prior to the rewrite contributors would create pull requests that would be merged in without any further process outside of the common code-review and testing cycles.
|
||||
|
||||
This was fine for the most part since we were simply working on the MVP but now as we move towards an infrastructure focus we intend on taking on enterprise clients who will have a need for a non-GPLv3 license since interpretations of it can be quite harmful to private hosting, to facilitate this we will require contributors to sign a contributor license agreement (CLA) prior to their changes being merged which will assign a perpetual license for us to use their code and relicense it as required such as for the use-case above.
|
||||
|
||||
While some might cringe at the idea of signing a CLA, we want to offer a compelling enterprise offering through means of dual-licensing. Great enterprise adoption is one of the cornerstones of our strategy and will be key to funding community and product development long-term.
|
||||
|
||||
_Do note that the above does not mean that we will ever go closed-source, it’s a point in our investor agreements that [https://github.com/documenso/documenso](https://github.com/documenso/documenso) will always remain available and open-source._
|
||||
|
||||
# Goals and Non-Goals
|
||||
|
||||
Rewriting an application is a monumental task that I have taken on and rejected many times in my career. As I get older, I become more hesitant to perform these rewrites because I understand that systems carry a lot of context and history. This makes them better suited for piecemeal refactoring instead, which avoids learning the lessons of the past all over again during the launch of the rewrite.
|
||||
|
||||
To ensure that we aren't just jumping off the deep end, I have set out a list of goals and non-goals to keep this rewrite lean and affordable.
|
||||
|
||||
### Goals
|
||||
|
||||
- Provide a clean design and interface for the newly rewritten application that creates a sense of trust and security at first glance.
|
||||
- Create a stable foundation and architecture that will allow for growth into our future roadmap items (teams, automation, workflows, etc.).
|
||||
- Create a robust system that requires minimal context through strong contracts and typing.
|
||||
|
||||
### Non-Goals
|
||||
|
||||
- Change the database schema (we don't want to make migration harder than it needs to be, thus all changes must be additive).
|
||||
- Add too many features that weren't in the system prior to the rewrite.
|
||||
- Remove any features that were in the older version of Documenso, such as free signatures (signatures that have no corresponding field).
|
||||
|
||||
# Rollout Plan
|
||||
|
||||
Thanks to the constraints listed above our rollout will hopefully be fairly painless, still to be safe we plan on doing the following.
|
||||
|
||||
1. In the current [testing environment](https://test.documenso.com), create and sign a number of documents leaving many in varying states of completion.
|
||||
2. Deploy the rewrite to the testing environment and verify that all existing documents and information is retrievable and modifiable without any issue.
|
||||
3. Create another set of documents using the new rewrite and verify that all interactions between authoring and signing work as expected.
|
||||
4. Repeat this until we reach a general confidence level (expectation of two weeks).
|
||||
|
||||
Once we’ve reached the desired confidence level with our testing environment we will look to deploy the rewrite to the production environment ensuring that we’ve performed all the required backups in the event of a catastrophic failure.
|
||||
|
||||
# Want to help out?
|
||||
|
||||
We’re currently working on the **[feat/refresh](https://github.com/documenso/documenso/tree/feat/refresh)** branch on GitHub, we aim to have a CLA available to sign in the coming days so we can start accepting external contributions asap. While we’re nearing the end-stage of the rewrite we will be throwing up a couple of bounties shortly for things like [Husky](https://github.com/typicode/husky) and [Changesets](https://github.com/changesets/changesets).
|
||||
|
||||
Keep an eye on our [GitHub issues](https://github.com/documenso/documenso/issues) to stay up to date!
|
||||
@ -1,13 +0,0 @@
|
||||
---
|
||||
title: Careers at Documenso
|
||||
---
|
||||
|
||||
# Careers at Documenso
|
||||
|
||||
So you love Documenso and all the things that we do and now you want to work with us to unlock the future of open signing?
|
||||
|
||||
---
|
||||
|
||||
## Open Positions
|
||||
|
||||
Unfortunately we have no open positions available at the moment. Our team has grown and so we must grow with it, please check back from time to time as now is not forever and we may be hiring again in the future.
|
||||
@ -1,357 +0,0 @@
|
||||
---
|
||||
title: Changelog - Documenso
|
||||
---
|
||||
|
||||
# Changelog
|
||||
|
||||
Check out what's new in the latest version and read our thoughts on it. For more technical details, you can find our releases on GitHub [here](https://github.com/documenso/documenso/releases). You can find our [release candidates here](https://github.com/documenso/documenso/tags).
|
||||
|
||||
---
|
||||
|
||||
# Documenso v1.8.0: Team Preferences, Signature Rejection, and Document Distribution
|
||||
|
||||
We're excited to announce the release of Documenso v1.8.0! This update brings powerful new features to enhance your document signing process. Here's what's new:
|
||||
|
||||
## 🌟 Key New Features
|
||||
|
||||
### 1. Team Preferences
|
||||
|
||||
Introducing **Team Preferences**, allowing administrators to configure settings and preferences that apply to documents across the entire team. This feature ensures consistency and simplifies management by letting you set default options, permissions, and preferences that automatically apply to all team members.
|
||||
|
||||

|
||||
|
||||
### 2. Signature Rejection
|
||||
|
||||
Recipients now have the option to **reject signatures**. This feature enhances communication by allowing recipients to decline signing, providing feedback or requesting changes before the document is finalized.
|
||||
|
||||
<video
|
||||
src="/changelog/v1_8_0/reject-document.mp4"
|
||||
className="aspect-video w-full"
|
||||
autoPlay
|
||||
loop
|
||||
controls
|
||||
/>
|
||||
|
||||
### 3. Document Distribution Settings
|
||||
|
||||
With the new **Document Distribution Settings**, you have greater control over how your documents are shared. Distribute communications via our automated emails and templates or take full control using our API and your own notifications infrastructure.
|
||||
|
||||
## 🔧 Other Improvements
|
||||
|
||||
- **Support for Gmail SMTP Service**: Adds support for using Gmail as your SMTP service provider.
|
||||
- **Certificate and Email Translations**: Added support for multiple languages in document certificates and emails, enhancing the experience for international users.
|
||||
- **Field Movement Fixes**: Resolved issues related to moving fields within documents, improving the document preparation experience.
|
||||
- **Docker Environment Update**: Improved Docker setup for smoother deployments and better environment consistency.
|
||||
- **Billing Access Improvements**: Users now have uninterrupted access to billing information, simplifying account management.
|
||||
- **Support Time Windows for 2FA Tokens**: Enhanced two-factor authentication by supporting time windows in 2FA tokens, improving flexibility.
|
||||
|
||||
## 💡 Recent Features
|
||||
|
||||
Don't forget to take advantage of these powerful features from our recent releases:
|
||||
|
||||
- **Signing Order**: Define the sequence in which recipients sign your documents for a structured signing process.
|
||||
- **Document Visibility Controls**: Manage who can view your documents and at what stages, offering greater privacy and control.
|
||||
- **Embedded Signing Experience**: Integrate the signing process directly into your own applications for a seamless user experience.
|
||||
|
||||
**👏 Thank You**
|
||||
|
||||
As always, we're grateful for the community's contributions and feedback. Your support helps us improve Documenso and deliver a top-notch open-source document signing solution.
|
||||
|
||||
We hope you enjoy the new features in Documenso v1.8.0. Happy signing!
|
||||
|
||||
---
|
||||
|
||||
# Documenso v1.7.1: Signing order and document visibility
|
||||
|
||||
We're excited to introduce Documenso v1.7.1, bringing you improved control over your document signing process. Here are the key updates:
|
||||
|
||||
## 🌟 Key New Features
|
||||
|
||||
### 1. Signing Order
|
||||
|
||||
Specify the sequence in which recipients sign your documents. This ensures a structured signing process, particularly useful for complex agreements or hierarchical approvals.
|
||||
|
||||
<video
|
||||
src="/changelog/signing-order-demo.mp4"
|
||||
className="aspect-video w-full"
|
||||
autoPlay
|
||||
loop
|
||||
controls
|
||||
/>
|
||||
|
||||
### 2. Document Visibility
|
||||
|
||||
Manage who can view your documents and when. This feature offers greater privacy and flexibility in your document sharing workflows.
|
||||
|
||||
<video
|
||||
src="/changelog/document-visibility-demo.mp4"
|
||||
className="aspect-video w-full"
|
||||
autoPlay
|
||||
loop
|
||||
controls
|
||||
/>
|
||||
|
||||
## 🔧 Other Improvements
|
||||
|
||||
- Added language switcher for easier language selection
|
||||
- Support for smaller field bounds in documents
|
||||
- Improved select field UX
|
||||
- Enhanced template functionality for advanced fields
|
||||
- Added authOptions to the API
|
||||
- Various UI refinements and bug fixes
|
||||
|
||||
## 💡 Recent Features
|
||||
|
||||
Don't forget about these powerful features from our recent v1.7.0 release:
|
||||
|
||||
- Embedded Signing Experience
|
||||
- Copy and Paste Fields
|
||||
- Customizable Signature Colors
|
||||
|
||||
## 👏 Thank You
|
||||
|
||||
As always, we're grateful for our community's contributions and feedback. Your input continues to shape Documenso into the leading open-source document signing solution.
|
||||
|
||||
We're eager to see how these new features enhance your document workflows. Enjoy exploring Documenso v1.7.1!
|
||||
|
||||
---
|
||||
|
||||
# Documenso v1.7.0: Embedded Signing, Copy and Paste, and More
|
||||
|
||||
We're thrilled to announce the release of Documenso v1.7.0, packed with exciting new features and improvements that enhance document signing flexibility, user experience, and global accessibility.
|
||||
|
||||
We're excited to see what you'll create with this release and we'd love to hear your feedback. Let's dive into the highlights:
|
||||
|
||||
## 🌟 Key Features
|
||||
|
||||
### Embedded Signing Experience
|
||||
|
||||
Take your document signing to the next level with our new embedded signing feature. Now you can seamlessly integrate Documenso's signing process directly into your own website or application, providing a smooth, branded experience for your users.
|
||||
|
||||
<video
|
||||
src="/blog/introducing-embedding/embedding-demo.mp4"
|
||||
className="aspect-video w-full"
|
||||
controls
|
||||
/>
|
||||
|
||||
Check out our [Embedding documentation](https://docs.documenso.com/developers/embedding) to learn more about how to get started.
|
||||
|
||||
### Copy and Paste Fields
|
||||
|
||||
Streamline your document preparation with our new copy and paste functionality for fields. This feature allows you to quickly duplicate fields across your document, saving time and ensuring consistency in your templates.
|
||||
|
||||
### Customizable Signature Colors
|
||||
|
||||
Recipients can now select a signature color from our list of available colors, supporting workflows where specific colors are required for each recipient, location, or document.
|
||||
|
||||
### Enhanced Internationalization (i18n)
|
||||
|
||||
Following on from our last release we've now expanded our i18n support to the main web application. We haven't yet added support for any additional languages but that will be coming quickly now that we have completed the hard work of wrapping all of our content in our new i18n system.
|
||||
|
||||
These enhancements make Documenso more accessible to users worldwide.
|
||||
|
||||
## 🔧 Other Improvements
|
||||
|
||||
- **API Enhancements**:
|
||||
|
||||
- New endpoint to prefill fields via API
|
||||
- Updated createFields API endpoint for more flexibility
|
||||
- Automatically set public profile URL for OIDC users
|
||||
|
||||
- **Security and Performance**:
|
||||
|
||||
- Document sealing moved to a background job for improved performance
|
||||
- Disable 2FA with backup codes for enhanced account recovery options
|
||||
- Extended lifespan for invites and confirmations
|
||||
|
||||
- **User Experience**:
|
||||
|
||||
- Updated email templates to reflect team-specific information
|
||||
- Fixed issues with dialog closing on page refresh
|
||||
- Improved field editing in document templates
|
||||
|
||||
- **Other Items**:
|
||||
- Added Elestio as a one-click deploy option
|
||||
- Updated README for manual self-hosting
|
||||
- New environment variable for internal webapp URL configuration
|
||||
|
||||
## 📚 New Content
|
||||
|
||||
- [Advanced fields article to help you make the most of Documenso's capabilities](/blog/introducing-advanced-signing-fields)
|
||||
- [Embedding blog post to guide you through how we implemented embedding](/blog/introducing-embedding)
|
||||
|
||||
## 👏 Community Contributions
|
||||
|
||||
A big thank you to our vibrant community! This release includes contributions from several new contributors, further enriching Documenso's capabilities.
|
||||
|
||||
We're excited to see how you'll use these new features to streamline your document workflows. As always, we appreciate your feedback and support in making Documenso the best open-source document signing solution available.
|
||||
|
||||
Enjoy exploring v1.7.0!
|
||||
|
||||
---
|
||||
|
||||
# Documenso v1.6.1: Internationalization, Enhanced OIDC, and More
|
||||
|
||||
We're excited to announce the release of Documenso v1.6.1, which brings several improvements to enhance your document signing experience. Here are the key updates:
|
||||
|
||||
## 🌟 Key Features
|
||||
|
||||
### New Initials Field Type
|
||||
|
||||
We've added a new field type for initials, giving you more options for document customization. This feature allows signers to quickly initial documents, adding an extra layer of verification to your signing process.
|
||||
|
||||
### Internationalization Support
|
||||
|
||||
We've taken a big step towards making Documenso accessible to a global audience by adding i18n (internationalization) support for our marketing pages and adding translations to support multiple languages.
|
||||
|
||||
While this is just a small step towards a fully multilingual Documenso, it's a significant step towards making our platform more accessible to a global audience.
|
||||
|
||||
Using our new knowledge and findings from the marketing implementation, we aim to tackle our web application in the near future for a fully global Documenso.
|
||||
|
||||
### Enhanced OpenID Connect (OIDC) Integration
|
||||
|
||||
For our self-hosted users leveraging OIDC for authentication:
|
||||
|
||||
- Now supports OIDC-only signup
|
||||
- Added trust for email addresses from OIDC providers
|
||||
- The OIDC sign-in button text is now configurable
|
||||
|
||||
## 🔧 Other Improvements
|
||||
|
||||
- **UI Enhancements**:
|
||||
|
||||
- Fixed display issues with field names/labels in dark mode
|
||||
- Improved truncation of titles to prevent UI breaks
|
||||
|
||||
- **User Experience**:
|
||||
|
||||
- The signup option is now shown only to users without existing accounts
|
||||
- Fixed issues with radio and checkbox fields having empty values
|
||||
|
||||
- **API and Security**:
|
||||
|
||||
- Fixed a bug in the date format API
|
||||
- Improved URL parsing for enhanced security
|
||||
- Added support for dynamic external IDs for direct templates
|
||||
|
||||
- **Document Management**:
|
||||
- Resolved an issue with downloading audit log certificates
|
||||
|
||||
We've also made various other minor fixes and improvements to ensure a smoother Documenso experience.
|
||||
|
||||
## 👏 Community Contributions
|
||||
|
||||
A big thank you to our growing community! This release includes contributions from several new contributors, showcasing the power of open-source collaboration.
|
||||
|
||||
We appreciate your continued support and feedback as we work to make Documenso the best document signing solution available. Enjoy the new features and improvements in v1.6.1!
|
||||
|
||||
---
|
||||
|
||||
## v1.6.0: Enhancing Team Collaboration and User Experience
|
||||
|
||||
### <small>Released 23th July 2024</small>
|
||||
|
||||
> This release contains [8 fixes](https://github.com/documenso/documenso/releases/tag/v1.6.0)
|
||||
|
||||
We're excited to announce the release of Documenso v1.6.0! The new release is packed with new features and improvements to streamline the signing process. Here are the highlights:
|
||||
|
||||
### 📚 New Documentation Site
|
||||
|
||||
We’ve launched a comprehensive documentation site to help you make the most of Documenso. Check it out to explore all our features and best practices! Based on your feedback, we’re constantly working to improve Documenso. Feel free to ping us to update the docs or even raise PRs.
|
||||
|
||||
> Check out the docs at [https://docs.documenso.com](https://docs.documenso.com)
|
||||
|
||||
### ✅ Enhanced Field Types
|
||||
|
||||
We've significantly expanded our field options to give you more document and template creation flexibility. New field types include:
|
||||
|
||||
- Dropdown Menus
|
||||
- Checkboxes
|
||||
- Radio Buttons
|
||||
- Number Fields
|
||||
|
||||
We've added more customization options for each field type, allowing you to create more dynamic and interactive documents. All non-auto field types allow setting pre-fill values, placeholders, and labels. For more details, see the new [documentation](https://docs.documenso.com/users/signing-documents/fields).
|
||||
|
||||
### 🪪 Public Profiles
|
||||
|
||||
We've introduced [Public Profiles](http://localhost:3001/blog/announcing-profiles), allowing you to showcase your professional identity within Documenso and showcase your publicly available templates. This feature enhances transparency and trust in your signing processes. This feature enhances transparency and trust in your signing processes.
|
||||
|
||||
### ⬅️ Move Documents and Templates to Teams
|
||||
|
||||
Did you accidentally create a document under your personal account? No problem! You can move documents and templates between your personal account and team workspaces, facilitating better organization and teamwork.
|
||||
|
||||
### 🔧 Other Improvements
|
||||
|
||||
- Background Tasks: We've implemented a system for handling background tasks, improving overall performance and responsiveness.
|
||||
- Force Signature Fields: Document creators can now ensure that signers complete all required signature fields.
|
||||
- Custom Emails for Direct Template Documents: Personalize your communication by sending custom emails to signers of direct template documents.
|
||||
- API Enhancements: We've added more template API endpoints and the ability to resend documents via API, giving developers more flexibility.
|
||||
- Anonymous SMTP Authentication: We now support anonymous SMTP authentication for those who need it.
|
||||
|
||||
---
|
||||
|
||||
## v1.5.6
|
||||
|
||||
### <small>Released 28th June 2024</small>
|
||||
|
||||
> This release contains [11 fixes](https://github.com/documenso/documenso/releases/tag/v1.5.6)
|
||||
|
||||
### 🕗 Show Creation Time
|
||||
|
||||
We are now displaying the document creation time in the documents view. This allows for easier identification of multiple documents created on the same day.
|
||||
|
||||
### 🔗 Direct Template Links
|
||||
|
||||
With this release, we are introducing direct link templates. This allows you to statically link to any template and let anyone with the link sign it at any time. A new document is created in your account when a template is signed. Templates with direct links still support all other template features, allowing you to create intricate workflows triggered by the signers.
|
||||
|
||||
Learn more about Direct Links [on our blog](https://documenso.com/blog/announcing-direct-links) or try them by signing the [Documenso Supporters Pledge](https://documen.so/pledge).
|
||||
|
||||
### 🛂 OpenID Connect (OIDC) Support
|
||||
|
||||
Thanks to [Matt Kilgore](https://github.com/tankerkiller125), Documenso now supports OIDC as an authentication provider. This allows self-hosted users to define whatever identity provider they want as long as it supports the OIDC. Azure, Zitadel, Authentik, KeyCloak, and Google all support OIDC.
|
||||
|
||||
---
|
||||
|
||||
## v1.5.5
|
||||
|
||||
### <small>Released 6th May 2024</small>
|
||||
|
||||
> This release contains [20 fixes](https://github.com/documenso/documenso/releases/tag/v1.5.5)
|
||||
|
||||
### ✅ Show Completed Fields
|
||||
|
||||
Fields completed by other recipients are now visible to everyone to communicate the state of the document better and allow users an informed decision on what they are signing.
|
||||
|
||||
### ⬇️ Download Completed Documents via API
|
||||
|
||||
Completed documents can now be downloaded via the API using this new endpoint:
|
||||
|
||||
**GET /API/V1//DOCUMENTS/\{ID\}/DOWNLOAD**
|
||||
|
||||
Check out the full Open API docs here: [https://documen.so/openapi](https://documen.so/openapi)
|
||||
|
||||
### ➕ Adding Yourself as a Signer
|
||||
|
||||
Adding yourself as a signer is now just one click away.
|
||||
|
||||
---
|
||||
|
||||
## v1.5.4
|
||||
|
||||
### <small>Released 11th April 2024</small>
|
||||
|
||||
> This release contains [21 fixes](https://github.com/documenso/documenso/releases/tag/v1.5.4)
|
||||
|
||||
#### 🔑 Passkeys
|
||||
|
||||
To improve security and usability for high-security setups, we added passkeys with this release. Passkeys can now be used to log in or re-authenticate each signature for high-compliance cases.
|
||||
|
||||
#### 📄 Signing Certificate & Audit Log
|
||||
|
||||
On the security/ compliance side, we also added Signing Certificates and Audit Logs. Every signed document now has a certificate attached, showing technical details of the signature to improve transparency and security. Further, every action on a document from creation to completion is now logged in the audit log to guarantee the integrity of the process.
|
||||
|
||||
#### 🔏🦀 @documenso/pdf-sign
|
||||
|
||||
We are pretty hyped about this one: Since version 0.9, we relied on https://github.com/vbuch/node-signpdf to add the digital signatures to our documents. Since signing is at the heart of Documenso, we created our own rust-based library for signing. As of 1.5.4, Documenso's signing runs on @documenso/pdf-sign. The library offers a better architecture to enable signing with private keys that are not stored locally (e.g. via HSM). We are in the process of cleaning up the library to open source it like the rest of Documenso 🌱 The library will also help us to offer Long Term Validation (LTV) for signatures soon. While we are currently limited to signing with PKCS7-B, eventually, we plan to support all common signing standards like PAdES, CAdES, and XAdES.
|
||||
|
||||
---
|
||||
@ -1,42 +0,0 @@
|
||||
---
|
||||
title: Design System
|
||||
---
|
||||
|
||||
# We're building a beautiful, open-source alternative to DocuSign
|
||||
|
||||
> Read more about our design culture here:
|
||||
>
|
||||
> [https://documenso.com/blog/design-system](https://documenso.com/blog/design-system)
|
||||
|
||||
At Documenso, we aim to be a design-driven company.
|
||||
|
||||
We believe that design isn't just about how things look, but also how they work. We want to make sure that the product is easy to use and intuitive. We also want to ensure that the website, desktop and mobile apps are consistent and look and feel like they belong together.
|
||||
|
||||
To achieve this, we've created Documenso's design system containing tokens, primitives, and components, screens, and brand assets.
|
||||
|
||||
We're open-sourcing this design system so you can see how we build the product and think about design as a whole.
|
||||
|
||||
## Check out the design system
|
||||
|
||||
<iframe
|
||||
src="https://documen.so/design-system-embed"
|
||||
className="aspect-square w-full border-none"
|
||||
frameBorder="0"
|
||||
/>
|
||||
|
||||
## Remix and Share the community version on Figma
|
||||
|
||||
<a href="https://documen.so/design" target="_blank">
|
||||
<figure>
|
||||
<MdxNextImage
|
||||
src="/blog/designsystem.png"
|
||||
width="1260"
|
||||
height="630"
|
||||
alt="Documenso's Design System"
|
||||
/>
|
||||
|
||||
<figcaption className="text-center">
|
||||
Documenso's Design System ✨
|
||||
</figcaption>
|
||||
</figure>
|
||||
</a>
|
||||
@ -1,256 +0,0 @@
|
||||
---
|
||||
title: Privacy Policy
|
||||
---
|
||||
|
||||
# Privacy Policy
|
||||
|
||||
Effective date: 05/28/2023
|
||||
|
||||
### 1\. Introduction
|
||||
|
||||
Welcome to **Documenso Inc.**
|
||||
|
||||
Documenso Inc. (“us”, “we”, or “our”) operates [https://documenso.com](https://documenso.com) (hereinafter referred to as “ **Service**”).
|
||||
|
||||
Our Privacy Policy governs your visit to [https://documenso.com](https://documenso.com), and explains how we collect, safeguard and disclose information that results from your use of our Service.
|
||||
|
||||
We use your data to provide and improve Service. By using Service, you agree to the collection and use of information in accordance with this policy. Unless otherwise defined in this Privacy Policy, the terms used in this Privacy Policy have the same meanings as in our Terms and Conditions.
|
||||
|
||||
Our Terms and Conditions (“**Terms**”) govern all use of our Service and together with the Privacy Policy constitutes your agreement with us (“ **agreement**”).
|
||||
|
||||
### 2\. Definitions
|
||||
|
||||
**SERVICE** means the https://documenso.com website operated by Documenso Inc.
|
||||
|
||||
**PERSONAL DATA** means data about a living individual who can be identified from those data (or from those and other information either in our possession or likely to come into our possession).
|
||||
|
||||
**USAGE DATA** is data collected automatically either generated by the use of Service or from Service infrastructure itself (for example, the duration of a page visit).
|
||||
|
||||
**COOKIES** are small files stored on your device (computer or mobile device).
|
||||
|
||||
**DATA CONTROLLER** means a natural or legal person who (either alone or jointly or in common with other persons) determines the purposes for which and the manner in which any personal data are, or are to be, processed. For the purpose of this Privacy Policy, we are a Data Controller of your data.
|
||||
|
||||
**DATA PROCESSORS (OR SERVICE PROVIDERS)** means any natural or legal person who processes the data on behalf of the Data Controller. We may use the services of various Service Providers in order to process your data more effectively.
|
||||
|
||||
**DATA SUBJECT** is any living individual who is the subject of Personal Data.
|
||||
|
||||
**THE USER** is the individual using our Service. The User corresponds to the Data Subject, who is the subject of Personal Data.
|
||||
|
||||
### 3\. Information Collection and Use
|
||||
|
||||
We collect several different types of information for various purposes to provide and improve our Service to you.
|
||||
|
||||
### 4\. Types of Data Collected
|
||||
|
||||
**Personal Data**
|
||||
|
||||
While using our Service, we may ask you to provide us with certain personally identifiable information that can be used to contact or identify you (“**Personal Data**”). Personally identifiable information may include, but is not limited to:
|
||||
|
||||
1. Email address
|
||||
2. First name and last name
|
||||
3. Cookies and Usage Data
|
||||
|
||||
We may use your Personal Data to contact you with newsletters, marketing or promotional materials and other information that may be of interest to you. You may opt out of receiving any, or all, of these communications from us by following the unsubscribe link.
|
||||
|
||||
**Usage Data**
|
||||
|
||||
We may also collect information that your browser sends whenever you visit our Service or when you access Service by or through a mobile device (“**Usage Data**”).
|
||||
|
||||
This Usage Data may include information such as your computer's Internet Protocol address (e.g. IP address), browser type, browser version, the pages of our Service that you visit, the time and date of your visit, the time spent on those pages, unique device identifiers and other diagnostic data.
|
||||
|
||||
When you access Service with a mobile device, this Usage Data may include information such as the type of mobile device you use, your mobile device unique ID, the IP address of your mobile device, your mobile operating system, the type of mobile Internet browser you use, unique device identifiers and other diagnostic data.
|
||||
|
||||
**Tracking Cookies Data**
|
||||
|
||||
We use cookies and similar tracking technologies to track the activity on our Service and we hold certain information.
|
||||
|
||||
Cookies are files with a small amount of data which may include an anonymous unique identifier. Cookies are sent to your browser from a website and stored on your device. Other tracking technologies are also used such as beacons, tags and scripts to collect and track information and to improve and analyze our Service.
|
||||
|
||||
You can instruct your browser to refuse all cookies or to indicate when a cookie is being sent. However, if you do not accept cookies, you may not be able to use some portions of our Service.
|
||||
|
||||
Examples of Cookies we use:
|
||||
|
||||
1. **Session Cookies:** We use Session Cookies to operate our Service.
|
||||
2. **Preference Cookies:** We use Preference Cookies to remember your preferences and various settings.
|
||||
3. **Security Cookies:** We use Security Cookies for security purposes.
|
||||
4. **Advertising Cookies:** Advertising Cookies are used to serve you with advertisements that may be relevant to you and your interests.
|
||||
|
||||
### 5\. Use of Data
|
||||
|
||||
Documenso Inc. uses the collected data for various purposes:
|
||||
|
||||
1. to provide and maintain our Service;
|
||||
2. to notify you about changes to our Service;
|
||||
3. to allow you to participate in interactive features of our Service when you choose to do so;
|
||||
4. to provide customer support;
|
||||
5. to gather analysis or valuable information so that we can improve our Service;
|
||||
6. to monitor the usage of our Service;
|
||||
7. to detect, prevent and address technical issues;
|
||||
8. to fulfill any other purpose for which you provide it;
|
||||
9. to carry out our obligations and enforce our rights arising from any contracts entered into between you and us, including for billing and collection;
|
||||
10. to provide you with notices about your account and/or subscription, including expiration and renewal notices, email-instructions, etc.;
|
||||
11. to provide you with news, special offers and general information about other goods, services and events which we offer that are similar to those that you have already purchased or enquired about unless you have opted not to receive such information;
|
||||
12. in any other way we may describe when you provide the information;
|
||||
13. for any other purpose with your consent.
|
||||
|
||||
### 6\. Retention of Data
|
||||
|
||||
We will retain your Personal Data only for as long as is necessary for the purposes set out in this Privacy Policy. We will retain and use your Personal Data to the extent necessary to comply with our legal obligations (for example, if we are required to retain your data to comply with applicable laws), resolve disputes, and enforce our legal agreements and policies.
|
||||
|
||||
We will also retain Usage Data for internal analysis purposes. Usage Data is generally retained for a shorter period, except when this data is used to strengthen the security or to improve the functionality of our Service, or we are legally obligated to retain this data for longer time periods.
|
||||
|
||||
### 7\. Transfer of Data
|
||||
|
||||
Your information, including Personal Data, may be transferred to – and maintained on – computers located outside of your state, province, country or other governmental jurisdiction where the data protection laws may differ from those of your jurisdiction.
|
||||
|
||||
If you are located outside United States and choose to provide information to us, please note that we transfer the data, including Personal Data, to United States and process it there.
|
||||
|
||||
Your consent to this Privacy Policy followed by your submission of such information represents your agreement to that transfer.
|
||||
|
||||
Documenso Inc. will take all the steps reasonably necessary to ensure that your data is treated securely and in accordance with this Privacy Policy and no transfer of your Personal Data will take place to an organisation or a country unless there are adequate controls in place including the security of your data and other personal information.
|
||||
|
||||
### 8\. Disclosure of Data
|
||||
|
||||
We may disclose personal information that we collect, or you provide:
|
||||
|
||||
1. **Disclosure for Law Enforcement.**
|
||||
2. Under certain circumstances, we may be required to disclose your Personal Data if required to do so by law or in response to valid requests by public authorities.
|
||||
3. **Business Transaction.**
|
||||
4. If we or our subsidiaries are involved in a merger, acquisition or asset sale, your Personal Data may be transferred.
|
||||
5. **Other cases. We may disclose your information also:**
|
||||
1. to our subsidiaries and affiliates;
|
||||
2. to contractors, service providers, and other third parties we use to support our business;
|
||||
3. to fulfill the purpose for which you provide it;
|
||||
|
||||
### 9\. Security of Data
|
||||
|
||||
The security of your data is important to us but remember that no method of transmission over the Internet or method of electronic storage is 100% secure. While we strive to use commercially acceptable means to protect your Personal Data, we cannot guarantee its absolute security.
|
||||
|
||||
### 10\. Your Data Protection Rights Under General Data Protection Regulation (GDPR)
|
||||
|
||||
If you are a resident of the European Union (EU) and European Economic Area (EEA), you have certain data protection rights, covered by GDPR. – See more at [https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://eur-lex.europa.eu/eli/reg/2016/679/oj)
|
||||
|
||||
We aim to take reasonable steps to allow you to correct, amend, delete, or limit the use of your Personal Data.
|
||||
|
||||
If you wish to be informed what Personal Data we hold about you and if you want it to be removed from our systems, please email us at hi@documenso.com.
|
||||
|
||||
In certain circumstances, you have the following data protection rights:
|
||||
|
||||
1. the right to access, update or to delete the information we have on you;
|
||||
2. the right of rectification. You have the right to have your information rectified if that information is inaccurate or incomplete;
|
||||
3. the right to object. You have the right to object to our processing of your Personal Data;
|
||||
4. the right of restriction. You have the right to request that we restrict the processing of your personal information;
|
||||
5. the right to data portability. You have the right to be provided with a copy of your Personal Data in a structured, machine-readable and commonly used format;
|
||||
6. the right to withdraw consent. You also have the right to withdraw your consent at any time where we rely on your consent to process your personal information;
|
||||
|
||||
Please note that we may ask you to verify your identity before responding to such requests. Please note, we may not able to provide Service without some necessary data.
|
||||
|
||||
You have the right to complain to a Data Protection Authority about our collection and use of your Personal Data. For more information, please contact your local data protection authority in the European Economic Area (EEA).
|
||||
|
||||
### 11\. Your Data Protection Rights under the California Privacy Protection Act (CalOPPA)
|
||||
|
||||
CalOPPA is the first state law in the nation to require commercial websites and online services to post a privacy policy. The law’s reach stretches well beyond California to require a person or company in the United States (and conceivable the world) that operates websites collecting personally identifiable information from California consumers to post a conspicuous privacy policy on its website stating exactly the information being collected and those individuals with whom it is being shared, and to comply with this policy. – See more at: [https://consumercal.org/about-cfc/cfc-education-foundation/california-online-privacy-protection-act-caloppa-3/](https://consumercal.org/about-cfc/cfc-education-foundation/california-online-privacy-protection-act-caloppa-3/)
|
||||
|
||||
According to CalOPPA we agree to the following:
|
||||
|
||||
1. users can visit our site anonymously;
|
||||
2. our Privacy Policy link includes the word “Privacy”, and can easily be found on the page specified above on the home page of our website;
|
||||
3. users will be notified of any privacy policy changes on our Privacy Policy Page;
|
||||
4. users are able to change their personal information by emailing us at hi@documenso.com.
|
||||
|
||||
Our Policy on “Do Not Track” Signals:
|
||||
|
||||
We honor Do Not Track signals and do not track, plant cookies, or use advertising when a Do Not Track browser mechanism is in place. Do Not Track is a preference you can set in your web browser to inform websites that you do not want to be tracked.
|
||||
|
||||
You can enable or disable Do Not Track by visiting the Preferences or Settings page of your web browser.
|
||||
|
||||
### 12\. Your Data Protection Rights under the California Consumer Privacy Act (CCPA)
|
||||
|
||||
If you are a California resident, you are entitled to learn what data we collect about you, ask to delete your data and not to sell (share) it. To exercise your data protection rights, you can make certain requests and ask us:
|
||||
|
||||
1. **What personal information we have about you**. If you make this request, we will return to you:
|
||||
|
||||
1. The categories of personal information we have collected about you.
|
||||
2. The categories of sources from which we collect your personal information.
|
||||
3. The business or commercial purpose for collecting or selling your personal information.
|
||||
4. The categories of third parties with whom we share personal information.
|
||||
5. The specific pieces of personal information we have collected about you.
|
||||
6. A list of categories of personal information that we have sold, along with the category of any other company we sold it to. If we have not sold your personal information, we will inform you of that fact.
|
||||
7. A list of categories of personal information that we have disclosed for a business purpose, along with the category of any other company we shared it with.
|
||||
|
||||
Please note, you are entitled to ask us to provide you with this information up to two times in a rolling twelve-month period. When you make this request, the information provided may be limited to the personal information we collected about you in the previous 12 months.
|
||||
|
||||
2. **To delete your personal information**. If you make this request, we will delete the personal information we hold about you as of the date of your request from our records and direct any service providers to do the same. In some cases, deletion may be accomplished through de-identification of the information. If you choose to delete your personal information, you may not be able to use certain functions that require your personal information to operate.
|
||||
3. **To stop selling your personal information**. We don't sell or rent your personal information to any third parties for any purpose. You are the only owner of your Personal Data and can request disclosure or deletion at any time.
|
||||
|
||||
Please note, if you ask us to delete or stop selling your data, it may impact your experience with us, and you may not be able to participate in certain programs or membership services which require the usage of your personal information to function. But in no circumstances, we will discriminate against you for exercising your rights.
|
||||
|
||||
To exercise your California data protection rights described above, please send your request(s) by one of the following means:
|
||||
|
||||
By email: hi@documenso.com
|
||||
|
||||
Your data protection rights, described above, are covered by the CCPA, short for the California Consumer Privacy Act. To find out more, visit the official [California Legislative Information website](https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=201720180AB375). The CCPA took effect on 01/01/2020.
|
||||
|
||||
### 13\. Service Providers
|
||||
|
||||
We may employ third party companies and individuals to facilitate our Service (“ **Service Providers**”), provide Service on our behalf, perform Service-related services or assist us in analysing how our Service is used.
|
||||
|
||||
These third parties have access to your Personal Data only to perform these tasks on our behalf and are obligated not to disclose or use it for any other purpose.
|
||||
|
||||
### 14\. Analytics
|
||||
|
||||
We may use third-party Service Providers to monitor and analyze the use of our Service.
|
||||
|
||||
**Plausible Analytics**
|
||||
|
||||
Plausible Analytics is an analytics service provided by Conva Ventures Inc. You can find their Privacy Policy here: [https://plausible.io/privacy](https://plausible.io/privacy)
|
||||
|
||||
### 15\. CI/CD tools
|
||||
|
||||
We may use third-party Service Providers to automate the development process of our Service.
|
||||
|
||||
**GitHub**
|
||||
|
||||
GitHub is provided by GitHub, Inc.
|
||||
|
||||
GitHub is a development platform to host and review code, manage projects, and build software.
|
||||
|
||||
For more information on what data GitHub collects for what purpose and how the protection of the data is ensured, please visit GitHub Privacy Policy page: [https://help.github.com/en/articles/github-privacy-statement](https://help.github.com/en/articles/github-privacy-statement) .
|
||||
|
||||
### 16\. Payments
|
||||
|
||||
We may provide paid products and/or services within Service. In that case, we use third-party services for payment processing (e.g. payment processors).
|
||||
|
||||
We will not store or collect your payment card details. That information is provided directly to our third-party payment processors whose use of your personal information is governed by their Privacy Policy. These payment processors adhere to the standards set by PCI-DSS as managed by the PCI Security Standards Council, which is a joint effort of brands like Visa, Mastercard, American Express and Discover. PCI-DSS requirements help ensure the secure handling of payment information.
|
||||
|
||||
The payment processors we work with are:
|
||||
|
||||
**Stripe:**
|
||||
|
||||
Their Privacy Policy can be viewed at: [https://stripe.com/us/privacy](https://stripe.com/us/privacy)
|
||||
|
||||
### 17\. Links to Other Sites
|
||||
|
||||
Our Service may contain links to other sites that are not operated by us. If you click a third party link, you will be directed to that third party's site. We strongly advise you to review the Privacy Policy of every site you visit.
|
||||
|
||||
We have no control over and assume no responsibility for the content, privacy policies or practices of any third party sites or services.
|
||||
|
||||
### 18\. Children's Privacy
|
||||
|
||||
Our Services are not intended for use by children under the age of 18 (“ **Child**” or “**Children**”).
|
||||
|
||||
We do not knowingly collect personally identifiable information from Children under 18. If you become aware that a Child has provided us with Personal Data, please contact us. If we become aware that we have collected Personal Data from Children without verification of parental consent, we take steps to remove that information from our servers.
|
||||
|
||||
### 19\. Changes to This Privacy Policy
|
||||
|
||||
We may update our Privacy Policy from time to time. We will notify you of any changes by posting the new Privacy Policy on this page.
|
||||
|
||||
We will let you know via email and/or a prominent notice on our Service, prior to the change becoming effective and update “effective date” at the top of this Privacy Policy.
|
||||
|
||||
You are advised to review this Privacy Policy periodically for any changes. Changes to this Privacy Policy are effective when they are posted on this page.
|
||||
|
||||
### 20\. Contact Us
|
||||
|
||||
If you have any questions about this Privacy Policy, please contact us:
|
||||
|
||||
By email: hi@documenso.com.
|
||||
@ -1,34 +0,0 @@
|
||||
import { defineDocumentType, makeSource } from 'contentlayer/source-files';
|
||||
|
||||
export const BlogPost = defineDocumentType(() => ({
|
||||
name: 'BlogPost',
|
||||
filePathPattern: `blog/**/*.mdx`,
|
||||
contentType: 'mdx',
|
||||
fields: {
|
||||
title: { type: 'string', required: true },
|
||||
description: { type: 'string', required: true },
|
||||
date: { type: 'date', required: true },
|
||||
tags: { type: 'list', of: { type: 'string' }, required: false, default: [] },
|
||||
authorName: { type: 'string', required: true },
|
||||
authorImage: { type: 'string', required: false },
|
||||
authorRole: { type: 'string', required: true },
|
||||
cta: { type: 'boolean', required: false, default: true },
|
||||
},
|
||||
computedFields: {
|
||||
href: { type: 'string', resolve: (post) => `/${post._raw.flattenedPath}` },
|
||||
},
|
||||
}));
|
||||
|
||||
export const GenericPage = defineDocumentType(() => ({
|
||||
name: 'GenericPage',
|
||||
filePathPattern: '**/*.mdx',
|
||||
contentType: 'mdx',
|
||||
fields: {
|
||||
title: { type: 'string', required: true },
|
||||
},
|
||||
computedFields: {
|
||||
href: { type: 'string', resolve: (post) => `/${post._raw.flattenedPath}` },
|
||||
},
|
||||
}));
|
||||
|
||||
export default makeSource({ contentDirPath: 'content', documentTypes: [BlogPost, GenericPage] });
|
||||
@ -1,22 +0,0 @@
|
||||
import type { LinguiConfig } from '@lingui/conf';
|
||||
|
||||
import { APP_I18N_OPTIONS } from '@documenso/lib/constants/i18n';
|
||||
|
||||
// Extends root lingui.config.cjs.
|
||||
const config: LinguiConfig = {
|
||||
// eslint-disable-next-line @typescript-eslint/consistent-type-assertions
|
||||
locales: APP_I18N_OPTIONS.supportedLangs as unknown as string[],
|
||||
catalogs: [
|
||||
{
|
||||
path: '<rootDir>/../../packages/lib/translations/{locale}/marketing',
|
||||
include: ['<rootDir>/apps/marketing/src'],
|
||||
},
|
||||
{
|
||||
path: '<rootDir>/../../packages/lib/translations/{locale}/common',
|
||||
include: ['<rootDir>/packages/ui', '<rootDir>/packages/lib'],
|
||||
},
|
||||
],
|
||||
catalogsMergePath: '<rootDir>/../../packages/lib/translations/{locale}/marketing',
|
||||
};
|
||||
|
||||
export default config;
|
||||
6
apps/marketing/next-env.d.ts
vendored
@ -1,6 +0,0 @@
|
||||
/// <reference types="next" />
|
||||
/// <reference types="next/image-types/global" />
|
||||
/// <reference types="next/navigation-types/compat/navigation" />
|
||||
|
||||
// NOTE: This file should not be edited
|
||||
// see https://nextjs.org/docs/basic-features/typescript for more information.
|
||||
@ -1,112 +0,0 @@
|
||||
/* eslint-disable @typescript-eslint/no-var-requires */
|
||||
const fs = require('fs');
|
||||
const path = require('path');
|
||||
const { withContentlayer } = require('next-contentlayer');
|
||||
const { withAxiom } = require('next-axiom');
|
||||
|
||||
const ENV_FILES = ['.env', '.env.local', `.env.${process.env.NODE_ENV || 'development'}`];
|
||||
|
||||
ENV_FILES.forEach((file) => {
|
||||
require('dotenv').config({
|
||||
path: path.join(__dirname, `../../${file}`),
|
||||
});
|
||||
});
|
||||
|
||||
// !: This is a temp hack to get caveat working without placing it back in the public directory.
|
||||
// !: By inlining this at build time we should be able to sign faster.
|
||||
const FONT_CAVEAT_BYTES = fs.readFileSync(
|
||||
path.join(__dirname, '../../packages/assets/fonts/caveat.ttf'),
|
||||
);
|
||||
|
||||
const FONT_NOTO_SANS_BYTES = fs.readFileSync(
|
||||
path.join(__dirname, '../../packages/assets/fonts/noto-sans.ttf'),
|
||||
);
|
||||
|
||||
/** @type {import('next').NextConfig} */
|
||||
const config = {
|
||||
experimental: {
|
||||
outputFileTracingRoot: path.join(__dirname, '../../'),
|
||||
serverComponentsExternalPackages: ['@node-rs/bcrypt', '@documenso/pdf-sign', 'playwright'],
|
||||
serverActions: {
|
||||
bodySizeLimit: '50mb',
|
||||
},
|
||||
swcPlugins: [['@lingui/swc-plugin', {}]],
|
||||
},
|
||||
reactStrictMode: true,
|
||||
transpilePackages: [
|
||||
'@documenso/assets',
|
||||
'@documenso/lib',
|
||||
'@documenso/tailwind-config',
|
||||
'@documenso/trpc',
|
||||
'@documenso/ui',
|
||||
],
|
||||
env: {
|
||||
NEXT_PUBLIC_PROJECT: 'marketing',
|
||||
FONT_CAVEAT_URI: `data:font/ttf;base64,${FONT_CAVEAT_BYTES.toString('base64')}`,
|
||||
FONT_NOTO_SANS_URI: `data:font/ttf;base64,${FONT_NOTO_SANS_BYTES.toString('base64')}`,
|
||||
},
|
||||
modularizeImports: {
|
||||
'lucide-react': {
|
||||
transform: 'lucide-react/dist/esm/icons/{{ kebabCase member }}',
|
||||
},
|
||||
},
|
||||
webpack: (config, { isServer }) => {
|
||||
// fixes: Module not found: Can’t resolve ‘../build/Release/canvas.node’
|
||||
if (isServer) {
|
||||
config.resolve.alias.canvas = false;
|
||||
}
|
||||
|
||||
config.module.rules.push({
|
||||
test: /\.po$/,
|
||||
use: {
|
||||
loader: '@lingui/loader',
|
||||
},
|
||||
});
|
||||
|
||||
return config;
|
||||
},
|
||||
async headers() {
|
||||
return [
|
||||
{
|
||||
source: '/:path*',
|
||||
headers: [
|
||||
{
|
||||
key: 'x-dns-prefetch-control',
|
||||
value: 'on',
|
||||
},
|
||||
{
|
||||
key: 'strict-transport-security',
|
||||
value: 'max-age=31536000; includeSubDomains; preload',
|
||||
},
|
||||
{
|
||||
key: 'x-frame-options',
|
||||
value: 'SAMEORIGIN',
|
||||
},
|
||||
{
|
||||
key: 'x-content-type-options',
|
||||
value: 'nosniff',
|
||||
},
|
||||
{
|
||||
key: 'referrer-policy',
|
||||
value: 'strict-origin-when-cross-origin',
|
||||
},
|
||||
{
|
||||
key: 'permissions-policy',
|
||||
value:
|
||||
'accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()',
|
||||
},
|
||||
],
|
||||
},
|
||||
];
|
||||
},
|
||||
async rewrites() {
|
||||
return [
|
||||
{
|
||||
source: '/ingest/:path*',
|
||||
destination: 'https://eu.posthog.com/:path*',
|
||||
},
|
||||
];
|
||||
},
|
||||
};
|
||||
|
||||
module.exports = withAxiom(withContentlayer(config));
|
||||
@ -1,59 +0,0 @@
|
||||
{
|
||||
"name": "@documenso/marketing",
|
||||
"version": "1.8.1-rc.7",
|
||||
"private": true,
|
||||
"license": "AGPL-3.0",
|
||||
"scripts": {
|
||||
"dev": "next dev -p 3001",
|
||||
"build": "npm run translate:extract --prefix ../../ && turbo run translate:compile && next build",
|
||||
"start": "next start -p 3001",
|
||||
"lint": "next lint",
|
||||
"lint:fix": "next lint --fix",
|
||||
"clean": "rimraf .next && rimraf node_modules",
|
||||
"copy:pdfjs": "node ../../scripts/copy-pdfjs.cjs",
|
||||
"translate:compile": "lingui compile --typescript"
|
||||
},
|
||||
"dependencies": {
|
||||
"@documenso/assets": "*",
|
||||
"@documenso/lib": "*",
|
||||
"@documenso/tailwind-config": "*",
|
||||
"@documenso/trpc": "*",
|
||||
"@documenso/ui": "*",
|
||||
"@hookform/resolvers": "^3.1.0",
|
||||
"@lingui/macro": "^4.11.3",
|
||||
"@lingui/react": "^4.11.3",
|
||||
"@openstatus/react": "^0.0.3",
|
||||
"cmdk": "^0.2.1",
|
||||
"contentlayer": "^0.3.4",
|
||||
"embla-carousel": "^8.1.3",
|
||||
"embla-carousel-autoplay": "^8.1.3",
|
||||
"embla-carousel-react": "^8.1.3",
|
||||
"framer-motion": "^10.12.8",
|
||||
"lucide-react": "^0.279.0",
|
||||
"luxon": "^3.4.0",
|
||||
"micro": "^10.0.1",
|
||||
"next": "14.2.6",
|
||||
"next-auth": "4.24.5",
|
||||
"next-axiom": "^1.5.1",
|
||||
"next-contentlayer": "^0.3.4",
|
||||
"next-plausible": "^3.10.1",
|
||||
"perfect-freehand": "^1.2.0",
|
||||
"posthog-js": "^1.77.3",
|
||||
"react": "^18",
|
||||
"react-confetti": "^6.1.0",
|
||||
"react-dom": "^18",
|
||||
"react-hook-form": "^7.43.9",
|
||||
"react-icons": "^4.11.0",
|
||||
"recharts": "^2.7.2",
|
||||
"sharp": "0.32.6",
|
||||
"typescript": "5.2.2",
|
||||
"zod": "^3.22.4"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@lingui/loader": "^4.11.3",
|
||||
"@lingui/swc-plugin": "4.0.8",
|
||||
"@types/node": "20.1.0",
|
||||
"@types/react": "^18",
|
||||
"@types/react-dom": "^18"
|
||||
}
|
||||
}
|
||||
@ -1,6 +0,0 @@
|
||||
module.exports = {
|
||||
plugins: {
|
||||
tailwindcss: {},
|
||||
autoprefixer: {},
|
||||
},
|
||||
};
|
||||
14
apps/marketing/process-env.d.ts
vendored
@ -1,14 +0,0 @@
|
||||
declare namespace NodeJS {
|
||||
export interface ProcessEnv {
|
||||
NEXT_PUBLIC_WEBAPP_URL?: string;
|
||||
NEXT_PUBLIC_MARKETING_URL?: string;
|
||||
NEXT_PRIVATE_INTERNAL_WEBAPP_URL?:string;
|
||||
|
||||
NEXT_PRIVATE_DATABASE_URL: string;
|
||||
|
||||
NEXT_PUBLIC_STRIPE_COMMUNITY_PLAN_MONTHLY_PRICE_ID: string;
|
||||
|
||||
NEXT_PRIVATE_STRIPE_API_KEY: string;
|
||||
NEXT_PRIVATE_STRIPE_WEBHOOK_SECRET: string;
|
||||
}
|
||||
}
|
||||
@ -1,7 +0,0 @@
|
||||
# General Issues
|
||||
Contact: https://github.com/documenso/documenso/issues/new?assignees=&labels=bug&projects=&template=bug-report.yml
|
||||
|
||||
# Report critical issues privately to let us take appropriate action before publishing.
|
||||
Contact: mailto:security@documenso.com
|
||||
Preferred-Languages: en
|
||||
Canonical: https://documenso.com/.well-known/security.txt
|
||||
|
Before Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 48 KiB |
|
Before Width: | Height: | Size: 14 KiB |
|
Before Width: | Height: | Size: 83 KiB |
|
Before Width: | Height: | Size: 89 KiB |
|
Before Width: | Height: | Size: 219 KiB |
|
Before Width: | Height: | Size: 212 KiB |
|
Before Width: | Height: | Size: 231 KiB |
|
Before Width: | Height: | Size: 24 KiB |
|
Before Width: | Height: | Size: 65 KiB |
|
Before Width: | Height: | Size: 181 KiB |
|
Before Width: | Height: | Size: 193 KiB |
|
Before Width: | Height: | Size: 80 KiB |
|
Before Width: | Height: | Size: 101 KiB |
|
Before Width: | Height: | Size: 50 KiB |
|
Before Width: | Height: | Size: 232 KiB |