An Integration is the place where Payloads keeps everything for one external system or workflow.

It is not the individual API call. It is the working area for the Payloads that make the calls, the Credentials they use, the Transformations that prepare values, and the Jobs created when the work runs.

For example, you might create one Integration called Stripe Commerce Operations, then add separate Payloads for creating customers, fetching charges, handling payment events, and updating Salesforce records.

Create the Integration first. It gives the rest of the configuration a clear home.

If you are still getting familiar with the app, start with Introduction to Payloads.

Open the Payloads app, then select the Integrations tab.

The Integrations tab is the configuration landing page. The summary cards show how many Integrations, Payloads, Credentials, and Transformations already exist. Each Integration entry shows its related configuration and recent runtime status, so you can see what is already owned before creating anything new.

The Integrations tab shows the current Integration landscape, including configuration totals, existing Integrations, and the New Integration action.

Before selecting New Integration, decide what this Integration should cover.

A good Integration usually represents:

Avoid creating a separate Integration for every API endpoint. If several Payloads belong to the same external system or operational process, they usually belong under the same Integration.

Also avoid making one Integration so broad that nobody can tell what it owns. Customer Portal Sync is useful. APIs is not.

The New Integration modal captures the human name, generated API Name, short summary, and operating notes for the Integration.

The Name should be something an admin or support user can recognise later, without needing to know the implementation. Use names like Stripe Commerce Operations, ServiceNow Case Escalation, or Warehouse Fulfilment Updates.

The API Name is generated from the Name and cannot be edited directly in the modal. Treat it as a stable identifier once the Integration is in use, especially if Payloads, Credentials, Transformations, or automation refer to it.

Use the Subtitle for a short summary. This appears beside the Integration name on the record page.

Use the Description for useful operating context: what the Integration is for, which external API it talks to, links to API documentation, owner notes, environment details, or anything a future admin would need when maintaining it. URLs in the Description appear as links on the Integration detail page.

Payloads opens the new Integration record after it is saved.

The Integration detail page groups the related Payloads, Credentials, and Transformations, with actions for Import, Export, editing, deletion, and Jobs.

The summary cards show the Integration API Name and the number of related Payloads, Credentials, and Transformations.

From the resource panels, you can add:

Use Import and Export when you need to move an Integration configuration between orgs or keep a backup. Use Jobs when you want to review recent runtime activity for this Integration.

After creating the Integration, check that:

If Payloads shows Integration name already in use, choose a more specific Name and save again.

Create the first Payload under the Integration.

Start with one API interaction, get it working, then add the rest of the Payloads, Credentials, Transformations, and mappings that belong to the same Integration.