The Payloads app is organised around the way integration work usually happens in Salesforce: first you configure the integration, then you run and monitor it, and later you come back to troubleshoot, adjust, or administer it.

Most day-to-day setup starts from an Integration because that is where the related Payloads, Credentials, Endpoints, Transformations, and Jobs live together. Most support work starts from Home or Jobs, because those views show what has actually happened at runtime.

The Home tab is the best starting point when you want to understand what is happening across the org.

Home is the quickest way to answer the question "is Payloads healthy right now?"

It brings together API usage, recent Job activity, average runtime, cleanup service status, subscription state, slow Payloads, integration health, and attention items. You do not need to open each Integration one by one just to understand whether the org is quiet, busy, failing, or accumulating old Jobs.

Start here when someone asks whether anything failed recently, whether Payloads is running more slowly than usual, or whether the cleanup and batch services are in the expected state.

For more detail, see Monitor the Payloads home tab.

Use Integrations to organise the external systems, internal processes, or API workflows Payloads is responsible for.

An Integration is a container for the configuration that belongs together. A Stripe Integration, for example, might contain a checkout Payload, a payment event Payload, a fulfilment Payload, Credentials, Transformations, and Job history for that whole workflow. Keeping those records together makes the setup easier to review later, especially when more than one Payload is involved.

The Integrations tab is where most configuration work begins.

For setup steps, see Create your first Integration.

Use Payload records to configure one runnable integration step.

A Payload is where the shape of the integration work is defined. It might send an outbound API request, receive an inbound request, return Salesforce data to a caller, process inbound email, or support a credential refresh flow. The important point is that a Payload is not just a record label. It contains the request structure, response structure, mappings, runtime behaviour, and troubleshooting history for that step.

Open a Payload when you need to configure:

For setup steps, see Create your first Payload.

Use Credentials to configure authentication for outbound calls.

Credentials keep authentication separate from the Payloads that use it. That means a Payload can focus on the request it needs to send, while the Credential handles API keys, bearer tokens, username/password authentication, certificates, or custom authentication values.

For more detail, see Credentials Overview.

Use Endpoints when an Inbound Payload needs a URL that an external system can call.

Endpoint records connect the Salesforce Site, generated URL, HTTP method, and Payload. They can also define echo behaviour for setup and diagnostic requests. In practice, this is the place you check when a caller says they are reaching Salesforce but Payloads is not receiving the request you expected.

For more detail, see Configure Endpoints.

Use Transformations when a value needs to be changed before it is sent, returned, or saved.

For example, you might convert a currency code to lower case, convert an amount into minor units, format a date for an API, or derive a value from a more complex input. A good Transformation gives that rule a name so the next admin can see why the value changes.

For setup steps, see Create transformations.

Use Jobs when you need to understand what happened during a run.

Job records are the audit trail for Payload execution. They store request data, response data, Data Query output, Data Target results, error messages, firing mode, status, and runtime metrics. When something fails, the Job should usually be the first detailed record you open.

For more detail, see Understand Job records.

Use Batch Engine when Payload work is queued for asynchronous batch processing.

This is useful when Flow or another process creates work that should run later, or when a larger number of Jobs should be processed in controlled groups. Instead of making the calling process wait for every run to finish, Payloads can queue the work and process it through the Batch Engine.

For more detail, see Configure the Batch Engine.

Use Billing to review subscription status, plan usage, subscription service state, and authorised environments.

This is normally an admin-only area, but it is useful during support because subscription state can affect whether Payloads is allowed to keep creating and running configuration in the org.

For more detail, see Manage subscription and billing.

If you are building a new integration, start with Integrations.

If you are troubleshooting, start with Home, then open the relevant Job.

If you are setting up inbound API access, start with the Payload record and then review the Endpoint and Site setup.

If you are checking limits, cleanup, or subscription state, start with Home or Billing.