Skip to integration content

How to integrate Unify with Amplitude

To integrate Unify with Amplitude, configure a Unify Play Webhook action to call the documented API with POST, the required credentials, and the destination-specific JSON body. Use this connection to add a real sales handoff event to Amplitude.[1][2][3]

By UnifyDocumentation reviewed
Connection
Via API
Product analytics
Tool
Amplitude
Amplitude
Data flow
Unify → Amplitude
JSON payload

At a glance

  1. Via API: Amplitude receives the handoff
  2. POST request with an explicit JSON contract and destination authentication
  3. Test scenario: Check the receiving identity

When this workflow makes sense

Start with the decision your team needs to make, then choose the connection that supports it.

A commercial milestone can help explain a journey only when it is recorded consistently. Agree on the exact point in the Play that represents the event and who owns its definition. Inspect the raw event before building an audience or dashboard on top of it.

A good fit when

Teams that want to add a real sales handoff event to Amplitude and have an owner for the receiving process. The destination account must permit the documented request and the chosen downstream action.

Reconsider the plan when

The receiving team has not agreed how this Amplitude operation should behave when the same record arrives again. Resolve the matching rule before enabling retries.

Design the handoff

Use this framework to agree on the input, the next action, and who owns the result.

Suggested workflow design, based on the documented capabilities below.

StageDecision to make
Business decisionAdd a real sales handoff event to Amplitude
Receiving contractAgree which of the 2 example data fields the receiving process actually needs. Set missing-value and identity rules in the field mapping below.
Execution boundaryGive one owner access to inspect the Amplitude request and its resulting action.
CompletionDecide who can confirm the Amplitude outcome and recover a failed or repeated handoff. Use the completion check below as the acceptance criterion.

Explore the scenarios

Choose the situation that fits your team and work through the proposed plan.

Open a scenario to explore its plan. Checklists track your selections in this page only.

Add a real sales handoff event to Amplitude

Start with one controlled record and one intended Amplitude outcome. Keep the test destination separate from live operations.

The decision that matters

The receiving owner must distinguish accepted input from completed work. Agree on the evidence required before treating this handoff as successful.

  1. Prepare the destination using the Amplitude setup checklist
  2. Resolve the sample fields for one known record and inspect the request before sending it
  3. Trace that handoff through the receiving operation and compare the actual destination values with the source
Your validation checklist
0 of 3 checks marked by you
Check the receiving identity

Check the receiving identity: send a controlled event for a known test user and inspect its timeline. Confirm that the new event joins the intended person instead of creating an unrelated profile.

The decision that matters

Decide whether this case should be held for review, corrected, or retried. Make that decision before running Amplitude against live records.

  1. Isolate the test in a controlled destination and record the starting state
  2. Run the edge case described above and capture the actual response and destination state
  3. Recover the record once, then check that recovery did not create unintended additional work
Your validation checklist
0 of 3 checks marked by you

Illustrative workflow, not a preconfigured automation. Complete these checks in your own account.

Connect your tools to Unify

Set up your integration or walk through it with our team

Define success before launch

Inspect the data and the intended outcome separately. Connection status is only the first check.

Expected, not tested

Add a real sales handoff event to Amplitude

Use Amplitude’s debugging or event inspection tools to confirm the event, user identity, and property values.

Documentation-based reference. This workflow has not been tested end to end. Use a record or event you control before enabling live activity.

Questions answered

Common decisions when connecting Unify and Amplitude.

Where should an EU project send events?

Amplitude documents the EU HTTP V2 endpoint as https://api.eu.amplitude.com/2/httpapi. Use the endpoint matching the project’s residency.[3]

Limits & decisions

Check these boundaries before designing a live workflow around the connection.

  • A handoff event is not evidence of product activation, a booked meeting, or a purchase. Keep those definitions separate in funnels.[3]
  • API and trigger access depend on the destination account, permissions, and configuration. This request pattern is not a claim of native Unify sync.[3]

What the connection supports

Understand the connection, the data involved, and the behavior that matters for a Unify + Amplitude workflow.

Connection flowVia API
Prospect data

POST / JSON

Documented behavior at a glance
DecisionWhat to know
Unify actionOutbound HTTP request with configurable method, authentication, headers, and body[1]
Receiving operationChoose the Amplitude project and its data residency. Define a user_id consistent with the project’s existing identity strategy.[3]
Response handlingWebhook response bodies are not available as inputs to later Unify Play actions[2]

Technical setup reference

References and requirements for the Amplitude connection.

Connection requirements and setup checklist

Before connecting

  • A Unify Play with a Webhook action and a controlled record for testing
  • Access to the intended Amplitude environment and the permissions required by the cited API or trigger
  • The destination identifiers, credentials, and schema used by the request below
  • An agreed record identity, duplicate policy, and owner for failed handoffs
  1. Prepare the Amplitude destination

    Choose the Amplitude project and its data residency. Define a user_id consistent with the project’s existing identity strategy.[3]

  2. Configure the destination action

    Send the HTTP V2 envelope with api_key and events. Use an event_type that describes the actual Play action rather than a guessed customer outcome.[3]

  3. Configure the Unify request

    Use POST, the endpoint and authentication below, and JSON body format in the Webhook action. Replace setup placeholders, then inspect Expand preview with a controlled record. The receiver must respond within 8 seconds; webhook response bodies are not exposed to later Play steps.[1][2]

  4. Validate the complete handoff

    Run the success and edge-case scenarios in Explore the scenarios with a controlled record. Save the request identity and destination evidence, then apply the completion check before enabling live traffic.[3]

Request configuration

Method
POST
URL pattern
https://api2.amplitude.com/2/httpapi
Headers
Content-Type: application/json
Authentication
Include the Amplitude project API key in api_key in the JSON body. Use the EU ingestion endpoint when the project uses EU residency.

Choose JSON as the body format. Unify sets Content-Type automatically. The receiver must respond within Unify’s 8-second timeout; request responses are not passed to later Play steps.[2]

Replace URL placeholders with the actual receiver URL from your account or deployed application. These example URLs are not working endpoints.

Example handoff payload

Start with a fictional prospect. Validate the resolved values before using a real record.

Inspect the sample payload and field mapping
Example request body
{
  "api_key": "YOUR_AMPLITUDE_API_KEY",
  "events": [
    {
      "user_id": "example-person-001",
      "event_type": "Prospect handoff",
      "event_properties": {
        "company_domain": "example.com",
        "source": "Unify"
      }
    }
  ]
}

Fictional data. Replace sample values before using a real Play.

Illustrative JSON for the documented receiving operation. All prospect values are fictional. Replace credentials, identifiers, schema-specific fields, and fixed example values before a controlled test. Use the field mapping to distinguish record data from fixed settings. Select available fields in your Play and inspect Expand preview; do not replace configuration values with prospect data.[1][2][3]

Payload fieldValue to send
api_keystring / configured / Destination settingsReplace this placeholder with the actual destination identifier or credential from the receiving account. Keep credentials out of prospect fields and shared examples.

If missing: Do not send the request until this setting has been supplied and checked.

events.0.user_idstring / dynamic / Agreed person identityMap the stable identity used by this destination to the same person or company in your source. This example identifier is not a documented Unify variable.

If missing: Hold the handoff rather than creating an anonymous or incorrectly matched record.

events.0.event_typestring / static / Request configurationKeep the literal "Prospect handoff" required by this example request; change it only when deliberately changing the receiving contract.

If missing: Keep this configured value in the request; do not replace it with a blank prospect field.

events.0.event_properties.company_domainstring / dynamic / Company domainSelect the available company domain field for the controlled person or company record in Unify. Keep the receiving field a string.

If missing: Skip or hold the handoff if this value is required by the destination; omit it only when the destination contract permits omission. Do not send a guessed value.

events.0.event_properties.sourcestring / static / Request configurationKeep the literal "Unify" required by this example request; change it only when deliberately changing the receiving contract.

If missing: Keep this configured value in the request; do not replace it with a blank prospect field.

The project key is a credential, not a prospect field. Put business context in event_properties and retain the agreed user_id.

Troubleshooting

Start with the stage where the expected data or action stops appearing.

The request is rejected

Include the Amplitude project API key in api_key in the JSON body. Use the EU ingestion endpoint when the project uses EU residency. Check the receiving account, permissions, endpoint, and required fields against the cited documentation.[3]

The values or destination are wrong

Compare the resolved JSON with the field-by-field contract in Example handoff payload. Check identifiers against the selected Amplitude environment, and distinguish an absent source value from an intentional static value. Fix the mapping before repeating the write.[3]

Receipt does not match the expected result

Find the request in the receiving logs, then inspect the actual Amplitude resource or execution. If the request was accepted but no result exists, investigate the destination failure before retrying. Keep the same logical handoff identity when recovering a repeat.[3]

Sources & review

Official documentation reviewed on September 15, 2026.

Technical claims link to primary documentation from Unify and the destination tool. Scenarios, field choices, and recovery plans are editorial implementation examples. Documentation review is separate from execution testing.

Documentation reviewed; end-to-end execution not tested. No named technical reviewer has signed off on these articles yet.

Content updated: . Report a correction to Unify with the tool name, source URL, and behavior you observed.

  1. [1] Unify: Webhook action
  2. [2] Unify: Webhooks in Plays
  3. [3] Amplitude: official connection reference

Get started with Unify

Create your account or book a demo with our team