# Documentation - [Payload Solutions documentation](/docs): Documentation for Payload Stack, Payload Clock and the Payload Solutions plugins. - **Products** - Payload Stack: SaaS boilerplate for Payload CMS - [Payload Stack](/docs/payload-stack): The SaaS boilerplate for Payload CMS. - [Getting started](/docs/payload-stack/getting-started): From an empty directory to a signed-in dashboard. - [CLI reference](/docs/payload-stack/cli): Every flag of create-payload-stack. - [Agentic development](/docs/payload-stack/agents): AGENTS.md, task skills, MCP servers and one verify command, so Claude Code, Codex and Cursor build on Payload Stack the way the template is meant to be built on. - [Configuration](/docs/payload-stack/configuration): Everything product-specific lives in src/stack.config.ts. - [Authentication](/docs/payload-stack/authentication): Better Auth for the app and the Payload admin, through payload-auth. - [Organizations](/docs/payload-stack/organizations): Better Auth organizations as Payload tenants. - [Billing](/docs/payload-stack/billing): Stripe subscriptions with @better-auth/stripe. - [Emails](/docs/payload-stack/emails): Every transactional email a SaaS owes its users — in code, or editable in the admin. - [Legal pages and consent](/docs/payload-stack/legal): A privacy policy, terms and a cookie policy that agree with what the project actually does — and a banner in front of them. - [Scheduled actions](/docs/payload-stack/scheduling): Trial reminders, dunning, sweeps and anything else that has to happen later — with a ledger you can read. - [Database](/docs/payload-stack/database): PostgreSQL, MongoDB, SQLite or Vercel Postgres. - [Media storage](/docs/payload-stack/storage): Local disk, Vercel Blob, S3, Cloudflare R2, Azure, Google Cloud Storage or Uploadthing. - [Dashboard and UI](/docs/payload-stack/dashboard): shadcn/ui, Better Auth UI, the sidebar shell and where to put your product. - [Observability](/docs/payload-stack/observability): Error monitoring through a provider-agnostic port — Sentry, a self-hosted alternative, or your own adapter. - [Testing](/docs/payload-stack/testing): Unit, integration and end-to-end suites that cover every stack.config.ts option, and how to extend them. - [Deployment](/docs/payload-stack/deployment): Environment variables, migrations and hosting. - [FAQ](/docs/payload-stack/faq): Common questions about Payload Stack. - Payload Clock: Scheduled jobs for serverless Payload - [Payload Clock](/docs/payload-clock): A reliable clock for serverless Payload job queues. In progress. - **Plugins** - [Plugins overview](/docs/plugins): Payload plugins built by Payload Solutions for the community. - Cookie Consent for Payload: Consent, cookies and legal pages in the admin - [Cookie Consent for Payload](/docs/plugins/payload-consent): Cookie categories, trackers, legal pages and consent records managed in the Payload admin. One source of truth for the banner, the script gating and the cookie policy. - [Installation](/docs/plugins/payload-consent/installation): Install the plugin, wire the frontend, add the banner, and get consent right on the first render. - [Admin guide](/docs/plugins/payload-consent/admin): What every screen and field under Privacy does, written for whoever maintains the site. - [Cookies & scripts](/docs/plugins/payload-consent/trackers): Declaring trackers so the banner, the loader and the cookie policy all agree, plus the built-in presets and Google Consent Mode. - [Processors & DPA](/docs/plugins/payload-consent/processors): The recipients you disclose under Art. 13(1)(e), the transfers under Art. 13(1)(f), and the sub-processor list and DPA your own customers need under Art. 28. - [Legal pages](/docs/plugins/payload-consent/legal-pages): Seeded privacy policy, terms and cookie policy as editable Lexical documents, with tables, a live cookie table and effective-date versioning. - [Jurisdictions & Consent Mode](/docs/plugins/payload-consent/jurisdictions): The four consent models, how a visitor's model is resolved, Global Privacy Control, and Google Consent Mode v2. - [Records & retention](/docs/plugins/payload-consent/records): What a consent record contains, what it deliberately does not, how decisions are posted, and how they are purged. - [Configuration](/docs/plugins/payload-consent/configuration): Every consentPlugin() option, with its default and what changing it costs you. - [API reference](/docs/plugins/payload-consent/api-reference): Endpoints, the ConsentConfig contract, the cookie format, and every export of the three packages. - [Legal audit](/docs/plugins/payload-consent/audit): Check your legal pages against your own configuration and the disclosures the law lists — a deterministic scan, an MCP server your own AI agent drives, and drafts that land as drafts. - [Recipes & troubleshooting](/docs/plugins/payload-consent/recipes): Common tasks, from building your own banner to gating server-side analytics, and the handful of things that usually go wrong. - Transactional Emails for Payload: Transactional email copy your team can edit - [Transactional Emails for Payload](/docs/plugins/payload-emails): Transactional emails declared once in code and written by your team in the admin. Typed at every call site, rendered through your own React Email template, sent through the adapter you already configured. - [Installation](/docs/plugins/payload-emails/installation): Install the plugin, declare your first email, regenerate types, and see it in the admin. - [Defining emails](/docs/plugins/payload-emails/defining-emails): Every field of defineEmail — the key, the input schema, the variable manifest, resolve, recipients, default copy — and the rules the plugin enforces. - [Templates](/docs/plugins/payload-emails/templates): The design is a React Email component in your repo. It owns the branding; editors own the words. - [Sending](/docs/plugins/payload-emails/sending): payload.emails.send and render, what the statuses mean, queued delivery, hooks, and wiring Payload's own auth emails. - [In the admin](/docs/plugins/payload-emails/admin): What your team sees — the email list, the editor and its variable chips, the Preview & test tab, Email Settings and the log. - [TypeScript](/docs/plugins/payload-emails/typescript): How Config['emails'] is generated, what it makes safe, and how the types behave before the first generate. - [Configuration](/docs/plugins/payload-emails/configuration): Every option of emailsPlugin(), what it defaults to, and when to change it. - [Recipes](/docs/plugins/payload-emails/recipes): Better Auth callbacks, migrating from hard-coded templates, localized copy, generated tables, renaming safely, and testing. - Resend Broadcasts: Alpha · Newsletters sent as Resend broadcasts - [Resend Broadcasts](/docs/plugins/resend-broadcasts): Newsletters for Payload CMS on Resend Broadcasts. Any collection becomes a subscriber source, lists become Resend segments, and campaigns are written, previewed as any subscriber, tested and sent from the admin. - [Installation](/docs/plugins/resend-broadcasts/installation): Install the plugin, give it a Resend key and a sender, point it at your subscriber collections, and connect the unsubscribe webhook. - [Sources](/docs/plugins/resend-broadcasts/sources): Any collection with an email can be a subscriber source. The plugin adds the fields it needs and keeps one Resend contact per address in step with your documents. - [Lists](/docs/plugins/resend-broadcasts/lists): A list is a Resend segment built from one source collection, optionally narrowed by a Payload query. Membership follows the documents. - [Campaigns](/docs/plugins/resend-broadcasts/campaigns): Write a campaign in the admin, preview it as any subscriber in the list, send yourself a test, then send it now or schedule it as a Resend broadcast. - [Templates](/docs/plugins/resend-broadcasts/templates): The design is a React Email component in your repo, with the same contract as Transactional Emails — so one branded template can serve your transactional mail and your newsletters. - [Webhooks](/docs/plugins/resend-broadcasts/webhooks): When a reader unsubscribes through Resend's link, a signed webhook switches their documents off in Payload. - [API](/docs/plugins/resend-broadcasts/api): payload.resendBroadcasts for server code, and the REST endpoints the admin uses. - [Configuration](/docs/plugins/resend-broadcasts/configuration): Every option of resendBroadcastsPlugin(), with its default. - [Recipes](/docs/plugins/resend-broadcasts/recipes): A public sign-up endpoint, an opt-in checkbox on user accounts, a nightly resync, serverless hosts, bulk imports and developing against a mock. - Vercel Integration: Deploy hooks, pending changes and deployment status in the admin - [Vercel Integration](/docs/plugins/vercel-integration): Trigger Vercel deployments from the Payload admin or automatically after content changes, see what is waiting to go live, follow every build, cancel and roll back — without giving editors a Vercel login. - [Installation](/docs/plugins/vercel-integration/installation): Install the plugin, create a deploy hook on Vercel, configure one target, boot, and verify the whole loop before you ship it. - [Configuration](/docs/plugins/vercel-integration/configuration): Every plugin option with its default — targets, tracked collections and globals, automatic deploys, ticks, access, retention, hooks, admin surfaces, slugs. - [Automatic deploys](/docs/plugins/vercel-integration/auto-deploy): The quiet period, who fires it on serverless hosts, the beacon, the scheduled task, pausing, and the 60-per-hour limit. - [Status, cancel and rollback](/docs/plugins/vercel-integration/status): How a hook call is matched to its Vercel deployment, polling and the webhook receiver, the state machine, re-instatement, cancel and instant rollback. - [Admin](/docs/plugins/vercel-integration/admin): The header widget, the Deploy drawer, the Deployments view, the document pill and the deployments collection. - [API](/docs/plugins/vercel-integration/api): The payload.vercel local API, the REST endpoints under /api/vercel, and the plugin hooks. - [Recipes](/docs/plugins/vercel-integration/recipes): A static marketing site next to Payload Stack, nightly rebuilds, notifying on failure, a preview target, skipping bulk imports, the mock server. - Action Scheduler for Payload: Scheduled and recurring actions with a bounded history and a real admin view - [Action Scheduler for Payload](/docs/plugins/payload-action-scheduler): Named, typed actions scheduled at runtime with arguments — once, as soon as possible, on an interval or on a cron — executed by Payload's job queue, recorded in a small ledger, and operated from a real admin view. - [Installation](/docs/plugins/payload-action-scheduler/installation): Install the plugin, declare an action, register it, and run the queue. - [Defining actions](/docs/plugins/payload-action-scheduler/defining-actions): The defineAction model — handler, arguments, retries, timeouts, uniqueness and outcomes. - [Scheduling](/docs/plugins/payload-action-scheduler/scheduling): The payload.scheduler API and its Action Scheduler equivalents. - [Admin](/docs/plugins/payload-action-scheduler/admin): The Scheduled Actions view — queue strip, status tabs, columns, row and bulk actions, the log drawer, and creating actions by hand. - [Runners](/docs/plugins/payload-action-scheduler/runners): What executes the actions, and what the maintenance tick does. - [TypeScript](/docs/plugins/payload-action-scheduler/typescript): How Config['scheduledActions'] is generated, what it makes safe, and how the types behave before the first generate. - [Configuration](/docs/plugins/payload-action-scheduler/configuration): Every actionScheduler option with its default. - [Recipes](/docs/plugins/payload-action-scheduler/recipes): Reminders from hooks, webhooks with backoff, nightly jobs in code, Transactional Emails, serverless runners, and testing. - **Project** - [Contributing](/docs/contributing): How to report bugs, propose changes, set up the monorepo, run the tests and get a pull request merged.