How to integrate Unify with Google Apps Script
To integrate Unify with Google Apps Script, deploy a web app whose doPost(e) function parses the JSON request and performs a small, owned action. Use the deployed /exec URL and an access configuration compatible with server requests. Validate a custom shared secret in your code before any side effect.[1][3]
- Connection
- Via webhook
- Developer platforms
- Tool
- Google Apps Script
- Apps Script web app
- Data flow
- Unify → Google Apps Script
- JSON payload
At a glance
- Choose one small operation with a visible result
- Validate the deployment identity and custom secret before side effects
- Test redirects and response timing with the actual sender
When this workflow makes sense
Start with the decision your team needs to make, then choose the connection that supports it.
Apps Script can be a useful home for a small Workspace-specific action that a team can maintain. Keep the action narrow enough to understand and verify. Deployment identity, request access, and response redirects are part of the design, not details to postpone until after the script works in the editor.
A good fit when
Teams maintaining a small Apps Script action with an allowed server-accessible deployment and an owner for authentication and errors.
Reconsider the plan when
Use a more explicit HTTP service when you need standard request-header authentication, precise status control, or durable processing beyond the request window.
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 |
|---|---|
| Action | Choose one small operation with a visible result |
| Access | Validate the deployment identity and custom secret before side effects |
| Response | Test redirects and response timing with the actual sender |
| Ownership | Assign someone to maintain deployment versions and failures |
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.
Run a small Workspace action
A selected prospect should enter an existing lightweight Workspace process.
Make the effect explicit and check authentication before doing it.
- Define the input and destination
- Deploy the reviewed handler
- Send a controlled request and inspect the result
Check an uncertain response
The script performs an action but the sender cannot confirm the response.
Investigate before replaying a potentially completed operation.
- Inspect the script execution and destination
- Check redirect handling and duration
- Apply the intended repeat policy before another attempt
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
An authenticated fictional request reaches doPost, passes validation, and produces the small destination change you implemented.
Inspect the script execution and actual destination. Verify redirect handling and the sender’s 8-second deadline; do not treat an HTML login page or a returned text body as proof of success.
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 Apps Script.
Which Apps Script function receives the webhook?
A deployed web app invokes doPost(e) for an HTTP POST. Parse the JSON from e.postData.contents.[3]
Should I use the /dev deployment URL?
No. It is restricted to editors and intended for testing. Use the deployment’s /exec URL for the externally reachable web app.[3]
Is webhook_secret a built-in authentication option?
No. It is a proposed body field your own script validates against Script Properties. Without that code, the field provides no authentication.[4]
Can I assume Unify follows Content Service redirects?
No. Google documents the redirect, but this Unify-to-Apps Script response behavior has not been established by the inspected sender docs or a live test.[5]
Does returning a computed value enrich the next Play step?
No. Unify does not make the webhook response body available to later Play actions. Store the intended result in an explicit destination.[2]
Limits & decisions
Check these boundaries before designing a live workflow around the connection.
- Requires custom validation code and a permitted deployment access model
- The body secret must not be exposed in logs or public examples
- Content Service redirect handling with Unify remains a live-test requirement
- Avoid long-running work inside the sender’s 8-second request window
- No Apps Script deployment or Workspace action was executed
What the connection supports
Understand the connection, the data involved, and the behavior that matters for a Unify + Google Apps Script workflow.
POST / JSON
| Decision | What to know |
|---|---|
| Entry point | POST requests invoke doPost(e)[3] |
| Body | e.postData.contents contains the POST body[3] |
| Identity | The deployment can execute as its owner or the accessing user[3] |
| Configuration | Script Properties store application-wide string configuration[4] |
| Response | Content Service serves output through a redirected URL[5] |
Technical setup reference
References and requirements for the Google Apps Script connection.
Connection requirements and setup checklist
Before connecting
- A Unify Play with a Webhook action
- An Apps Script project with a reviewed doPost implementation
- A permitted web-app access configuration and an explicitly chosen execution identity
- A shared secret stored in Script Properties and excluded from logs
- A controlled destination and a plan to keep request processing short
Implement a narrow handler
Implement doPost(e), parse e.postData.contents as JSON, and validate the required fields. Return an HtmlOutput or TextOutput as required by the web-app contract.[3]
Deploy with the intended identity
Create a web-app deployment, choose the execution identity and permitted access, and copy its /exec URL. The /dev URL is for editors testing the latest saved code and is unsuitable for this external sender.[3]
Validate the response path
Check the actual destination action, elapsed time, and response handling. Content Service redirects to a one-time script.googleusercontent.com URL. The inspected Unify docs do not establish redirect-following behavior, so verify it with a controlled request before enabling live traffic.[2][5]
Request configuration
- Method
POST- URL pattern
https://script.google.com/macros/s/YOUR_DEPLOYMENT_ID/exec- Headers
Content-Type: application/json- Authentication
- This example requires a deployment that can receive a request without an interactive Google sign-in, where your organization permits that access. The script must compare webhook_secret from the JSON body with a value in Script Properties before doing any work. This is custom application authentication, not a Google API-key feature. Use another authenticated receiver if your deployment policy cannot support this design.
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
{
"webhook_secret": "YOUR_SHARED_SECRET",
"prospect_name": "Avery Morgan",
"prospect_email": "avery@example.com"
}Fictional data. Replace sample values before using a real Play.
Application-defined example body. The script must implement secret validation before any side effect. No real secret is shown. 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][3]
| Payload field | Value to send |
|---|---|
webhook_secret | Replace privately with the secret validated by your script; do not log it |
prospect_name | Map documented person-name fields and inspect the rendered result |
prospect_email | Map the intended person email |
The fictional body contains an application-level secret placeholder and selected prospect fields. Parse it through e.postData.contents. webhook_secret is your own validation contract, not a documented Unify variable or Apps Script built-in field.
Troubleshooting
Start with the stage where the expected data or action stops appearing.
Unify receives a Google sign-in page
Inspect deployment access and execution identity. A server webhook cannot complete an interactive user sign-in. Choose a supported access design or another receiver.[3]
The test URL works only for the editor
Use the deployed /exec URL. The /dev URL is restricted to editors and runs the latest saved code.[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
