How to integrate Unify with Google Sheets
To integrate Unify with Google Sheets, send a Play webhook to a receiver that maps prospect fields into a Sheets API append request. The receiver manages Google authorization and writes to a selected spreadsheet and range. Inspect the returned update details and the actual row before treating the handoff as complete.[1][3]
- Connection
- Via webhook + endpoint
- Spreadsheets
- Tool
- Google Sheets
- Receiver → Sheets API
- Data flow
- Unify → Custom receiver → Google Sheets
- JSON payload
At a glance
- Agree on an explicit column order and separate reviewer-owned fields
- Choose append for new handoffs or design a separate matching update
- Assign a person to interpret and act on each row
When this workflow makes sense
Start with the decision your team needs to make, then choose the connection that supports it.
A sheet is useful when a person needs to review a manageable set of records before the next action. Define the review decision and its owner before adding rows. Separate incoming facts from notes and approval fields so another delivery cannot be mistaken for a fresh human decision.
A good fit when
Teams that already review prospect handoffs in Google Sheets and can maintain the receiving automation.
Reconsider the plan when
A large shared spreadsheet can become an unclear system of record. Decide whether a CRM, database, or dedicated review app better matches the process.
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 |
|---|---|
| Columns | Agree on an explicit column order and separate reviewer-owned fields |
| Write | Choose append for new handoffs or design a separate matching update |
| Review | Assign a person to interpret and act on each row |
| Check | Compare the stored row with the intended input |
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.
Build a prospect review queue
A small operations team reviews selected prospects in a sheet.
Make the review action clear before adding columns.
- Choose the required prospect columns
- Append one fictional record
- Ask the owner to inspect the row and review fields
Review repeated prospect deliveries
The same prospect can be selected more than once.
Decide whether another row represents another handoff.
- Define append versus update behavior
- Send a controlled repeat
- Inspect the rows and existing reviewer notes
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
The selected sheet contains the intended fictional prospect row with the correct column mapping.
Compare the API update details with the intended sheet and row. Receiver acceptance alone does not prove a Sheets write.
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 Google Sheets.
Can a Unify webhook write into Google Sheets?
A custom receiver can turn the outbound request into an authorized Sheets API write. This article describes that implementation rather than a native connector.[1]
Why use a receiver?
The receiver can map the body, manage Google credentials, and track completion outside Unify’s short request window.[2]
Does append update an existing prospect?
No. Append adds rows after the detected table. Matching and updating an existing prospect is a separate design.[3]
How can I keep text from becoming a formula?
Use RAW for this feed. USER_ENTERED follows the parsing behavior used when values are entered in the interface.[4]
How do I know where data was written?
Inspect the append response’s updates and confirm the intended row in the spreadsheet.[3]
Limits & decisions
Check these boundaries before designing a live workflow around the connection.
- Requires an implemented receiver and Google authorization
- Append is not an upsert or a duplicate-prevention guarantee
- A spreadsheet review decision does not automatically sync back to Unify
- No live spreadsheet was changed
What the connection supports
Understand the connection, the data involved, and the behavior that matters for a Unify + Google Sheets workflow.
POST JSON to a receiver, then append a mapped row
| Decision | What to know |
|---|---|
| Write | spreadsheets.values.append adds values after a logical table[3] |
| Mapping | A ValueRange carries the row arrays[3] |
| Input mode | RAW preserves input values without parsing them as user-entered expressions[4] |
| Access | OAuth scopes and spreadsheet access govern the write[5] |
Technical setup reference
References and requirements for the Google Sheets connection.
Connection requirements and setup checklist
Before connecting
- A Unify Play with a Webhook action
- An HTTPS receiver with an owner, input validation, and a durable job store
- A controlled test record and a deliberate policy for repeat delivery
- Google API authorization with access to the chosen spreadsheet
- A spreadsheet ID, a named sheet, and agreed column order
Authorize the worker
Configure Google authorization and a documented Sheets scope. Confirm that the acting identity can edit the selected file. An API key alone does not grant write access to a private spreadsheet.[5]
Inspect the row and a repeat
Compare the append response’s updates with the visible row. Send a controlled repeat and inspect your application’s repeat policy. Append does not perform a business-key upsert.[3]
Request configuration
- Method
POST- URL pattern
https://YOUR_APP.vercel.app/api/unify-to-sheets- Headers
Content-Type: application/jsonX-Unify-Webhook-Key: YOUR_WEBHOOK_SECRET- Authentication
- Use a custom X-Unify-Webhook-Key header in the Play and validate it inside your receiver. This header is an example contract you implement, not a built-in provider credential. Keep destination authorization and token renewal in the worker.
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",
"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.
The keys are an example handoff format, not required Unify field names. 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.[2]
| Payload field | Value to send |
|---|---|
event | A fixed label you choose for this workflow |
prospect_name | Use {{ person.first_name }} and {{ person.last_name }} for the prospect name |
prospect_email | Use {{ person.email }}; decide how to handle missing values |
company_name | Use {{ company.name }} |
company_domain | Use {{ company.domain }} |
The example object goes to your receiver. The worker converts its fields into a two-dimensional values array; object key order is not a column-mapping contract. The A1 range identifies the logical table used for append.
Troubleshooting
Start with the stage where the expected data or action stops appearing.
The API denies access
Check the acting identity, authorized scope, and file permissions. Confirm the worker is using the intended spreadsheet ID.[5]
Values appear in unexpected columns
Inspect the values array and A1 range. Append locates a logical table within the range, rather than updating a row by prospect email.[3][4]
A repeat creates another row
Append adds values after the existing table. If one row per prospect is required, implement an explicit matching and update design instead.[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
