Use this guide when you are setting up Payloads in a Salesforce org, upgrading the package, or moving Payloads configuration between orgs.

Most teams should treat Payloads like any other integration platform inside Salesforce: install it carefully, assign access deliberately, check the subscription service, then test one known Payload before handing it to users.

For day-to-day permission details, see Set up permissions and access. For billing and subscription behaviour, see Manage subscription and billing.

Install Payloads into the Salesforce org where the integration should run.

Use the package installation link provided by Payloads. Start with an admin-controlled installation unless your rollout plan already defines broader access. After the package is installed, open the Payloads app from the App Launcher.

The first post-install check is simple: make sure an admin can open the Payloads app, see the main tabs, and open the Billing tab without an access error.

Assign the Payloads Admin permission set to the users who will build, test, and support Payloads configuration.

These users usually need access to the Payloads app, Integration records, Payload records, Credentials, Endpoints, Transformations, Jobs, and Batch Engine controls. They may also need access to the Salesforce objects they query from or write to through Payloads.

Start with the packaged permission sets, then review any extra business object access needed by your own Payloads.

Do not solve access errors by giving every user broad Salesforce permissions. Payloads configuration access and business data access are separate decisions.

Open the Billing tab after installation.

Payloads uses the subscription service to verify that the org is allowed to run Payloads. If the subscription service has not verified the org, runtime actions can be blocked.

The Billing tab shows whether the org is verified and whether action is needed.

This matters operationally: if the subscription service stops or fails for any reason, Payloads will cease to operate after 7 days. Keep the Billing tab on your post-install and post-upgrade checklist, and investigate subscription warnings before they become runtime failures.

You only need Salesforce Sites setup when an external system will call Payloads through an inbound Endpoint.

If you are only sending outbound requests from Salesforce to another system, you can skip Site setup. If you are receiving webhooks, exposing an API endpoint, or returning Salesforce data to another system, configure Sites before you give the Endpoint URL to the external system.

For the full setup process, see Set up inbound endpoints and Sites.

Upgrade Payloads in a sandbox first when the org has production integrations.

After the package upgrade, check:

For a controlled runtime test, see Run a Payload manually.

Payloads can export and import configuration using a .payloads file.

Use this when you want to move a tested Integration, Payload, Credential, or Transformation from one org to another. Common examples are sandbox to production, development org to UAT, or one demo org to another.

You can export from Integration, Payload, Credential, and Transformation record pages. An Integration export includes the selected Integration and its related configuration. A Payload or Credential export includes the selected record and the dependencies Payloads needs to rebuild that configuration in another org.

Open the record you want to move and select Export.

Payloads opens an export modal with the migration JSON. You can copy the JSON or download it as a .payloads file.

Credential secrets are redacted in the on-screen preview. The copy and download actions include the original values, so treat exported files as sensitive integration material. Store and share them through your normal secure process.

Use clear API Names before exporting. API Names are how Payloads recognises matching configuration during import.

Open the target Integration record and select Import.

Paste the migration JSON or upload the .payloads file exported from Payloads.

Existing records with matching API Names are updated. Payload child configuration is replaced by the imported configuration. That behaviour is useful when you are promoting a known version from sandbox, but it also means you should not import into a live Integration casually.

Before importing into production, check that the target org has:

After importing configuration, open the Integration and review the imported records.

Check the Payloads first, then Credentials, Endpoints, Transformations, Data Queries, Data Targets, and request or response mappings. Run one representative test before marking the migration complete.

For a complete seeded example you can compare against, see Use the Stripe demo records.