Payload's new and robust Plugins infrastructure makes reusing and modularizing your Payload code super easy.

Because Payload is built as a code-first, config-based headless CMS, using third-party plugins and even writing your own is extremely straightforward. All that's necessary is a little knowledge of JavaScript, and then from there, you can extend and modify Payload in any way that you can dream up.

With Plugins, Payload can be extended and modified in a ton of ways. Over time, we're going to build up a library of commonly requested and officially supported plugins—but what's really exciting is the fact that anyone can make their own with just a little bit of JS knowledge.

const config = buildConfig({
  // .. your config here
    serverURL: 'http://localhost:3000',

  // plugins are just simple JS functions
  plugins: [
    passwordProtect(['pages']),
    syncToHubSpot(['customers']),
  ],
});

Easy to learn, easy to write

Most CMS plugin systems are upsettingly difficult to learn and require you to devote yourself to learning how to build a plugin for that CMS. You might be able to cobble something together after spending a day or so of time learning how to work in someone else's system, but you'll never get that time back. Worse yet - your learning will only ever apply to that one platform.

Payload is different. Because the core infrastructure of Payload is so open-ended, being based fully on vanilla JS / TS, the knowledge that you need to build Payload plugins is universally applicable in your career as a developer. Writing a Payload plugin is as easy as taking in a config, and then returning an enhanced config. Within, you can rely on Payload's already powerful infrastructure design like Hooks, function-based access control, custom components, open-ended Express usage, and more.

Possibilities

The possibilities run a lot wider than what you might expect at first glance. You can add and enhance just about any part of Payload. Below, we'll write out some examples.

CRM Connector (MailChimp, HubSpot, Salesforce, etc.)

Imagine if your Customers collection could be automatically synced with HubSpot, MailChimp, or similar each time a customer is created or updated.

Required plugin functions:

• Add an afterChange hook to relevant collections that takes the incoming data and sends it to your CRM

Easy. The plugin would just take in a user's config, copy it, inject some hooks containing your platform's integration logic, and return the new config.

Field encryption

If you're working with sensitive data, you might want to encrypt certain fields, so that even when their data is stored at rest in the database, it is not in plaintext. Common examples might be passwords, API keys, HIPAA data, credit card data, or other personally identifiable information. A Plugin could be easily written to automatically encrypt/decrypt data as it enters and exits your APIs. The plugin would need to:

• Add a beforeChange hook to all fields needing to be encrypted that converts the incoming value to an encrypted counterpart
• Add an afterRead hook too all encrypted fields which decrypts them automatically as they are sent out by your APIs

Form builder

A common use case for sites and apps is to expose a fully featured Form Builder to your editors. One way to do this through a Plugin would be as follows:

• Inject a new collection called Forms. The Forms collection would come with a blocks field type, where each block would represent a field type (select, text, checkbox, etc.) Editors could then build out their own custom forms and build relationship fields which would reference them.
• Inject a new collection called Form Submissions. This new collection would accept JSON submissions and automatically validate their incoming data compared to the corresponding Form.

Password-protection

What if you needed password protection over documents in certain collections? A plugin could do this easily. It would need to:

• Automatically inject some new fields into password-enabled collections
• Add a new REST endpoint as well as a new GraphQL mutation for end-users to provide a password, and have their password be validated
• Add a beforeRead hook to all appropriate collections that shows and hides the document based on if the user has access
• Conditionally show and hide existing fields in the admin panel based on if the user has access

Stay tuned for this one.

This is the first officially-supported plugin that Payload will release. You'll be able to read the source code to see how it's done.

Other possibilities

Here are some other quick example use cases:

• Add a full ecommerce backend to any Payload app
• Add custom reporting views to Payload's admin panel
• Integrate all upload-enabled collections with a third-party file host like S3 or Cloudinary
• Add custom routes or GraphQL queries / mutations with any type of custom functionality that you can think of

Documentation

Find more information, including a simple example plugin, in our Plugin documentation.

Request a Plugin

Need a plugin to be created? Start a GitHub discussion. If we don't build it, maybe someone else has - or will!

Let us know your thoughts

We've got big things planned for Payload, and we'd love to hear what you think. If you haven't yet given the CMS a shot, you can get started free with one command:

npx create-payload-app