v1.8.0-rc.4

## Description

When using 2fa enabled authentication on direct templates we run into an
issue where a 2fa token has been attached to a field but it's submitted
at a later point.

To better facilitate this we have introduced the ability to have a
window of valid tokens.

This won't affect other signing methods since tokens are verified
immediately after they're entered.

## Related Issue

N/A

## Changes Made

- Updated our validate2FAToken method to use a window based approach
rather than the default verify method.

## Testing Performed

- Created a series of tokens and tested upon different intervals and
windows to confirm functionality works as expected.

.cursorrules

@@ -0,0 +1,48 @@
+Code Style and Structure:
+- Write concise, technical TypeScript code with accurate examples
+- Use functional and declarative programming patterns; avoid classes
+- Prefer iteration and modularization over code duplication
+- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError)
+- Structure files: exported component, subcomponents, helpers, static content, types
+
+Naming Conventions:
+- Use lowercase with dashes for directories (e.g., components/auth-wizard)
+- Favor named exports for components
+
+TypeScript Usage:
+- Use TypeScript for all code; prefer interfaces over types
+- Avoid enums; use maps instead
+- Use functional components with TypeScript interfaces
+
+Syntax and Formatting:
+- Use the "function" keyword for pure functions
+- Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements
+- Use declarative JSX
+
+Error Handling and Validation:
+- Prioritize error handling: handle errors and edge cases early
+- Use early returns and guard clauses
+- Implement proper error logging and user-friendly messages
+- Use Zod for form validation
+- Model expected errors as return values in Server Actions
+- Use error boundaries for unexpected errors
+
+UI and Styling:
+- Use Shadcn UI, Radix, and Tailwind Aria for components and styling
+- Implement responsive design with Tailwind CSS; use a mobile-first approach
+
+Performance Optimization:
+- Minimize 'use client', 'useEffect', and 'setState'; favor React Server Components (RSC)
+- Wrap client components in Suspense with fallback
+- Use dynamic loading for non-critical components
+- Optimize images: use WebP format, include size data, implement lazy loading
+
+Key Conventions:
+- Use 'nuqs' for URL search parameter state management
+- Optimize Web Vitals (LCP, CLS, FID)
+- Limit 'use client':
+  - Favor server components and Next.js SSR
+  - Use only for Web API access in small components
+  - Avoid for data fetching or state management
+
+Follow Next.js docs for Data Fetching, Rendering, and Routing

.env.example

@@ -10,16 +10,25 @@ NEXT_PRIVATE_ENCRYPTION_KEY="CAFEBABE"
 NEXT_PRIVATE_ENCRYPTION_SECONDARY_KEY="DEADBEEF"
 
 # [[AUTH OPTIONAL]]
+# Find documentation on setting up Google OAuth here:
+# https://docs.documenso.com/developers/self-hosting/setting-up-oauth-providers#google-oauth-gmail
 NEXT_PRIVATE_GOOGLE_CLIENT_ID=""
 NEXT_PRIVATE_GOOGLE_CLIENT_SECRET=""
 
 NEXT_PRIVATE_OIDC_WELL_KNOWN=""
 NEXT_PRIVATE_OIDC_CLIENT_ID=""
 NEXT_PRIVATE_OIDC_CLIENT_SECRET=""
+NEXT_PRIVATE_OIDC_PROVIDER_LABEL="OIDC"
+# This can be used to still allow signups for OIDC connections
+# when signup is disabled via `NEXT_PUBLIC_DISABLE_SIGNUP`
+NEXT_PRIVATE_OIDC_ALLOW_SIGNUP=""
+NEXT_PRIVATE_OIDC_SKIP_VERIFY=""
 
 # [[URLS]]
 NEXT_PUBLIC_WEBAPP_URL="http://localhost:3000"
 NEXT_PUBLIC_MARKETING_URL="http://localhost:3001"
+# URL used by the web app to request itself (e.g. local background jobs)
+NEXT_PRIVATE_INTERNAL_WEBAPP_URL="http://localhost:3000"
 
 # [[DATABASE]]
 NEXT_PRIVATE_DATABASE_URL="postgres://documenso:password@127.0.0.1:54320/documenso"
@@ -84,6 +93,8 @@ NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS=
 NEXT_PRIVATE_SMTP_FROM_NAME="Documenso"
 # REQUIRED: Defines the email address to use as the from address.
 NEXT_PRIVATE_SMTP_FROM_ADDRESS="noreply@documenso.com"
+# OPTIONAL: Defines the service for nodemailer
+NEXT_PRIVATE_SMTP_SERVICE=
 # OPTIONAL: The API key to use for Resend.com
 NEXT_PRIVATE_RESEND_API_KEY=
 # OPTIONAL: The API key to use for MailChannels.

.eslintrc.cjs

@@ -11,4 +11,5 @@ module.exports = {
       rootDir: ['apps/*/'],
     },
   },
+  ignorePatterns: ['lingui.config.ts', 'packages/lib/translations/**/*.js'],
 };

.github/actions/cache-build/action.yml

@@ -3,7 +3,7 @@ description: 'Cache or restore if necessary'
 inputs:
   node_version:
     required: false
-    default: v18.x
+    default: v20.x
 runs:
   using: 'composite'
   steps:
@@ -17,7 +17,7 @@ runs:
           **/.turbo/**
           **/dist/**
 
-        key: prod-build-${{ github.run_id }}
+        key: prod-build-${{ github.run_id }}-${{ hashFiles('package-lock.json') }}
         restore-keys: prod-build-
 
     - run: npm run build

.github/actions/node-install/action.yml

@@ -2,7 +2,7 @@ name: 'Setup node and cache node_modules'
 inputs:
   node_version:
     required: false
-    default: v18.x
+    default: v20.x
 
 runs:
   using: 'composite'

.github/workflows/e2e-tests.yml

@@ -32,6 +32,9 @@ jobs:
 
       - name: Run Playwright tests
         run: npm run ci
+        env:
+          # Needed since we use next start which will set the NODE_ENV to production
+          NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH: './example/cert.p12'
 
       - uses: actions/upload-artifact@v4
         if: always()

.github/workflows/publish.yml

@@ -89,22 +89,35 @@ jobs:
           APP_VERSION="$(git name-rev --tags --name-only $(git rev-parse HEAD) | head -n 1 | sed 's/\^0//')"
           GIT_SHA="$(git rev-parse HEAD)"
 
-          docker manifest create \
-            documenso/documenso:latest \
-            --amend documenso/documenso-amd64:latest \
-            --amend documenso/documenso-arm64:latest \
+          # Check if the version is stable (no rc or beta in the version)
+          if [[ "$APP_VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
+            docker manifest create \
+              documenso/documenso:latest \
+              --amend documenso/documenso-amd64:latest \
+              --amend documenso/documenso-arm64:latest
+
+            docker manifest push documenso/documenso:latest
+          fi
+
+          if [[ "$APP_VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+-rc\.[0-9]+$ ]]; then
+            docker manifest create \
+              documenso/documenso:rc \
+              --amend documenso/documenso-amd64:rc \
+              --amend documenso/documenso-arm64:rc
+
+            docker manifest push documenso/documenso:rc
+          fi
 
           docker manifest create \
             documenso/documenso:$GIT_SHA \
             --amend documenso/documenso-amd64:$GIT_SHA \
-            --amend documenso/documenso-arm64:$GIT_SHA \
+            --amend documenso/documenso-arm64:$GIT_SHA
 
           docker manifest create \
             documenso/documenso:$APP_VERSION \
             --amend documenso/documenso-amd64:$APP_VERSION \
-            --amend documenso/documenso-arm64:$APP_VERSION \
+            --amend documenso/documenso-arm64:$APP_VERSION
 
-          docker manifest push documenso/documenso:latest
           docker manifest push documenso/documenso:$GIT_SHA
           docker manifest push documenso/documenso:$APP_VERSION
 
@@ -113,21 +126,34 @@ jobs:
           APP_VERSION="$(git name-rev --tags --name-only $(git rev-parse HEAD) | head -n 1 | sed 's/\^0//')"
           GIT_SHA="$(git rev-parse HEAD)"
 
-          docker manifest create \
-            ghcr.io/documenso/documenso:latest \
-            --amend ghcr.io/documenso/documenso-amd64:latest \
-            --amend ghcr.io/documenso/documenso-arm64:latest \
+          # Check if the version is stable (no rc or beta in the version)
+          if [[ "$APP_VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
+            docker manifest create \
+              ghcr.io/documenso/documenso:latest \
+              --amend ghcr.io/documenso/documenso-amd64:latest \
+              --amend ghcr.io/documenso/documenso-arm64:latest
+
+            docker manifest push ghcr.io/documenso/documenso:latest
+          fi
+
+          if [[ "$APP_VERSION" =~ ^[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 \
+              --amend ghcr.io/documenso/documenso-arm64:rc
+
+            docker manifest push ghcr.io/documenso/documenso:rc
+          fi
 
           docker manifest create \
             ghcr.io/documenso/documenso:$GIT_SHA \
             --amend ghcr.io/documenso/documenso-amd64:$GIT_SHA \
-            --amend ghcr.io/documenso/documenso-arm64:$GIT_SHA \
+            --amend ghcr.io/documenso/documenso-arm64:$GIT_SHA
 
           docker manifest create \
             ghcr.io/documenso/documenso:$APP_VERSION \
             --amend ghcr.io/documenso/documenso-amd64:$APP_VERSION \
-            --amend ghcr.io/documenso/documenso-arm64:$APP_VERSION \
+            --amend ghcr.io/documenso/documenso-arm64:$APP_VERSION
 
-          docker manifest push ghcr.io/documenso/documenso:latest
           docker manifest push ghcr.io/documenso/documenso:$GIT_SHA
           docker manifest push ghcr.io/documenso/documenso:$APP_VERSION

.github/workflows/translations-force-pull.yml

@@ -0,0 +1,51 @@
+# This is similar to the "Pull Translations" workflow, but without the conditional check to allow us to
+# forcefully pull down translations from Crowdin and create a PR regardless if all the translations are fulfilled.
+#
+# Intended to be used when we manually update translations in Crowdin UI and want to pull those down when
+# they already exist.
+
+name: 'Force pull translations'
+
+on:
+  workflow_dispatch:
+  workflow_call:
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  pull_translations:
+    name: Force pull translations
+    runs-on: ubuntu-latest
+    environment: Translations
+    permissions:
+      contents: write
+      pull-requests: write
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - uses: ./.github/actions/node-install
+
+      - name: Pull translations from Crowdin
+        uses: crowdin/github-action@v2
+        with:
+          upload_sources: false
+          upload_translations: false
+          download_translations: true
+          export_only_approved: false
+          localization_branch_name: chore/translations
+          commit_message: 'chore: add translations'
+          pull_request_title: 'chore: add translations'
+
+        env:
+          # A classic GitHub Personal Access Token with the 'repo' scope selected (the user should have write access to the repository).
+          GITHUB_TOKEN: ${{ secrets.GH_PAT }}
+
+          # A numeric ID, found at https://crowdin.com/project/<projectName>/tools/api
+          CROWDIN_PROJECT_ID: ${{ secrets.CROWDIN_PROJECT_ID }}
+
+          # Visit https://crowdin.com/settings#api-key to create this token
+          CROWDIN_PERSONAL_TOKEN: ${{ secrets.CROWDIN_PERSONAL_TOKEN }}

.github/workflows/translations-pull.yml

@@ -3,11 +3,10 @@
 name: 'Pull translations'
 
 on:
+  schedule:
+    - cron: '0 */2 * * *' # Every two hours.
   workflow_dispatch:
   workflow_call:
-  # Cron disabled until i18n PR is landed.
-  # schedule:
-  #   - cron: '0 */2 * * *' # Every two hours.
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
@@ -17,6 +16,7 @@ jobs:
   pull_translations:
     name: Pull translations
     runs-on: ubuntu-latest
+    environment: Translations
     permissions:
       contents: write
       pull-requests: write
@@ -46,7 +46,7 @@ jobs:
 
         env:
           # A classic GitHub Personal Access Token with the 'repo' scope selected (the user should have write access to the repository).
-          GITHUB_TOKEN: ${{ secrets.GITHUB_CROWDIN_TOKEN }}
+          GITHUB_TOKEN: ${{ secrets.GH_PAT }}
 
           # A numeric ID, found at https://crowdin.com/project/<projectName>/tools/api
           CROWDIN_PROJECT_ID: ${{ secrets.CROWDIN_PROJECT_ID }}

.github/workflows/translations-upload.yml

@@ -3,9 +3,8 @@ name: 'Extract and upload translations'
 on:
   workflow_dispatch:
   workflow_call:
-  # Disabled until i18n PR is landed.
-  # push:
-  #   branches: ['main']
+  push:
+    branches: ['main']
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
@@ -15,20 +14,19 @@ jobs:
   extract_translations:
     name: Extract and upload translations
     runs-on: ubuntu-latest
+    environment: Translations
     permissions:
       contents: write
     steps:
       - name: Checkout
         uses: actions/checkout@v4
         with:
-          ref: ${{ github.event.pull_request.head.ref }}
+          token: ${{ secrets.GH_PAT }}
 
       - uses: ./.github/actions/node-install
 
-      - name: Extract and compile translations
-        run: |
-          npm run translate:extract
-          npm run translate:compile
+      - name: Extract translations
+        run: npm run translate:extract
 
       - name: Check and commit any files created
         run: |

.gitignore

@@ -1,5 +1,7 @@
 # See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
 
+packages/prisma/generated/types.ts
+
 # dependencies
 node_modules
 .pnp

.prettierignore

@@ -4,6 +4,7 @@ public
 **/**/node_modules
 **/**/.next
 **/**/public
+packages/lib/translations/**/*.js
 
 *.lock
 *.log

.vscode/settings.json

@@ -5,12 +5,7 @@
   "editor.codeActionsOnSave": {
     "source.fixAll": "explicit"
   },
-  "eslint.validate": [
-    "typescript",
-    "typescriptreact",
-    "javascript",
-    "javascriptreact"
-  ],
+  "eslint.validate": ["typescript", "typescriptreact", "javascript", "javascriptreact"],
   "javascript.preferences.importModuleSpecifier": "non-relative",
   "javascript.preferences.useAliasesForRenames": false,
   "typescript.enablePromptUseWorkspaceTsdk": true,
@@ -20,4 +15,7 @@
   "[prisma]": {
     "editor.defaultFormatter": "Prisma.prisma"
   },
-}
+  "[typescriptreact]": {
+    "editor.defaultFormatter": "esbenp.prettier-vscode"
+  }
+}

README.md

@@ -261,6 +261,7 @@ npm run prisma:migrate-deploy
 Finally, you can start it with:
 
 ```
+cd apps/web
 npm run start
 ```
 
@@ -302,6 +303,10 @@ WantedBy=multi-user.target
 
 [![Deploy to Koyeb](https://www.koyeb.com/static/images/deploy/button.svg)](https://app.koyeb.com/deploy?type=git&repository=github.com/documenso/documenso&branch=main&name=documenso-app&builder=dockerfile&dockerfile=/docker/Dockerfile)
 
+## Elestio
+
+[![Deploy on Elestio](https://elest.io/images/logos/deploy-to-elestio-btn.png)](https://elest.io/open-source/documenso)
+
 ## Troubleshooting
 
 ### I'm not receiving any emails when using the developer quickstart.

apps/documentation/package.json

@@ -16,7 +16,7 @@
     "@documenso/tailwind-config": "*",
     "@documenso/trpc": "*",
     "@documenso/ui": "*",
-    "next": "14.0.3",
+    "next": "14.2.6",
     "next-plausible": "^3.12.0",
     "nextra": "^2.13.4",
     "nextra-theme-docs": "^2.13.4",
@@ -32,4 +32,4 @@
     "tailwindcss": "^3.3.0",
     "typescript": "^5"
   }
-}
+}

apps/documentation/pages/developers/_meta.json

@@ -12,5 +12,6 @@
     "title": "API & Integration Guides"
   },
   "public-api": "Public API",
+  "embedding": "Embedding",
   "webhooks": "Webhooks"
-}
+}

apps/documentation/pages/developers/contributing/_meta.json

@@ -0,0 +1,4 @@
+{
+  "index": "Getting Started",
+  "contributing-translations": "Contributing Translations"
+}

apps/documentation/pages/developers/contributing/contributing-translations.mdx

@@ -0,0 +1,69 @@
+---
+title: Contributing Translations
+description: Learn how to contribute translations to Documenso and become part of our community.
+---
+
+import { Callout, Steps } from 'nextra/components';
+
+# Contributing Translations
+
+We are always open for help with translations! Currently we utilise AI to generate the initial translations for new languages, which are then improved over time by our awesome community.
+
+If you are looking for development notes on translations, you can find them [here](/developers/local-development/translations).
+
+<Callout type="info">
+  Contributions are made through GitHub Pull Requests, so you will need a GitHub account to
+  contribute.
+</Callout>
+
+## Overview
+
+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
+
+Each PO file contains translations which look like this:
+
+```po
+#: apps/web/src/app/(signing)/sign/[token]/no-longer-available.tsx:61
+msgid "Want to send slick signing links like this one? <0>Check out Documenso.</0>"
+msgstr "Möchten Sie auffällige Signatur-Links wie diesen senden? <0>Überprüfen Sie Documenso.</0>"
+```
+
+- `msgid`: The original text in English (never edit this manually)
+- `msgstr`: The translated text in the target language
+
+<Callout type="warning">
+  Notice the `<0>` tags? These represent HTML elements and must remain in both the `msgid` and `msgstr`. Make sure to translate the content between these tags while keeping the tags intact.
+</Callout>
+
+## How to Contribute
+
+### 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.
+
+### Adding a New Language
+
+If you want to add translations for a language that doesn't exist yet:
+
+1. Create an issue in our GitHub repository requesting the addition of the new language.
+2. Wait for our team to review and approve the request.
+3. Once approved, we will set up the necessary files and kickstart the translations with AI to provide initial coverage.
+
+## Need Help?
+
+<Callout type="info">
+  If you have any questions, hop into our [Discord](https://documen.so/discord) and ask us directly!
+</Callout>
+
+Thank you for helping make Documenso more accessible to users around the world!

apps/documentation/pages/developers/contributing/index.mdx

@@ -1,5 +1,5 @@
 ---
-title: Contributing Guide
+title: Getting started
 description: Learn how to contribute to Documenso and become part of our community.
 ---
 

apps/documentation/pages/developers/embedding/index.mdx

@@ -0,0 +1,131 @@
+---
+title: Get Started
+description: Learn how to use embedding to bring signing to your own website or application
+---
+
+# 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.
+
+## Availability
+
+Embedding is currently available for all users on a **Teams Plan** and above, as well as **Early Adopter's** within a team (Early Adopters can create a team for free).
+
+In the future, we will roll out a **Platform Plan** that will offer additional enhancements for embedding, including the option to remove Documenso branding for a more customized experience.
+
+## How Embedding Works
+
+Embedding with Documenso allows you to handle document signing in two main ways:
+
+1. **Using Direct Templates**: Using direct templates you can have an evergreen template that upon completion will create a new document within Documenso.
+2. **Using a Signing Token**: A more advanced option for those running rich integrations with Documenso already. Given a recipients signing token you can embed the signing experience in your application rather than direct the recipient to Documenso.
+
+_For most use-cases we recommend using direct templates, however if you have a need for a more advanced integration, we are happy to help you get started._
+
+## Supported Frameworks
+
+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)   |
+
+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.
+
+## Embedding with Direct Templates
+
+#### Instructions
+
+To get started with embedding using a Direct Template we will need the URL segment which is also referred to as the token for the template.
+
+You can find your URL/Token by performing the following steps:
+
+1. **Navigate to your team's templates within Documenso**
+
+![Team Templates](/embedding/team-templates.png)
+
+2. **Click on the direct link template you want to embed**
+
+This will copy the URL to your clipboard, e.g. `https://stg-app.documenso.com/d/-WoSwWVT-fYOERS2MI37k`
+
+**For the above url the token is `-WoSwWVT-fYOERS2MI37k`**
+
+3. Provide the token to the `EmbedDirectTemplate` component in your frameworks SDK
+
+```jsx
+import { EmbedDirectTemplate } from '@documenso/embed-react';
+
+const MyEmbeddingComponent = () => {
+  const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
+
+  return <EmbedDirectTemplate token={token} />;
+};
+```
+
+---
+
+**Converting a regular template to a direct link template**
+
+If you don't currently have any direct link templates you can easily create one by selecting the "Direct Link" option within the actions dropdown on the templates table.
+
+This will show a dialog which will ask you to configure which recipient should be used as the direct link signer.
+
+![Enable Direct Link Template](/embedding/enable-direct-link.png)
+
+---
+
+## 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.
+
+#### Instructions
+
+1. Retrieve the signing token for the recipient document you want to embed
+
+This will typically be done using an API integration where signing tokens are provided as part of the response when creating a document. Alternatively you can manually get a signing link by clicking hovering over a recipients avatar and clicking their email on a document that you own.
+
+![Copy Recipient Token](/embedding/copy-recipient-token.png)
+
+With the signing url on our clipboard we can extract the token the same way we did for the direct link template.
+
+So `https://stg-app.documenso.com/sign/lm7Tp2_yhvFfzdeJQzYQF` will become `lm7Tp2_yhvFfzdeJQzYQF`
+
+2. Provide the token to the `EmbedSignDocument` component in your frameworks SDK
+
+```jsx
+import { EmbedSignDocument } from '@documenso/embed-react';
+
+const MyEmbeddingComponent = () => {
+  const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
+
+  return <EmbedSignDocument token={token} />;
+};
+```
+
+---
+
+## Using Embedding in Your Application
+
+Once you've obtained the appropriate tokens, you can integrate the signing experience into your application. For framework-specific instructions, please refer to the guides provided in our documentation for:
+
+- [React](/developers/embedding/react)
+- [Preact](/developers/embedding/preact)
+- [Vue](/developers/embedding/vue)
+- [Svelte](/developers/embedding/svelte)
+- [Solid](/developers/embedding/solid)
+
+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.
+
+## Stay Tuned for the Platform Plan
+
+While embedding is already a powerful tool, we're working on a **Platform Plan** that will introduce even more functionality. This plan will offer:
+
+- Additional customization options
+- The ability to remove Documenso branding
+- Additional controls for the signing experience
+
+More details will be shared as we approach the release.

apps/documentation/pages/developers/embedding/preact.mdx

@@ -0,0 +1,77 @@
+---
+title: Preact Integration
+description: Learn how to use our embedding SDK within your Preact application.
+---
+
+# Preact Integration
+
+Our Preact SDK provides a simple way to embed a signing experience within your Preact application. It supports both direct link templates and signing tokens.
+
+## Installation
+
+To install the SDK, run the following command:
+
+```bash
+npm install @documenso/embed-preact
+```
+
+## 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.
+
+```jsx
+import { EmbedDirectTemplate } from '@documenso/embed-preact';
+
+const MyEmbeddingComponent = () => {
+  const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
+
+  return <EmbedDirectTemplate token={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                  |
+| externalId          | string (optional)   | The external ID to be used for the document that will be created upon completion           |
+| 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 has been signed                       |
+| onFieldUnsigned     | function (optional) | A callback function that will be called when a field has been unsigned                     |
+
+### Signing Token
+
+If you have a signing token, you can provide it to the `EmbedSignDocument` component.
+
+```jsx
+import { EmbedSignDocument } from '@documenso/embed-preact';
+
+const MyEmbeddingComponent = () => {
+  const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
+
+  return <EmbedSignDocument token={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             |

apps/documentation/pages/developers/embedding/react.mdx

@@ -0,0 +1,77 @@
+---
+title: React Integration
+description: Learn how to use our embedding SDK within your React application.
+---
+
+# React Integration
+
+Our React SDK provides a simple way to embed a signing experience within your React application. It supports both direct link templates and signing tokens.
+
+## Installation
+
+To install the SDK, run the following command:
+
+```bash
+npm install @documenso/embed-react
+```
+
+## 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.
+
+```jsx
+import { EmbedDirectTemplate } from '@documenso/embed-react';
+
+const MyEmbeddingComponent = () => {
+  const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
+
+  return <EmbedDirectTemplate token={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                  |
+| externalId          | string (optional)   | The external ID to be used for the document that will be created upon completion           |
+| 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 has been signed                       |
+| onFieldUnsigned     | function (optional) | A callback function that will be called when a field has been unsigned                     |
+
+### Signing Token
+
+If you have a signing token, you can provide it to the `EmbedSignDocument` component.
+
+```jsx
+import { EmbedSignDocument } from '@documenso/embed-react';
+
+const MyEmbeddingComponent = () => {
+  const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
+
+  return <EmbedSignDocument token={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             |

apps/documentation/pages/developers/embedding/solid.mdx

@@ -0,0 +1,77 @@
+---
+title: Solid.js Integration
+description: Learn how to use our embedding SDK within your Solid.js application.
+---
+
+# Solid.js Integration
+
+Our Solid.js SDK provides a simple way to embed a signing experience within your Solid.js application. It supports both direct link templates and signing tokens.
+
+## Installation
+
+To install the SDK, run the following command:
+
+```bash
+npm install @documenso/embed-solid
+```
+
+## 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.
+
+```jsx
+import { EmbedDirectTemplate } from '@documenso/embed-solid';
+
+const MyEmbeddingComponent = () => {
+  const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
+
+  return <EmbedDirectTemplate token={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                  |
+| externalId          | string (optional)   | The external ID to be used for the document that will be created upon completion           |
+| 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 has been signed                       |
+| onFieldUnsigned     | function (optional) | A callback function that will be called when a field has been unsigned                     |
+
+### Signing Token
+
+If you have a signing token, you can provide it to the `EmbedSignDocument` component.
+
+```jsx
+import { EmbedSignDocument } from '@documenso/embed-solid';
+
+const MyEmbeddingComponent = () => {
+  const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
+
+  return <EmbedSignDocument token={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             |

apps/documentation/pages/developers/embedding/svelte.mdx

@@ -0,0 +1,79 @@
+---
+title: Svelte Integration
+description: Learn how to use our embedding SDK within your Svelte application.
+---
+
+# Svelte Integration
+
+Our Svelte SDK provides a simple way to embed a signing experience within your Svelte application. It supports both direct link templates and signing tokens.
+
+## Installation
+
+To install the SDK, run the following command:
+
+```bash
+npm install @documenso/embed-svelte
+```
+
+## 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.
+
+```html
+<script lang="ts">
+  import { EmbedDirectTemplate } from '@documenso/embed-svelte';
+
+  const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
+</script>
+
+<template>
+  <EmbedDirectTemplate {token} />
+</template>
+```
+
+#### 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                  |
+| externalId          | string (optional)   | The external ID to be used for the document that will be created upon completion           |
+| 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 has been signed                       |
+| onFieldUnsigned     | function (optional) | A callback function that will be called when a field has been unsigned                     |
+
+### Signing Token
+
+If you have a signing token, you can provide it to the `EmbedSignDocument` component.
+
+```jsx
+import { EmbedSignDocument } from '@documenso/embed-svelte';
+
+const MyEmbeddingComponent = () => {
+  const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
+
+  return <EmbedSignDocument token={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             |

apps/documentation/pages/developers/embedding/vue.mdx

@@ -0,0 +1,79 @@
+---
+title: Vue Integration
+description: Learn how to use our embedding SDK within your Vue application.
+---
+
+# Vue Integration
+
+Our Vue SDK provides a simple way to embed a signing experience within your Vue application. It supports both direct link templates and signing tokens.
+
+## Installation
+
+To install the SDK, run the following command:
+
+```bash
+npm install @documenso/embed-vue
+```
+
+## 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.
+
+```html
+<script setup lang="ts">
+  import { EmbedDirectTemplate } from '@documenso/embed-vue';
+
+  const token = ref('YOUR_TOKEN_HERE'); // Replace with the actual token
+</script>
+
+<template>
+  <EmbedDirectTemplate :token="token" />
+</template>
+```
+
+#### 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                  |
+| externalId          | string (optional)   | The external ID to be used for the document that will be created upon completion           |
+| 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 has been signed                       |
+| onFieldUnsigned     | function (optional) | A callback function that will be called when a field has been unsigned                     |
+
+### Signing Token
+
+If you have a signing token, you can provide it to the `EmbedSignDocument` component.
+
+```jsx
+import { EmbedSignDocument } from '@documenso/embed-vue';
+
+const MyEmbeddingComponent = () => {
+  const token = 'YOUR_TOKEN_HERE'; // Replace with the actual token
+
+  return <EmbedSignDocument token={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             |

apps/documentation/pages/developers/local-development/_meta.json

@@ -3,5 +3,6 @@
   "quickstart": "Developer Quickstart",
   "manual": "Manual Setup",
   "gitpod": "Gitpod",
-  "signing-certificate": "Signing Certificate"
-}
+  "signing-certificate": "Signing Certificate",
+  "translations": "Translations"
+}

apps/documentation/pages/developers/local-development/signing-certificate.mdx

@@ -11,6 +11,10 @@ Digitally signing documents requires a signing certificate in `.p12` format. You
 
 Follow the steps below to create a free, self-signed certificate for local development.
 
+<Callout type="warning">
+  These steps should be run on a UNIX based system, otherwise you may run into an error.
+</Callout>
+
 <Steps>
 
 ### Generate Private Key
@@ -38,11 +42,17 @@ You will be prompted to enter some information, such as the certificate's Common
 Combine the private key and the self-signed certificate to create a `.p12` certificate. Use the following command:
 
 ```bash
-openssl pkcs12 -export -out certificate.p12 -inkey private.key -in certificate.crt
+openssl pkcs12 -export -out certificate.p12 -inkey private.key -in certificate.crt -legacy
 ```
 
 <Callout type="warning">
-  If you get the error "Error: Failed to get private key bags", add the `-legacy` flag to the command `openssl pkcs12 -export -out certificate.p12 -inkey private.key -in certificate.crt -legacy`.
+When running the application in Docker, you may encounter permission issues when attempting to sign documents using your certificate (.p12) file. This happens because the application runs as a non-root user inside the container and needs read access to the certificate.
+
+To resolve this, you'll need to update the certificate file permissions to allow the container user 1001, which runs NextJS, to read it:
+
+```bash
+sudo chown 1001 certificate.p12
+```
 
 </Callout>
 
@@ -54,8 +64,8 @@ Note that for local development, the password can be left empty.
 
 ### Add Certificate to the Project
 
-Finally, add the certificate to the project. Place the `certificate.p12` file in the `/apps/web/resources` directory. If the directory doesn't exist, create it.
+Use the `NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH` environment variable to point at the certificate you created.
 
-The final file path should be `/apps/web/resources/certificate.p12`.
+Details about environment variables associated with certificates can be found [here](/developers/self-hosting/signing-certificate#configure-documenso-to-use-the-certificate).
 
 </Steps>

apps/documentation/pages/developers/local-development/translations.mdx

@@ -0,0 +1,128 @@
+---
+title: Translations
+description: Handling translations in code.
+---
+
+# About
+
+Documenso uses the following stack to handle translations:
+
+- [Lingui](https://lingui.dev/) - React i10n library
+- [Crowdin](https://crowdin.com/) - Handles syncing translations
+- [OpenAI](https://openai.com/) - Provides AI translations
+
+Additional reading can be found in the [Lingui documentation](https://lingui.dev/introduction).
+
+## Requirements
+
+You **must** insert **`setupI18nSSR()`** when creating any of the following files:
+
+- Server layout.tsx
+- Server page.tsx
+- Server loading.tsx
+
+Server meaning it does not have `'use client'` in it.
+
+```tsx
+import { setupI18nSSR } from '@documenso/lib/client-only/providers/i18n.server';
+
+export default function SomePage() {
+  setupI18nSSR(); // Required if there are translations within the page, or nested in components.
+
+  // Rest of code...
+}
+```
+
+Additional information can be found [here.](https://lingui.dev/tutorials/react-rsc#pages-layouts-and-lingui)
+
+## Quick guide
+
+If you require more in-depth information, please see the [Lingui documentation](https://lingui.dev/introduction).
+
+### HTML
+
+Wrap all text to translate in **`<Trans></Trans>`** tags exported from **@lingui/macro** (not @lingui/react).
+
+```html
+<h1>
+  <Trans>Title</Trans>
+</h1>
+```
+
+For text that is broken into elements, but represent a whole sentence, you must wrap it in a Trans tag so ensure the full message is extracted correctly.
+
+```html
+<h1>
+  <Trans>
+    This is one
+    <span className="text-foreground/60">full</span>
+    <a href="https://documenso.com">sentence</a>
+  </Trans>
+</h1>
+```
+
+### Constants outside of react components
+
+```tsx
+import { Trans, msg } from '@lingui/macro';
+import { useLingui } from '@lingui/react';
+
+// Wrap text in msg`text to translate` when it's in a constant here, or another file/package.
+export const CONSTANT_WITH_MSG = {
+  foo: msg`Hello`,
+  bar: msg`World`,
+};
+
+export const SomeComponent = () => {
+  const { _ } = useLingui();
+
+  return (
+    <div>
+      {/* This will render the correct translated text. */}
+      <p>{_(CONSTANT_WITH_MSG.foo)}</p>
+    </div>
+  );
+};
+```
+
+### Plurals
+
+Lingui provides a Plural component to make it easy. See full documentation [here.](https://lingui.dev/ref/macro#plural-1)
+
+```tsx
+// Basic usage.
+<Plural one="1 Recipient" other="# Recipients" value={recipients.length} />
+```
+
+### Dates
+
+Lingui provides a [DateTime instance](https://lingui.dev/ref/core#i18n.date) with the configured locale.
+
+#### Server components
+
+Note that the i18n instance is coming from **setupI18nSSR**.
+
+```tsx
+import { Trans } from '@lingui/macro';
+import { useLingui } from '@lingui/react';
+
+export const SomeComponent = () => {
+  const { i18n } = setupI18nSSR();
+
+  return <Trans>The current date is {i18n.date(new Date(), { dateStyle: 'short' })}</Trans>;
+};
+```
+
+#### Client components
+
+Note that the i18n instance is coming from the **import**.
+
+```tsx
+import { i18n } from '@lingui/core';
+import { Trans } from '@lingui/macro';
+import { useLingui } from '@lingui/react';
+
+export const SomeComponent = () => {
+  return <Trans>The current date is {i18n.date(new Date(), { dateStyle: 'short' })}</Trans>;
+};
+```

apps/documentation/pages/developers/public-api/reference.mdx

@@ -0,0 +1,507 @@
+---
+title: API Reference
+description: Reference documentation for the Documenso public API.
+---
+
+import { Callout, Steps } from 'nextra/components';
+
+# API Reference
+
+The Swagger UI for the API is available at [/api/v1/openapi](https://app.documenso.com/api/v1/openapi). This page provides detailed information about the API endpoints, request and response formats, and authentication requirements.
+
+## Upload a Document
+
+Uploading a document to your Documenso account requires a two-step process.
+
+<Steps>
+
+### Create Document
+
+First, you need to make a `POST` request to the `/api/v1/documents` endpoint, which takes a JSON payload with the following fields:
+
+```json
+{
+  "title": "string",
+  "externalId": "string",
+  "recipients": [
+    {
+      "name": "string",
+      "email": "user@example.com",
+      "role": "SIGNER",
+      "signingOrder": 0
+    }
+  ],
+  "meta": {
+    "subject": "string",
+    "message": "string",
+    "timezone": "Etc/UTC",
+    "dateFormat": "yyyy-MM-dd hh:mm a",
+    "redirectUrl": "string",
+    "signingOrder": "PARALLEL"
+  },
+  "authOptions": {
+    "globalAccessAuth": "ACCOUNT",
+    "globalActionAuth": "ACCOUNT"
+  },
+  "formValues": {
+    "additionalProp1": "string",
+    "additionalProp2": "string",
+    "additionalProp3": "string"
+  }
+}
+```
+
+- `title` _(required)_ - This represents the document's title.
+- `externalId` - This is an optional field that you can use to store an external identifier for the document. This can be useful for tracking the document in your system.
+- `recipients` _(required)_ - This is an array of recipient objects. Each recipient object has the following fields:
+  - `name` - The name of the recipient.
+  - `email` - The email address of the recipient.
+  - `role` - The role of the recipient. See the [available roles](/users/signing-documents#roles).
+  - `signingOrder` - The order in which the recipient should sign the document. This is an integer value starting from 0.
+- `meta` - This object contains additional metadata for the document. It has the following fields:
+  - `subject` - The subject of the email that will be sent to the recipients.
+  - `message` - The message of the email that will be sent to the recipients.
+  - `timezone` - The timezone in which the document should be signed.
+  - `dateFormat` - The date format that should be used in the document.
+  - `redirectUrl` - The URL to which the user should be redirected after signing the document.
+  - `signingOrder` - The signing order for the document. This can be either `SEQUENTIAL` or `PARALLEL`.
+- `authOptions` - This object contains authentication options for the document. It has the following fields:
+  - `globalAccessAuth` - The authentication level required to access the document. This can be either `ACCOUNT` or `null`.
+    - If the document is set to `ACCOUNT`, all recipients must authenticate with their Documenso account to access it.
+    - The document can be accessed without a Documenso account if it's set to `null`.
+  - `globalActionAuth` - The authentication level required to perform actions on the document. This can be `ACCOUNT`, `PASSKEY`, `TWO_FACTOR_AUTH`, or `null`.
+    - If the document is set to `ACCOUNT`, all recipients must authenticate with their Documenso account to perform actions on the document.
+    - If it's set to `PASSKEY`, all recipients must have the passkey active to perform actions on the document.
+    - If it's set to `TWO_FACTOR_AUTH`, all recipients must have the two-factor authentication active to perform actions on the document.
+    - If it's set to `null`, all the recipients can perform actions on the document without any authentication.
+- `formValues` - This object contains additional form values for the document. This property only works with native PDF fields and accepts three types: number, text and boolean.
+
+<Callout type="info">
+  The `globalActionAuth` property is only available for Enterprise accounts.
+</Callout>
+
+Here's an example of the JSON payload for uploading a document:
+
+```json
+{
+  "title": "my-document.pdf",
+  "externalId": "12345",
+  "recipients": [
+    {
+      "name": "Alex Blake",
+      "email": "alexblake@email.com",
+      "role": "SIGNER",
+      "signingOrder": 1
+    },
+    {
+      "name": "Ash Drew",
+      "email": "ashdrew@email.com",
+      "role": "SIGNER",
+      "signingOrder": 0
+    }
+  ],
+  "meta": {
+    "subject": "Sign the document",
+    "message": "Hey there, please sign this document.",
+    "timezone": "Europe/London",
+    "dateFormat": "Day, Month Year",
+    "redirectUrl": "https://mysite.com/welcome",
+    "signingOrder": "SEQUENTIAL"
+  },
+  "authOptions": {
+    "globalAccessAuth": "ACCOUNT",
+    "globalActionAuth": "PASSKEY"
+  }
+}
+```
+
+### Upload to S3
+
+A successful API call to the `/api/v1/documents` endpoint returns a JSON response containing the upload URL, document ID, and recipient information.
+
+The upload URL is a pre-signed S3 URL that you can use to upload the document to the Documenso (or your) S3 bucket. You need to make a `PUT` request to this URL to upload the document.
+
+```json
+{
+  "uploadUrl": "https://<url>/<bucket-name>/<id>/my-document.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=<credentials>&X-Amz-Date=<date>&X-Amz-Expires=3600&X-Amz-Signature=<signature>&X-Amz-SignedHeaders=host&x-id=PutObject",
+  "documentId": 51,
+  "recipients": [
+    {
+      "recipientId": 11,
+      "name": "Alex Blake",
+      "email": "alexblake@email.com",
+      "token": "<unique-signer-token>",
+      "role": "SIGNER",
+      "signingOrder": 1,
+      "signingUrl": "https://app.documenso.com/sign/<unique-signer-token>"
+    },
+    {
+      "recipientId": 12,
+      "name": "Ash Drew",
+      "email": "ashdrew@email.com",
+      "token": "<unique-signer-token>",
+      "role": "SIGNER",
+      "signingOrder": 0,
+      "signingUrl": "https://app.documenso.com/sign/<unique-signer-token>"
+    }
+  ]
+}
+```
+
+When you make the `PUT` request to the pre-signed URL, you need to include the document file you want to upload. The image below shows how to upload a document to the S3 bucket via Postman.
+
+![Upload document to S3](/api-reference/upload-document-to-s3.webp)
+
+Here's an example of how to upload a document using cURL:
+
+```bash
+curl --location --request PUT 'https://<url>/<bucket-name>/<id>/my-document.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=<credentials>&X-Amz-Date=<date>&X-Amz-Expires=3600&X-Amz-Signature=<signature>&X-Amz-SignedHeaders=host&x-id=PutObject' \
+--form '=@"/Users/my-user/Documents/documenso.pdf"'
+```
+
+Once the document is successfully uploaded, you can access it in your Documenso account dashboard. The screenshot below shows the document that was uploaded via the API.
+
+![Uploaded Document](/api-reference/document-uploaded-to-documenso-via-api.webp)
+
+</Steps>
+
+## Generate Document From Template
+
+Documenso allows you to generate documents from templates. This is useful when you have a standard document format you want to reuse.
+
+The API endpoint for generating a document from a template is `/api/v1/templates/{templateId}/generate-document`, and it takes a JSON payload with the following fields:
+
+```json
+{
+  "title": "string",
+  "externalId": "string",
+  "recipients": [
+    {
+      "id": 0,
+      "name": "string",
+      "email": "user@example.com",
+      "signingOrder": 0
+    }
+  ],
+  "meta": {
+    "subject": "string",
+    "message": "string",
+    "timezone": "string",
+    "dateFormat": "string",
+    "redirectUrl": "string",
+    "signingOrder": "PARALLEL"
+  },
+  "authOptions": {
+    "globalAccessAuth": "ACCOUNT",
+    "globalActionAuth": "ACCOUNT"
+  },
+  "formValues": {
+    "additionalProp1": "string",
+    "additionalProp2": "string",
+    "additionalProp3": "string"
+  }
+}
+```
+
+The JSON payload is identical to the payload for uploading a document, so you can read more about the fields in the [Create Document](/developers/public-api/reference#create-document) step. For this API endpoint, the `recipients` property is required.
+
+<Steps>
+
+### Grab the Template ID
+
+The first step is to retrieve the template ID from the Documenso dashboard. You can find the template ID in the URL by navigating to the template details page.
+
+![Template ID](/api-reference/documenso-template-id.webp)
+
+In this case, the template ID is "99999".
+
+### Retrieve the Recipient(s) ID(s)
+
+Once you have the template ID, the next step involves retrieving the ID(s) of the recipient(s) from the template. You can do this by making a GET request to `/api/v1/templates/{template-id}`.
+
+A successful response looks as follows:
+
+```json
+{
+  "id": 0,
+  "externalId": "string",
+  "type": "PUBLIC",
+  "title": "string",
+  "userId": 0,
+  "teamId": 0,
+  "templateDocumentDataId": "string",
+  "createdAt": "2024-10-11T08:46:58.247Z",
+  "updatedAt": "2024-10-11T08:46:58.247Z",
+  "templateMeta": {
+    "id": "string",
+    "subject": "string",
+    "message": "string",
+    "timezone": "string",
+    "dateFormat": "string",
+    "templateId": 0,
+    "redirectUrl": "string",
+    "signingOrder": "PARALLEL"
+  },
+  "directLink": {
+    "token": "string",
+    "enabled": true
+  },
+  "templateDocumentData": {
+    "id": "string",
+    "type": "S3_PATH",
+    "data": "string"
+  },
+  "Field": [
+    {
+      "id": 0,
+      "recipientId": 0,
+      "type": "SIGNATURE",
+      "page": 0,
+      "positionX": "string",
+      "positionY": "string",
+      "width": "string",
+      "height": "string"
+    }
+  ],
+  "Recipient": [
+    {
+      "id": 0,
+      "email": "user@example.com",
+      "name": "string",
+      "signingOrder": 0,
+      "authOptions": "string",
+      "role": "CC"
+    }
+  ]
+}
+```
+
+You'll need the recipient(s) ID(s) for the next step.
+
+### Generate the Document
+
+To generate a document from the template, you need to make a POST request to the `/api/v1/templates/{template-id}/generate-document` endpoint.
+
+At the minimum, you must provide the `recipients` array in the JSON payload. Here's an example of the JSON payload:
+
+```json
+{
+  "recipients": [
+    {
+      "id": 0,
+      "name": "Ash Drew",
+      "email": "ashdrew@email.com",
+      "signingOrder": 0
+    }
+  ]
+}
+```
+
+Filling the `recipients` array with the corresponding recipient for each template placeholder recipient is recommended. For example, if the template has two placeholders, you should provide at least two recipients in the `recipients` array. Otherwise, the document will be sent to inexistent recipients such as `<recipient.1@documenso.com>`. However, the recipients can always be edited via the API or the web app.
+
+A successful response will contain the document ID and recipient(s) information.
+
+```json
+{
+  "documentId": 999,
+  "recipients": [
+    {
+      "recipientId": 0,
+      "name": "Ash Drew",
+      "email": "ashdrew@email.com",
+      "token": "<signing-token>",
+      "role": "SIGNER",
+      "signingOrder": null,
+      "signingUrl": "https://app.documenso.com/sign/<signing-token>"
+    }
+  ]
+}
+```
+
+You can now access the document in your Documenso account dashboard. The screenshot below shows the document that was generated from the template.
+
+![Generated Document](/api-reference/document-generated-from-template.webp)
+
+</Steps>
+
+## Add Fields to Document
+
+The API allows you to add fields to a document via the `/api/v1/documents/{documentId}/fields` endpoint. This is useful when you want to add fields to a document before sending it to recipients.
+
+To add fields to a document, you need to make a `POST` request with a JSON payload containing the field(s) information.
+
+```json
+{
+  "recipientId": 0,
+  "type": "SIGNATURE",
+  "pageNumber": 0,
+  "pageX": 0,
+  "pageY": 0,
+  "pageWidth": 0,
+  "pageHeight": 0,
+  "fieldMeta": {
+    "label": "string",
+    "placeholder": "string",
+    "required": true,
+    "readOnly": true,
+    "type": "text",
+    "text": "string",
+    "characterLimit": 0
+  }
+}
+
+// or
+
+[
+  {
+    "recipientId": 0,
+    "type": "SIGNATURE",
+    "pageNumber": 0,
+    "pageX": 0,
+    "pageY": 0,
+    "pageWidth": 0,
+    "pageHeight": 0
+  },
+  {
+    "recipientId": 0,
+    "type": "TEXT",
+    "pageNumber": 0,
+    "pageX": 0,
+    "pageY": 0,
+    "pageWidth": 0,
+    "pageHeight": 0,
+    "fieldMeta": {
+      "label": "string",
+      "placeholder": "string",
+      "required": true,
+      "readOnly": true,
+      "type": "text",
+      "text": "string",
+      "characterLimit": 0
+    }
+  }
+]
+```
+
+<Callout type="info">This endpoint accepts either one field or an array of fields.</Callout>
+
+Before adding fields to a document, you need each recipient's ID. If the document already has recipients, you can query the document to retrieve the recipient's details. If the document has no recipients, you need to add a recipient via the UI or API before adding a field.
+
+<Steps>
+
+### Retrieve the Recipient(s) ID(s)
+
+Perform a `GET` request to the `/api/v1/documents/{id}` to retrieve the details of a specific document, including the recipient's information.
+
+An example response would look like this:
+
+```json
+{
+  "id": 137,
+  "externalId": null,
+  "userId": 3,
+  "teamId": null,
+  "title": "documenso.pdf",
+  "status": "DRAFT",
+  "documentDataId": "<document-data-id>",
+  "createdAt": "2024-10-11T12:29:12.725Z",
+  "updatedAt": "2024-10-11T12:29:12.725Z",
+  "completedAt": null,
+  "recipients": [
+    {
+      "id": 55,
+      "documentId": 137,
+      "email": "ashdrew@email.com",
+      "name": "Ash Drew",
+      "role": "SIGNER",
+      "signingOrder": null,
+      "token": "<signing-token>",
+      "signedAt": null,
+      "readStatus": "NOT_OPENED",
+      "signingStatus": "NOT_SIGNED",
+      "sendStatus": "NOT_SENT",
+      "signingUrl": "https://app.documenso.com/sign/<signing-token>"
+    }
+  ]
+}
+```
+
+From this response, you'll only need the recipient ID, which is `55` in this case.
+
+### (OR) Add a Recipient
+
+If the document doesn't already have recipient(s), you can add recipient(s) via the API. Make a `POST` request to the `/api/v1/documents/{documentId}/recipients` endpoint with the recipient information. This endpoint takes the following JSON payload:
+
+```json
+{
+  "name": "string",
+  "email": "user@example.com",
+  "role": "SIGNER",
+  "signingOrder": 0,
+  "authOptions": {
+    "actionAuth": "ACCOUNT"
+  }
+}
+```
+
+<Callout type="info">The `authOptions` property is only available for Enterprise accounts.</Callout>
+
+Here's an example of the JSON payload for adding a recipient:
+
+```json
+{
+  "name": "Ash Drew",
+  "email": "ashdrew@email.com",
+  "role": "SIGNER",
+  "signingOrder": 0
+}
+```
+
+A successful request will return a JSON response with the newly added recipient. You can now use the recipient ID to add fields to the document.
+
+### Add Field(s)
+
+Now you can make a `POST` request to the `/api/v1/documents/{documentId}/fields` endpoint with the field(s) information. Here's an example:
+
+```json
+[
+  {
+    "recipientId": 55,
+    "type": "SIGNATURE",
+    "pageNumber": 1,
+    "pageX": 50,
+    "pageY": 20,
+    "pageWidth": 25,
+    "pageHeight": 5
+  },
+  {
+    "recipientId": 55,
+    "type": "TEXT",
+    "pageNumber": 1,
+    "pageX": 20,
+    "pageY": 50,
+    "pageWidth": 30,
+    "pageHeight": 7.5,
+    "fieldMeta": {
+      "label": "Address",
+      "placeholder": "32 New York Street, 41241",
+      "required": true,
+      "readOnly": false,
+      "type": "text",
+      "text": "32 New York Street, 41241",
+      "characterLimit": 40
+    }
+  }
+]
+```
+
+<Callout type="info">
+  The `text` field represents the default value of the field. If the user doesn't provide any other
+  value, this is the value that will be used to sign the field.
+</Callout>
+
+A successful request will return a JSON response with the newly added fields. The image below illustrates the fields added to the document via the API.
+
+![A screenshot of the document in the Documenso editor](/api-reference/fields-added-via-api.webp)
+
+</Steps>

apps/documentation/pages/developers/self-hosting/_meta.json

@@ -1,5 +1,6 @@
 {
   "index": "Getting Started",
   "signing-certificate": "Signing Certificate",
-  "how-to": "How To"
-}
+  "how-to": "How To",
+  "setting-up-oauth-providers": "Setting up OAuth Providers"
+}

apps/documentation/pages/developers/self-hosting/how-to.mdx

@@ -5,6 +5,8 @@ description: Learn how to self-host Documenso on your server or cloud infrastruc
 
 import { Callout, Steps } from 'nextra/components';
 
+import { CallToAction } from '@documenso/ui/components/call-to-action';
+
 # Self Hosting
 
 We support various deployment methods and are actively working on adding more. Please let us know if you have a specific deployment method in mind!
@@ -131,7 +133,7 @@ volumes:
 After updating the volume binding, save the `compose.yml` file and run the following command to start the containers:
 
 ```bash
-docker-compose --env-file ./.env -d up
+docker-compose --env-file ./.env up -d
 ```
 
 The command will start the PostgreSQL database and the Documenso application containers.
@@ -273,3 +275,5 @@ We offer several alternative deployment methods for Documenso if you need more o
 ## Koyeb
 
 [![Deploy to Koyeb](https://www.koyeb.com/static/images/deploy/button.svg)](https://app.koyeb.com/deploy?type=git&repository=github.com/documenso/documenso&branch=main&name=documenso-app&builder=dockerfile&dockerfile=/docker/Dockerfile)
+
+<CallToAction className="mt-12" utmSource="self-hosting" />

apps/documentation/pages/developers/self-hosting/index.mdx

@@ -3,6 +3,10 @@ title: Getting Started with Self-Hosting
 description: A step-by-step guide to setting up and hosting your own Documenso instance.
 ---
 
+import { CallToAction } from '@documenso/ui/components/call-to-action';
+
 # Getting Started with Self-Hosting
 
 This is a step-by-step guide to setting up and hosting your own Documenso instance. Before getting started, [select the right license for you](/users/licenses).
+
+<CallToAction className="mt-12" utmSource="self-hosting" />

apps/documentation/pages/developers/self-hosting/setting-up-oauth-providers.mdx

@@ -0,0 +1,29 @@
+---
+title: Setting up OAuth Providers
+description: Learn how to set up OAuth providers for your own instance of Documenso.
+---
+
+## Google OAuth (Gmail)
+
+To use Google OAuth, you will need to create a Google Cloud Platform project and enable the Google Identity and Access Management (IAM) API. You will also need to create a new OAuth client ID and download the client secret.
+
+### Create and configure a new OAuth client ID
+
+1. Go to the [Google Cloud Platform Console](https://console.cloud.google.com/)
+2. From the projects list, select a project or create a new one
+3. If the APIs & services page isn't already open, open the console left side menu and select APIs & services
+4. On the left, click Credentials
+5. Click New Credentials, then select OAuth client ID
+6. When prompted to select an application type, select Web application
+7. Enter a name for your client ID, and click Create
+8. Click the download button to download the client secret
+9. Set the authorized javascript origins to `https://<documenso-domain>`
+10. Set the authorized redirect URIs to `https://<documenso-domain>/api/auth/callback/google`
+11. In the Documenso environment variables, set the following:
+
+```
+NEXT_PRIVATE_GOOGLE_CLIENT_ID=<your-client-id>
+NEXT_PRIVATE_GOOGLE_CLIENT_SECRET=<your-client-secret>
+```
+
+Finally verify the signing in with Google works by signing in with your Google account and checking the email address in your profile.

apps/documentation/pages/developers/webhooks.mdx

@@ -37,7 +37,7 @@ To create a new webhook subscription, you need to provide the following informat
 
 - 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`.
-- Optionally, you can provide a secret key that will be used to sign the payload. This key will be included in the `X-Documenso-Signature` header of the request.
+- Optionally, you can provide a secret key that will be used to sign the payload. This key will be included in the `X-Documenso-Secret` header of the request.
 
 ![A screenshot of the Create Webhook modal that shows the URL input field and the event checkboxes](/webhook-images/webhooks-page-create-webhook-modal.webp)
 

apps/documentation/pages/users/_meta.json

@@ -1,5 +1,6 @@
 {
   "index": "Introduction",
+  "support": "Support",
   "-- How To Use": {
     "type": "separator",
     "title": "How To Use"
@@ -9,10 +10,13 @@
   "signing-documents": "Signing Documents",
   "templates": "Templates",
   "direct-links": "Direct Signing Links",
+  "document-visibility": "Document Visibility",
+  "teams": "Teams",
   "-- Legal Overview": {
     "type": "separator",
     "title": "Legal Overview"
   },
+  "fair-use": "Fair Use Policy",
   "licenses": "Licenses",
   "compliance": "Compliance"
 }

apps/documentation/pages/users/fair-use.mdx

@@ -0,0 +1,34 @@
+---
+title: Fair Use Policy
+description: Learn about our fair use policy, which enables us to have unlimited plans.
+---
+
+import { Callout } from 'nextra/components';
+
+# Fair Use Policy
+
+### Why
+
+We offer our plans without any limits on volume because we want our users and customers to make the most of their accounts. Estimating volume is incredibly hard, especially for shorter intervals like a quarter. We are not interested in selling volume packages our customers end up not using. This is why the individual plan and the team plan do not include a limit on signing or API volume. If you are a customer of these [plans](https://documen.so/pricing), we ask you to abide by this fair use policy:
+
+### Spirit of the Plan
+
+> Use the limitless accounts as much as you like (they are meant to offer a lot) while respecting the spirit and intended scope of the account.
+
+<Callout type="info">
+  What happens if I violate this policy? We will ask you to upgrade to a fitting plan or custom
+  pricing. We won’t block your account without reaching out. [Message
+  us](mailto:support@documenso.com) for questions. It's probably fine, though.
+</Callout>
+
+### DO
+
+- Sign as many documents with the individual plan for your single business or organization you are part of
+- Use the API and Zapier to automate all your signing to sign as much as possible
+- Experiment with the plans and integrations, testing what you want to build: When in doubt, do it. Especially if you are just starting.
+
+### DON'T
+
+- Use the individual account's API to power a platform
+- Run a huge company, signing thousands of documents per day on a two-user team plan using the API
+- Let this policy make you overthink. If you are a paying customer, we want you to win, and it's probably fine

apps/documentation/pages/users/get-started/account-creation.mdx

@@ -3,7 +3,7 @@ title: Create Your Account
 description: Learn how to create an account on Documenso.
 ---
 
-import { Steps } from 'nextra/components';
+import { Callout, Steps } from 'nextra/components';
 
 # Create Your Account
 
@@ -14,6 +14,8 @@ The first step to start using Documenso is to pick a plan and create an account.
 
 Explore each plan's features and choose the one that best suits your needs. The [pricing page](https://documen.so/pricing) has more information about the plans.
 
+<Callout>All plans are subject to our [Fair Use Policy](/users/fair-use).</Callout>
+
 ### Create an account
 
 If you are unsure which plan to choose, you can start with the free plan and upgrade later.

apps/documentation/pages/users/signing-documents/fields.mdx

@@ -15,7 +15,7 @@ The signature field collects the signer's signature. It's required for each reci
 
 The field doesn't have any additional settings. You just need to place it on the document where you want the signer to sign.
 
-![The signature field in the Documenso document editor](public/document-signing/signature-field-document-editor-view.webp)
+![The signature field in the Documenso document editor](/document-signing/signature-field-document-editor-view.webp)
 
 ### Document Signing View
 
@@ -23,11 +23,11 @@ The recipient will see the signature field when they open the document to sign.
 
 The recipient must click on the signature field to open the signing view, where they can sign using their mouse, touchpad, or touchscreen.
 
-![The signature field in the Documenso document signing view](public/document-signing/signature-field-document-signing-view.webp)
+![The signature field in the Documenso document signing view](/document-signing/signature-field-document-signing-view.webp)
 
 The image below shows the signature field signed by the recipient.
 
-![The signature field signed by the user in the Documenso document signing view](public/document-signing/signed-signature-field.webp)
+![The signature field signed by the user in the Documenso document signing view](/document-signing/signed-signature-field.webp)
 
 After signing, the recipient can click the "Complete" button to complete the signing process.
 
@@ -39,7 +39,7 @@ The email field is used to collect the signer's email address.
 
 The field doesn't have any additional settings. You just need to place it on the document where you want the signer to sign.
 
-![The email field in the Documenso document editor](public/document-signing/email-field-document-editor-view.webp)
+![The email field in the Documenso document editor](/document-signing/email-field-document-editor-view.webp)
 
 ### Document Signing View
 
@@ -47,11 +47,11 @@ When the recipient opens the document to sign, they will see the email field.
 
 The recipient must click on the email field to automatically sign the field with the email associated with their account.
 
-![The email field in the Documenso document signing view](public/document-signing/email-field-document-signing-view.webp)
+![The email field in the Documenso document signing view](/document-signing/email-field-document-signing-view.webp)
 
 The image below shows the email field signed by the recipient.
 
-![The email field signed by the user in the Documenso document signing view](public/document-signing/signed-email-field.webp)
+![The email field signed by the user in the Documenso document signing view](/document-signing/signed-email-field.webp)
 
 After entering their email address, the recipient can click the "Complete" button to complete the signing process.
 
@@ -63,7 +63,7 @@ The name field is used to collect the signer's name.
 
 The field doesn't have any additional settings. You just need to place it on the document where you want the signer to sign.
 
-![The name field in the Documenso document editor](public/document-signing/name-field-document-editor-view.webp)
+![The name field in the Documenso document editor](/document-signing/name-field-document-editor-view.webp)
 
 ### Document Signing View
 
@@ -71,11 +71,11 @@ When the recipient opens the document to sign, they will see the name field.
 
 The recipient must click on the name field, which will automatically sign the field with the name associated with their account.
 
-![The name field in the Documenso document signing view](public/document-signing/name-field-document-signing-view.webp)
+![The name field in the Documenso document signing view](/document-signing/name-field-document-signing-view.webp)
 
 The image below shows the name field signed by the recipient.
 
-![The name field signed by the user in the Documenso document signing view](public/document-signing/name-field-signed.webp)
+![The name field signed by the user in the Documenso document signing view](/document-signing/name-field-signed.webp)
 
 After entering their name, the recipient can click the "Complete" button to complete the signing process.
 
@@ -87,7 +87,7 @@ The date field is used to collect the date of the signature.
 
 The field doesn't have any additional settings. You just need to place it on the document where you want the signer to sign.
 
-![The date field in the Documenso document editor](public/document-signing/date-field-document-editor-view.webp)
+![The date field in the Documenso document editor](/document-signing/date-field-document-editor-view.webp)
 
 ### Document Signing View
 
@@ -95,11 +95,11 @@ When the recipient opens the document to sign, they will see the date field.
 
 The recipient must click on the date field to automatically sign the field with the current date and time.
 
-![The date field in the Documenso document signing view](public/document-signing/date-field-document-signing-view.webp)
+![The date field in the Documenso document signing view](/document-signing/date-field-document-signing-view.webp)
 
 The image below shows the date field signed by the recipient.
 
-![The date field signed by the user in the Documenso document signing view](public/document-signing/date-field-signed.webp)
+![The date field signed by the user in the Documenso document signing view](/document-signing/date-field-signed.webp)
 
 After entering the date, the recipient can click the "Complete" button to complete the signing process.
 
@@ -111,11 +111,11 @@ The text field is used to collect text input from the signer.
 
 Place the text field on the document where you want the signer to enter text. The text field comes with additional settings that can be configured.
 
-![The text field in the Documenso document editor](public/document-signing/text-field-document-editor-view.webp)
+![The text field in the Documenso document editor](/document-signing/text-field-document-editor-view.webp)
 
 To open the settings, click on the text field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.
 
-![The text field settings in the Documenso document editor](public/document-signing/text-field-advanced-settings-document-editor-view.webp)
+![The text field settings in the Documenso document editor](/document-signing/text-field-advanced-settings-document-editor-view.webp)
 
 The text field settings include:
 
@@ -137,7 +137,7 @@ It also comes with a couple of rules:
 
 Let's look at the following example.
 
-![A text field with the settings configured by the user in the Documenso document editor](public/document-signing/text-field-with-filled-advanced-settings.webp)
+![A text field with the settings configured by the user in the Documenso document editor](/document-signing/text-field-with-filled-advanced-settings.webp)
 
 The field is configured as follows:
 
@@ -156,23 +156,23 @@ What the recipient sees when they open the document to sign depends on the setti
 
 In this case, the recipient sees the text field signed with the default value.
 
-![Text field with the default value signed by the user in the Documenso document signing view](public/document-signing/text-field-autosigned.webp)
+![Text field with the default value signed by the user in the Documenso document signing view](/document-signing/text-field-autosigned.webp)
 
 The recipient can modify the text field value since the field is not read-only. To change the value, the recipient must click the field to un-sign it.
 
 Once it's unsigned, the field uses the label set by the sender.
 
-![Unsigned text field in the Documenso document signing view](public/document-signing/text-field-unsigned.webp)
+![Unsigned text field in the Documenso document signing view](/document-signing/text-field-unsigned.webp)
 
 To sign the field with a different value, the recipient needs to click on the field and enter the new value.
 
-![Text field with the text input in the Documenso document signing view](public/document-signing/text-field-input-modal.webp)
+![Text field with the text input in the Documenso document signing view](/document-signing/text-field-input-modal.webp)
 
 Since the text field has a character limit, the recipient must enter a value that doesn't exceed the limit. Otherwise, an error message will appear, and the field will not be signed.
 
 The image below illustrates the text field signed with a new value.
 
-![Text field signed with a new value](public/document-signing/text-field-new-value-signed.webp)
+![Text field signed with a new value](/document-signing/text-field-new-value-signed.webp)
 
 After signing the field, the recipient can click the "Complete" button to complete the signing process.
 
@@ -184,11 +184,11 @@ The number field is used for collecting a number input from the signer.
 
 Place the number field on the document where you want the signer to enter a number. The number field comes with additional settings that can be configured.
 
-![The number field in the Documenso document editor](public/document-signing/number-field-document-editor.webp)
+![The number field in the Documenso document editor](/document-signing/number-field-document-editor.webp)
 
 To open the settings, click on the number field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.
 
-![The number field in the Documenso document editor](public/document-signing/number-field-document-editor-view.webp)
+![The number field in the Documenso document editor](/document-signing/number-field-document-editor-view.webp)
 
 The number field settings include:
 
@@ -221,7 +221,7 @@ In this example, the number field is configured as follows:
 - Validation:
 - Min value: 5, Max value: 50
 
-![A number field with the label configured by the user in the Documenso document editor](public/document-signing/number-field-label.webp)
+![A number field with the label configured by the user in the Documenso document editor](/document-signing/number-field-label.webp)
 
 Since the field has a label set, the label is displayed instead of the default number field value - "Add number".
 
@@ -231,23 +231,23 @@ What the recipient sees when they open the document to sign depends on the setti
 
 The recipient sees the number field signed with the default value in this case.
 
-![Number field with the default value signed by the user in the Documenso document signing view](public/document-signing/number-field-autosigned.webp)
+![Number field with the default value signed by the user in the Documenso document signing view](/document-signing/number-field-autosigned.webp)
 
 Since the number field is not read-only, the recipient can modify its value. To change the value, the recipient must click the field to un-sign it.
 
 Once it's unsigned, the field uses the label set by the sender.
 
-![Unsigned number field in the Documenso document signing view](public/document-signing/number-field-unsigned.webp)
+![Unsigned number field in the Documenso document signing view](/document-signing/number-field-unsigned.webp)
 
 To sign the field with a different value, the recipient needs to click on the field and enter the new value.
 
-![Number field with the number input in the Documenso document signing view](public/document-signing/number-field-input-modal.webp)
+![Number field with the number input in the Documenso document signing view](/document-signing/number-field-input-modal.webp)
 
 Since the number field has a validation rule set, the recipient must enter a value that meets the rules. In this example, the value needs to be between 5 and 50. Otherwise, an error message will appear, and the field will not be signed.
 
 The image below illustrates the text field signed with a new value.
 
-![Number field signed with a new value](public/document-signing/number-field-signed-with-another-value.webp)
+![Number field signed with a new value](/document-signing/number-field-signed-with-another-value.webp)
 
 After signing the field, the recipient can click the "Complete" button to complete the signing process.
 
@@ -259,11 +259,11 @@ The radio field is used to collect a single choice from the signer.
 
 Place the radio field on the document where you want the signer to select a choice. The radio field comes with additional settings that can be configured.
 
-![The radio field in the Documenso document editor](public/document-signing/radio-field-document-editor-view.webp)
+![The radio field in the Documenso document editor](/document-signing/radio-field-document-editor-view.webp)
 
 To open the settings, click on the radio field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.
 
-![The radio field advanced settings in the Documenso document editor](public/document-signing/radio-field-advanced-settings-document-editor-view.webp)
+![The radio field advanced settings in the Documenso document editor](/document-signing/radio-field-advanced-settings-document-editor-view.webp)
 
 The radio field settings include:
 
@@ -293,7 +293,7 @@ In this example, the radio field is configured as follows:
   - Empty value
   - Option 3
 
-![The radio field with the settings configured by the user in the Documenso document editor](public/document-signing/radio-field-options-document-editor-view.webp)
+![The radio field with the settings configured by the user in the Documenso document editor](/document-signing/radio-field-options-document-editor-view.webp)
 
 Since the field contains radio options, it displays them instead of the default radio field value, "Radio".
 
@@ -303,11 +303,11 @@ What the recipient sees when they open the document to sign depends on the setti
 
 In this case, the recipient sees the radio field unsigned because the sender didn't select a value.
 
-![Radio field with no value selected in the Documenso document signing view](public/document-signing/radio-field-unsigned.webp)
+![Radio field with no value selected in the Documenso document signing view](/document-signing/radio-field-unsigned.webp)
 
 The recipient can select one of the options by clicking on the radio button next to the option.
 
-![Radio field with the value selected by the user in the Documenso document signing view](public/document-signing/radio-field-signed.webp)
+![Radio field with the value selected by the user in the Documenso document signing view](/document-signing/radio-field-signed.webp)
 
 After signing the field, the recipient can click the "Complete" button to complete the signing process.
 
@@ -319,11 +319,11 @@ The checkbox field is used to collect multiple choices from the signer.
 
 Place the checkbox field on the document where you want the signer to select choices. The checkbox field comes with additional settings that can be configured.
 
-![The checkbox field in the Documenso document editor](public/document-signing/checkbox-document-editor-view.webp)
+![The checkbox field in the Documenso document editor](/document-signing/checkbox-document-editor-view.webp)
 
 To open the settings, click on the checkbox field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.
 
-![The checkbox field settings in the Documenso document editor](public/document-signing/checkbox-advanced-settings.webp)
+![The checkbox field settings in the Documenso document editor](/document-signing/checkbox-advanced-settings.webp)
 
 The checkbox field settings include the following:
 
@@ -356,7 +356,7 @@ In this example, the checkbox field is configured as follows:
   - Option 3 (checked)
   - Empty value
 
-![The checkbox field with the settings configured by the user in the Documenso document editor](public/document-signing/checkbox-advanced-settings-document-editor-view.webp)
+![The checkbox field with the settings configured by the user in the Documenso document editor](/document-signing/checkbox-advanced-settings-document-editor-view.webp)
 
 Since the field contains checkbox options, it displays them instead of the default checkbox field value, "Checkbox".
 
@@ -366,7 +366,7 @@ What the recipient sees when they open the document to sign depends on the setti
 
 In this case, the recipient sees the checkbox field signed with the values selected by the sender.
 
-![Checkbox field with the values selected by the user in the Documenso document signing view](public/document-signing/checkbox-field-document-signing-view.webp)
+![Checkbox field with the values selected by the user in the Documenso document signing view](/document-signing/checkbox-field-document-signing-view.webp)
 
 Since the field is required, the recipient can either sign with the values selected by the sender or modify the values.
 
@@ -377,11 +377,11 @@ The values can be modified in 2 ways:
 
 The image below illustrates the checkbox field with the values cleared by the recipient. Since the field is required, it has a red border instead of the yellow one (non-required fields).
 
-![Checkbox field the values cleared by the user in the Documenso document signing view](public/document-signing/checkbox-field-unsigned.webp)
+![Checkbox field the values cleared by the user in the Documenso document signing view](/document-signing/checkbox-field-unsigned.webp)
 
 Then, the recipient can select values other than the ones chosen by the sender.
 
-![Checkbox field with the values selected by the user in the Documenso document signing view](public/document-signing/checkbox-field-custom-sign.webp)
+![Checkbox field with the values selected by the user in the Documenso document signing view](/document-signing/checkbox-field-custom-sign.webp)
 
 After signing the field, the recipient can click the "Complete" button to complete the signing process.
 
@@ -393,11 +393,11 @@ The dropdown/select field collects a single choice from a list of options.
 
 Place the dropdown/select field on the document where you want the signer to select a choice. The dropdown/select field comes with additional settings that can be configured.
 
-![The dropdown/select field in the Documenso document editor](public/document-signing/select-field-sliders.webp)
+![The dropdown/select field in the Documenso document editor](/document-signing/select-field-sliders.webp)
 
 To open the settings, click on the dropdown/select field and then on the "Sliders" icon. That opens the settings panel on the right side of the screen.
 
-![The dropdown/select field settings in the Documenso document editor](public/document-signing/select-field-advanced-settings-panel.webp)
+![The dropdown/select field settings in the Documenso document editor](/document-signing/select-field-advanced-settings-panel.webp)
 
 The dropdown/select field settings include:
 
@@ -433,14 +433,14 @@ What the recipient sees when they open the document to sign depends on the setti
 
 In this case, the recipient sees the dropdown/select field with the default label, "-- Select ---" since the sender has not set a default value.
 
-![Dropdown/select field  in the Documenso document signing view](public/document-signing/select-field-unsigned.webp)
+![Dropdown/select field  in the Documenso document signing view](/document-signing/select-field-unsigned.webp)
 
 The recipient can modify the dropdown/select field value since the field is not read-only. To change the value, the recipient must click on the field for the dropdown list to appear.
 
-![Dropdown/select field with the dropdown list in the Documenso document signing view](public/document-signing/select-field-unsigned-dropdown.webp)
+![Dropdown/select field with the dropdown list in the Documenso document signing view](/document-signing/select-field-unsigned-dropdown.webp)
 
 The recipient can select one of the options from the list. The image below illustrates the dropdown/select field signed with a new value.
 
-![Dropdown/select field signed with a value](public/document-signing/select-field-signed.webp)
+![Dropdown/select field signed with a value](/document-signing/select-field-signed.webp)
 
 After signing the field, the recipient can click the "Complete" button to complete the signing process.

apps/documentation/pages/users/signing-documents/index.mdx

@@ -18,17 +18,17 @@ The guide assumes you have a Documenso account. If you don't, you can create a f
 
 Navigate to the [Documenso dashboard](https://app.documenso.com/documents) and click on the "Add a document" button. Select the document you want to upload and wait for the upload to complete.
 
-![Documenso dashboard](public/document-signing/documenso-documents-dashboard.webp)
+![Documenso dashboard](/document-signing/documenso-documents-dashboard.webp)
 
 After the upload is complete, you will be redirected to the document's page. You can configure the document's settings and add recipients and fields here.
 
-![Documenso document overview](public/document-signing/documenso-uploaded-document.webp)
+![Documenso document overview](/document-signing/documenso-uploaded-document.webp)
 
 ### (Optional) Advanced Options
 
 Click on the "Advanced options" button to access additional settings for the document. You can set an external ID, date format, time zone, and the redirect URL.
 
-![Advanced settings for a document uploaded in the Documenso dashboard](public/document-signing/documenso-uploaded-document-advanced-options.webp)
+![Advanced settings for a document uploaded in the Documenso dashboard](/document-signing/documenso-uploaded-document-advanced-options.webp)
 
 The external ID allows you to set a custom ID for the document that can be used to identify the document in your external system(s).
 
@@ -45,7 +45,7 @@ The available options are:
 - **Require account** - The recipient must be signed in to view the document.
 - **None** - The document can be accessed directly by the URL sent to the recipient.
 
-![Document access settings in the Documenso dashboard](public/document-signing/documenso-enterprise-document-access.webp)
+![Document access settings in the Documenso dashboard](/document-signing/documenso-enterprise-document-access.webp)
 
 <Callout type="info">
   The "Document Access" feature is only available for Enterprise accounts.
@@ -61,7 +61,7 @@ The available options are:
 - **Require 2FA** - The recipient must have an account and 2FA enabled via their settings.
 - **None** - No authentication required.
 
-![Document recipient action authentication in the Documenso dashboard](public/document-signing/document-enterprise-recipient-action-authentication.webp)
+![Document recipient action authentication in the Documenso dashboard](/document-signing/document-enterprise-recipient-action-authentication.webp)
 
 This can be overridden by setting the authentication requirements directly for each recipient in the next step.
 
@@ -75,11 +75,11 @@ Click the "+ Add Signer" button to add a new recipient. You can configure the re
 
 You can choose any option from the ["Recipient Authentication"](#optional-recipient-authentication) section, or you can set it to "Inherit authentication method" to use the global action signing authentication method configured in the "General Settings" step.
 
-![The required authentication method for a recipient](public/document-signing/documenso-document-recipient-authentication-method.webp)
+![The required authentication method for a recipient](/document-signing/documenso-document-recipient-authentication-method.webp)
 
 You can also set the recipient's role, which determines their actions and permissions in the document.
 
-![The recipient role](public/document-signing/documenso-document-recipient-role.webp)
+![The recipient role](/document-signing/documenso-document-recipient-role.webp)
 
 #### Roles
 
@@ -96,7 +96,7 @@ Documenso has 4 roles for recipients with different permissions and actions.
 
 Documenso supports 9 different field types that can be added to the document. Each field type collects various information from the recipients when they sign the document.
 
-![The available field types in the Documenso dashboard](public/document-signing/documenso-document-fields.webp)
+![The available field types in the Documenso dashboard](/document-signing/documenso-document-fields.webp)
 
 The available field types are:
 
@@ -121,13 +121,13 @@ All fields can be placed anywhere on the document and resized as needed.
 
 Signer Roles require at least 1 signature field. You will get an error message if you try to send a document without a signature field.
 
-![Error message when trying to send a document without a signature field](public/document-signing/documenso-no-signature-field-found.webp)
+![Error message when trying to send a document without a signature field](/document-signing/documenso-no-signature-field-found.webp)
 
 ### Email Settings
 
 Before sending the document, you can configure the email settings and customize the subject line, message, and sender name.
 
-![Email settings in the Documenso dashboard](public/document-signing/documenso-document-email-settings.webp)
+![Email settings in the Documenso dashboard](/document-signing/documenso-document-email-settings.webp)
 
 If you leave the email subject and message empty, Documenso will use the default email template.
 
@@ -135,13 +135,13 @@ If you leave the email subject and message empty, Documenso will use the default
 
 After configuring the document, click the "Send" button to send the document to the recipients. The recipients will receive an email with a link to sign the document.
 
-![The email sent to the recipients with the signing link](public/document-signing/documenso-sign-email.webp)
+![The email sent to the recipients with the signing link](/document-signing/documenso-sign-email.webp)
 
 #### Signing Link
 
 If you need to copy the signing link for each recipient, you can do so by clicking on the recipient whose link you want to copy. The signing link is copied automatically to your clipboard.
 
-![How to copy the signing link for each recipient from the Documenso dashboard](public/document-signing/documenso-signing-links.webp)
+![How to copy the signing link for each recipient from the Documenso dashboard](/document-signing/documenso-signing-links.webp)
 
 The signing link has the following format:
 

apps/documentation/pages/users/support.mdx

@@ -0,0 +1,38 @@
+---
+title: Support
+description: Learn what types of support we offer.
+---
+
+# Support
+
+## Community Support
+
+If you are a developer or free user, you can reach out to the community or raise an issue:
+
+### [Create Github Issues](https://github.com/documenso/documenso/issues)
+
+The community and the core team address GitHub issues. Be sure to check if a similar issue already exists. Please note that while we want to address everything immediately, we must prioritize.
+
+### [Join our Discord](https://documen.so/discord)
+
+You can ask for help in the [community help channel](https://discord.com/channels/1132216843537485854/1133419426524430376).
+
+## Paid Account Support
+
+### Email: support@documenso.com
+
+If you are paying customers facing issues, email our customer support, especially in urgent cases.
+
+### Private Discord channel
+
+If you prefer Discord, we can invite you to a private channel. Message support to make this happen.
+
+## Enterprise Support
+
+### Email: support@documenso.com
+
+If you are paying customers facing issues, email our customer support, especially in urgent cases.
+
+### Slack
+
+If your team is on Slack, we can create a private workspace to support you more closely.

apps/documentation/pages/users/teams/_meta.json

@@ -0,0 +1,5 @@
+{
+  "general-settings": "General Settings",
+  "document-visibility": "Document Visibility",
+  "sender-details": "Email Sender Details"
+}

apps/documentation/pages/users/teams/document-visibility.mdx

@@ -0,0 +1,45 @@
+---
+title: Document Visibility
+description: Learn how to control the visibility of your team documents.
+---
+
+import { Callout } from 'nextra/components';
+
+# Team's Document Visibility
+
+The default document visibility option allows you to control who can view and access the documents uploaded to your team account. The document visibility can be set to one of the following options:
+
+- **Everyone** - The document is visible to all team members.
+- **Managers and above** - The document is visible to team members with the role of _Manager or above_ and _Admin_.
+- **Admin only** - The document is only visible to the team's admins.
+
+![A screenshot of the document visibility selector from the team's general settings page](/teams/team-general-settings-document-visibility-select.webp)
+
+The default document visibility is set to "_EVERYONE_" by default. You can change this setting by going to the [team's general settings page](/users/teams/general-settings) 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.
+
+You can change the visibility of a document at any time by editing the document and selecting a different visibility option.
+
+![A screenshot of the Documenso's document editor page where you can update the document visibility](/teams/document-visibility-settings.webp)
+
+<Callout type="warning">
+  Updating the default document visibility in the team's general settings will not affect the
+  visibility of existing documents. You will need to update the visibility of each document
+  individually.
+</Callout>
+
+## A Note on Document Access
+
+The `document owner` (the user who created the document) always has access to the document, regardless of the document's visibility settings. This means that even if a document is set to "Admins only", the document owner can still view and edit the document.
+
+The `recipient` (the user who receives the document for signature, approval, etc.) also has access to the document, regardless of the document's visibility settings. This means that even if a document is set to "Admins only", the recipient can still view and sign the document.

apps/documentation/pages/users/teams/general-settings.mdx

@@ -0,0 +1,15 @@
+---
+title: General Settings
+description: Learn how to manage your team's General settings.
+---
+
+# General Settings
+
+You can manage your team's general settings by clicking on the **General Settings** tab in the team's settings dashboard.
+
+![A screenshot of team's General settings page](/teams/team-general-settings.webp)
+
+The general settings page allows you to update the following settings:
+
+- **Document Visibility** - Set the default visibility of the documents created by team members. Learn more about [document visibility](/users/teams/document-visibility).
+- **Sender Details** - Set whether the sender's name should be included in the emails sent by the team. Learn more about [sender details](/users/teams/sender-details).

apps/documentation/pages/users/teams/sender-details.mdx

@@ -0,0 +1,14 @@
+---
+title: Email Sender Details
+description: Learn how to update the sender details for your team's email notifications.
+---
+
+## Sender Details
+
+If the **Sender Details** setting is enabled, the emails sent by the team will include the sender's name. The email will say:
+
+> "Example User" on behalf of "Example Team" has invited you to sign "document.pdf"
+
+If the **Sender Details** setting is disabled, the emails sent by the team will not include the sender's name. The email will say:
+
+> "Example Team" has invited you to sign "document.pdf"

apps/documentation/pages/users/templates.mdx

@@ -10,15 +10,15 @@ Documenso allows you to create templates, which are reusable documents. Template
 
 To create a new template, navigate to the ["Templates" page](https://app.documenso.com/templates) and click on the "New Template" button.
 
-![Documenso template page](public/templates/documenso-template-page.webp)
+![Documenso template page](/templates/documenso-template-page.webp)
 
 Clicking on the "New Template" button opens a new modal to upload the document you want to use as a template. Select the document and wait for Documenso to upload it to your account.
 
-![Upload a new template document in the Documenso dashboard](public/templates/documenso-template-page-upload-document.webp)
+![Upload a new template document in the Documenso dashboard](/templates/documenso-template-page-upload-document.webp)
 
 Once the upload is complete, Documenso opens the template configuration page.
 
-![A successfuly uploaded document in the Documenso dashboard](public/templates/documenso-template-page-uploaded-document.webp)
+![A successfuly uploaded document in the Documenso dashboard](/templates/documenso-template-page-uploaded-document.webp)
 
 You can then configure the template by adding recipients, fields, and other options.
 
@@ -28,7 +28,7 @@ When you send a document for signing, Documenso emails the recipients with a lin
 
 Documenso uses a generic subject and message but also allows you to customize them for each document and template.
 
-![Configuring the email options for the Documenso template](public/templates/documenso-template-page-uploaded-document-email-options.webp)
+![Configuring the email options for the Documenso template](/templates/documenso-template-page-uploaded-document-email-options.webp)
 
 To configure the email options, click the "Email Options" tab and fill in the subject and message fields. Every time you use this template for signing, Documenso will use the custom subject and message you provided. They can also be overridden before sending the document.
 
@@ -36,7 +36,7 @@ To configure the email options, click the "Email Options" tab and fill in the su
 
 The template also has advanced options that you can configure. These options include settings such as the external ID, date format, time zone and the redirect URL.
 
-![Configuring the advanced options for the Documenso template](public/templates/documenso-template-page-uploaded-document-advanced-options.webp)
+![Configuring the advanced options for the Documenso template](/templates/documenso-template-page-uploaded-document-advanced-options.webp)
 
 The external ID allows you to set a custom ID for the document that can be used to identify the document in your external system(s).
 
@@ -50,7 +50,7 @@ You can add placeholders for the template recipients. Placeholders specify where
 
 You can also add recipients directly to the template. Recipients are the people who will receive the document for signing.
 
-![Adding placeholder recipients for the Documenso template](public/templates/documenso-template-recipients.webp)
+![Adding placeholder recipients for the Documenso template](/templates/documenso-template-recipients.webp)
 
 If you add placeholders to the template, you must replace them with actual recipients when creating a document from it. See the modal from the ["Use a Template"](#use-a-template) section.
 
@@ -70,7 +70,7 @@ Documenso provides the following field types:
 - **Checkbox** - Collects multiple choices from the signer
 - **Dropdown/Select** - Collects a single choice from a list of choices
 
-![Adding fields for the Documenso template](public/templates/documenso-template-page-fields.webp)
+![Adding fields for the Documenso template](/templates/documenso-template-page-fields.webp)
 
 After adding the fields, press the "Save Template" button to save the template.
 
@@ -85,7 +85,7 @@ Click on the "Use Template" button to create a new document from the template. B
 
 After filling in the recipients, click the "Create Document" button to create the document in your account.
 
-![Use an available Documenso template](public/templates/documenso-use-template.webp)
+![Use an available Documenso template](/templates/documenso-use-template.webp)
 
 You can also send the document straight to the recipients for signing by checking the "Send document" checkbox.
 

apps/marketing/content/blog/announcing-vial-21-cfr-part-11.mdx

@@ -11,14 +11,7 @@ tags:
   - Compliance
 ---
 
-<video
-  id="vid"
-  width="100%"
-  src="/blog/vial.webm"
-  autoPlay
-  loop
-  muted
-></video>
+<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>
@@ -26,42 +19,40 @@ tags:
 > 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.
+
+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>
+
+<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.
@@ -70,4 +61,3 @@ If you have any questions or comments, please reach out on [Twitter / X](https:/
 
 Best from Hamburg\
 Timur
-

apps/marketing/content/blog/cal.com-chooses-documenso-for-dpa-and-baa-scalability-and-compliance.mdx

@@ -0,0 +1,82 @@
+---
+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

apps/marketing/content/blog/customer-story-prisma-4-reasons-prisma-choose-documenso-for-signing.mdx

@@ -0,0 +1,85 @@
+---
+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

apps/marketing/content/blog/go-fork-yourself.mdx

@@ -0,0 +1,86 @@
+---
+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

apps/marketing/content/blog/introducing-advanced-signing-fields.mdx

@@ -0,0 +1,599 @@
+---
+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.
+
+![Old text signing field in the Documenso document editor](/blog/advanced-fields/old-text-field.jpeg)
+
+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
+
+![The advanced settings tab for the text field in the Documenso document editor](/blog/advanced-fields/text-field-advanced-settings.webp)
+
+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 text signing field on the Documenso signing page](/blog/advanced-fields/text-field-signing.webp)
+
+The first text field has no default value ("Add text") or configuration. You can sign the field by entering any text.
+
+![The first text field input](/blog/advanced-fields/first-text-field-input.webp)
+
+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 second text field input](/blog/advanced-fields/second-text-field-input.webp)
+
+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 third text field input](/blog/advanced-fields/third-text-field-input.webp)
+
+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.
+
+![A screenshot illustrating the various text fields unsigned](/blog/advanced-fields/unsigned-text-fields.webp)
+
+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 advanced settings tab for the number field on the Documenso document editor page](/blog/advanced-fields/number-field-advanced-settings.webp)
+
+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 advanced settings tab for the radio field in the Documenso document editor](/blog/advanced-fields/radio-field-advanced-settings.webp)
+
+The image below shows what the signer sees after the document is sent for signing.
+
+![The radio signing field on the Documenso signing page](/blog/advanced-fields/radio-field-sign-page.webp)
+
+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
+
+![The advanced settings tab for the select field in the Documenso document editor](/blog/advanced-fields/select-field-advanced-settings.webp)
+
+On the signing page, the "Dropdown/Select" field appears as shown below:
+
+![The select field on the Documenso document signing page](/blog/advanced-fields/select-field-sign-page.webp)
+
+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)_
+
+![The advanced settings tab for the checkbox field in the Documenso document editor](/blog/advanced-fields/checkbox-field-advanced-settings.webp)
+
+When a signer receives the document, they will see the "Checkbox" field as shown below:
+
+![The checkbox field on the Documenso document signing page](/blog/advanced-fields/checkbox-sign-page.webp)
+
+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.
+
+![Documenso advanced field signing](/blog/advanced-fields/documenso-advanced-fields-signing.webp)
+
+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.
+
+![Documenso field advanced settings](/blog/advanced-fields/documenso-field-advanced-settings.webp)
+
+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 radio and checkbox signing fields on the Documenso document signing page](/blog/advanced-fields/radio-and-checkbox-fields.webp)
+
+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.
+
+![Screenshot illustrating the active state for a field on the Documenso document editor page](/blog/advanced-fields/field-active-state.webp)
+
+The second image shows the "Signature" field in the normal state.
+
+![Screenshot illustrating the fields for a signer on the Documenso document editor page](/blog/advanced-fields/recipient-colours.webp)
+
+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.
+
+![Screenshot illustrating the recipient colour on the Documenso document editor page](/blog/advanced-fields/recipient-colour-example.webp)
+
+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.

apps/marketing/content/blog/introducing-embedding.mdx

@@ -0,0 +1,72 @@
+---
+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.

apps/marketing/content/blog/project-babel.mdx

@@ -0,0 +1,64 @@
+---
+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

apps/marketing/content/changelog.mdx

@@ -8,7 +8,236 @@ Check out what's new in the latest version and read our thoughts on it. For more
 
 ---
 
-## v1.5.6 (latest)
+# 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>
 

apps/marketing/lingui.config.ts

@@ -0,0 +1,22 @@
+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;

apps/marketing/next.config.js

@@ -30,6 +30,7 @@ const config = {
     serverActions: {
       bodySizeLimit: '50mb',
     },
+    swcPlugins: [['@lingui/swc-plugin', {}]],
   },
   reactStrictMode: true,
   transpilePackages: [
@@ -55,6 +56,13 @@ const config = {
       config.resolve.alias.canvas = false;
     }
 
+    config.module.rules.push({
+      test: /\.po$/,
+      use: {
+        loader: '@lingui/loader',
+      },
+    });
+
     return config;
   },
   async headers() {

apps/marketing/package.json

@@ -1,16 +1,17 @@
 {
   "name": "@documenso/marketing",
-  "version": "1.6.0",
+  "version": "1.8.0-rc.4",
   "private": true,
   "license": "AGPL-3.0",
   "scripts": {
     "dev": "next dev -p 3001",
-    "build": "next build",
+    "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"
+    "copy:pdfjs": "node ../../scripts/copy-pdfjs.cjs",
+    "translate:compile": "lingui compile --typescript"
   },
   "dependencies": {
     "@documenso/assets": "*",
@@ -19,7 +20,10 @@
     "@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",
@@ -28,16 +32,16 @@
     "lucide-react": "^0.279.0",
     "luxon": "^3.4.0",
     "micro": "^10.0.1",
-    "next": "14.0.3",
+    "next": "14.2.6",
     "next-auth": "4.24.5",
-    "next-axiom": "^1.1.1",
+    "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.2.0",
+    "react": "^18",
     "react-confetti": "^6.1.0",
-    "react-dom": "18.2.0",
+    "react-dom": "^18",
     "react-hook-form": "^7.43.9",
     "react-icons": "^4.11.0",
     "recharts": "^2.7.2",
@@ -46,16 +50,10 @@
     "zod": "^3.22.4"
   },
   "devDependencies": {
+    "@lingui/loader": "^4.11.3",
+    "@lingui/swc-plugin": "4.0.8",
     "@types/node": "20.1.0",
-    "@types/react": "18.2.18",
-    "@types/react-dom": "18.2.7"
-  },
-  "overrides": {
-    "next-auth": {
-      "next": "$next"
-    },
-    "next-contentlayer": {
-      "next": "$next"
-    }
+    "@types/react": "^18",
+    "@types/react-dom": "^18"
   }
 }

apps/marketing/process-env.d.ts

@@ -2,7 +2,8 @@ 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;

apps/marketing/src/app/(marketing)/[content]/content.tsx

@@ -0,0 +1,23 @@
+'use client';
+
+import Image from 'next/image';
+
+import type { DocumentTypes } from 'contentlayer/generated';
+import type { MDXComponents } from 'mdx/types';
+import { useMDXComponent } from 'next-contentlayer/hooks';
+
+const mdxComponents: MDXComponents = {
+  MdxNextImage: (props: { width: number; height: number; alt?: string; src: string }) => (
+    <Image {...props} alt={props.alt ?? ''} />
+  ),
+};
+
+export type ContentPageContentProps = {
+  document: DocumentTypes;
+};
+
+export const ContentPageContent = ({ document }: ContentPageContentProps) => {
+  const MDXContent = useMDXComponent(document.body.code);
+
+  return <MDXContent components={mdxComponents} />;
+};

apps/marketing/src/app/(marketing)/[content]/page.tsx

@@ -1,9 +1,10 @@
-import Image from 'next/image';
 import { notFound } from 'next/navigation';
 
 import { allDocuments } from 'contentlayer/generated';
-import type { MDXComponents } from 'mdx/types';
-import { useMDXComponent } from 'next-contentlayer/hooks';
+
+import { setupI18nSSR } from '@documenso/lib/client-only/providers/i18n.server';
+
+import { ContentPageContent } from './content';
 
 export const dynamic = 'force-dynamic';
 
@@ -17,29 +18,23 @@ export const generateMetadata = ({ params }: { params: { content: string } }) =>
   return { title: document.title };
 };
 
-const mdxComponents: MDXComponents = {
-  MdxNextImage: (props: { width: number; height: number; alt?: string; src: string }) => (
-    <Image {...props} alt={props.alt ?? ''} />
-  ),
-};
-
 /**
  * A generic catch all page for the root level that checks for content layer documents.
  *
  * Will render the document if it exists, otherwise will return a 404.
  */
-export default function ContentPage({ params }: { params: { content: string } }) {
+export default async function ContentPage({ params }: { params: { content: string } }) {
+  await setupI18nSSR();
+
   const post = allDocuments.find((post) => post._raw.flattenedPath === params.content);
 
   if (!post) {
     notFound();
   }
 
-  const MDXContent = useMDXComponent(post.body.code);
-
   return (
     <article className="prose dark:prose-invert mx-auto">
-      <MDXContent components={mdxComponents} />
+      <ContentPageContent document={post} />
     </article>
   );
 }

apps/marketing/src/app/(marketing)/blog/[post]/content.tsx

@@ -0,0 +1,23 @@
+'use client';
+
+import Image from 'next/image';
+
+import type { BlogPost } from 'contentlayer/generated';
+import type { MDXComponents } from 'mdx/types';
+import { useMDXComponent } from 'next-contentlayer/hooks';
+
+const mdxComponents: MDXComponents = {
+  MdxNextImage: (props: { width: number; height: number; alt?: string; src: string }) => (
+    <Image {...props} alt={props.alt ?? ''} />
+  ),
+};
+
+export type BlogPostContentProps = {
+  post: BlogPost;
+};
+
+export const BlogPostContent = ({ post }: BlogPostContentProps) => {
+  const MdxContent = useMDXComponent(post.body.code);
+
+  return <MdxContent components={mdxComponents} />;
+};