How to integrate Unify with Amazon S3
To integrate Unify with Amazon S3, send a Play webhook to an authenticated receiver that your team configures. The receiver calls Amazon S3, manages its credentials, and tracks the result. Use this connection to archive Unify handoff payloads in Amazon S3.[1][2][3]
- Connection
- Via intermediary
- Data storage
- Tool
- Amazon S3
- Custom receiver, then Amazon S3
- Data flow
- Unify → Your receiver → Amazon S3
- JSON payload
At a glance
- Via intermediary: your receiver calls Amazon S3
- POST request with an explicit JSON contract and destination authentication
- Test scenario: Separate snapshots from history
When this workflow makes sense
Start with the decision your team needs to make, then choose the connection that supports it.
An archive is useful when someone can reconcile it with the source handoff. Decide whether you need the latest state or an event history. Use a predictable key strategy and a retention policy that matches that purpose, then document how an operator finds a missing event.
A good fit when
Teams that want to archive Unify handoff payloads in Amazon S3 and have an owner for the receiving process. A developer or automation owner must maintain the receiver and its credentials.
Reconsider the plan when
There is no owner for the receiver, credential lifecycle, or recovery process. Assign that responsibility before using Amazon S3 for a live handoff.
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.
| Stage | Decision to make |
|---|---|
| Business decision | Archive Unify handoff payloads in Amazon S3 |
| Receiving contract | Agree which of the 5 example data fields the receiving process actually needs. Set missing-value and identity rules in the field mapping below. |
| Execution boundary | Assign an owner for the HTTPS receiver, credentials, and Amazon S3 operation. |
| Completion | Decide who can confirm the Amazon S3 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.
Archive Unify handoff payloads in Amazon S3
Start with one controlled record and one intended Amazon S3 outcome. Keep the test destination separate from live operations.
The receiving owner must distinguish accepted input from completed work. Agree on the evidence required before treating this handoff as successful.
- Prepare the destination using the Amazon S3 setup checklist
- Resolve the sample fields for one known record and inspect the request before sending it
- Trace that handoff through the receiving operation and compare the actual destination values with the source
Separate snapshots from history
Separate snapshots from history: write two versions of a controlled handoff under the chosen key strategy. Inspect which objects remain and confirm that the result matches the intended audit model.
Decide whether this case should be held for review, corrected, or retried. Make that decision before running Amazon S3 against live records.
- Isolate the test in a controlled destination and record the starting state
- Run the edge case described above and capture the actual response and destination state
- Recover the record once, then check that recovery did not create unintended additional work
Illustrative workflow, not a preconfigured automation. Complete these checks in your own account.
Define success before launch
Inspect the data and the intended outcome separately. Connection status is only the first check.
Expected, not tested
Archive Unify handoff payloads in Amazon S3
Retrieve the object from the selected bucket and compare its JSON with the accepted input. Verify the chosen repeat and overwrite behavior.
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 Amazon S3.
Can Unify write directly to an S3 bucket with a normal Bearer key?
The proposed implementation uses a receiver with AWS credentials and the SDK. An S3 bucket URL is not a generic webhook endpoint.[3]
Limits & decisions
Check these boundaries before designing a live workflow around the connection.
What the connection supports
Understand the connection, the data involved, and the behavior that matters for a Unify + Amazon S3 workflow.
Authenticated intake and destination API
| Decision | What to know |
|---|---|
| Unify action | Outbound HTTP request with configurable method, authentication, headers, and body[1] |
| Receiving operation | Deploy an authenticated receiver with an IAM role permitted to PutObject in one intended bucket or prefix. Do not place AWS credentials in the incoming JSON.[3] |
| Response handling | Webhook response bodies are not available as inputs to later Unify Play actions[2] |
Technical setup reference
References and requirements for the Amazon S3 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 Amazon S3 environment and the permissions required by the cited API or trigger
- An HTTPS receiver your team implements or configures, with an owner and a place to inspect accepted work
- An agreed record identity, duplicate policy, and owner for failed handoffs
Prepare the Amazon S3 destination
Deploy an authenticated receiver with an IAM role permitted to PutObject in one intended bucket or prefix. Do not place AWS credentials in the incoming JSON.[3]
Implement the receiving operation
Validate the payload, choose an object key from a trusted handoff identity, and use the AWS SDK to PutObject. Decide whether repeated events overwrite a snapshot or create separate history.[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]
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://YOUR_RECEIVER_HOST/webhooks/unify/amazon-s3- Headers
Content-Type: application/jsonAuthorization: Bearer YOUR_RECEIVER_SECRET- Authentication
- Protect your own HTTPS receiver with a Bearer secret checked by your application. Keep the destination credentials in the receiver, not in this example payload.
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
{
"event": "prospect_handoff",
"handoff_id": "example-handoff-001",
"prospect_name": "Alex Morgan",
"prospect_email": "alex@example.com",
"company_name": "Example Company",
"company_domain": "example.com"
}Fictional data. Replace sample values before using a real Play.
Proposed JSON contract for your receiver, not a ready-made destination API request. Implement the translation in Technical setup. All prospect values are fictional and all setup placeholders must be replaced. 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 field | Value to send |
|---|---|
event | Keep 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. |
handoff_id | Supply a stable identifier for this logical handoff. Reuse it on a retry, and use a different identifier for a genuinely new event. Do not assume Unify automatically creates this sample field. If missing: Hold the handoff until the receiver or upstream workflow can establish its identity. |
prospect_name | Select the available full name 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. |
prospect_email | Select the available email 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. |
company_name | Select the available company name 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. |
company_domain | Select 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. |
Serialize the validated receiver payload as JSON. The bucket, key construction, encryption policy, and allowed prefix are server-side settings, not arbitrary fields supplied by the sender.
Troubleshooting
Start with the stage where the expected data or action stops appearing.
The request is rejected
Protect your own HTTPS receiver with a Bearer secret checked by your application. Keep the destination credentials in the receiver, not in this example payload. 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 Amazon S3 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 Amazon S3 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.
Keep exploring
