How to integrate Unify with Zendesk
To integrate Unify with Zendesk, use a Play webhook to create a ticket through the Zendesk Tickets API. For an internal operational handoff, include an explicit private comment with public: false and choose the requester deliberately. Review account triggers separately because creating a ticket can invoke the account’s configured business rules.[1][3]
- Connection
- Via webhook
- Customer engagement
- Tool
- Zendesk
- Zendesk ticket
- Data flow
- Unify → Zendesk
- JSON payload
At a glance
- Define the request that the receiving team can resolve
- Choose the internal requester deliberately
- Use an internal note and review ticket triggers
When this workflow makes sense
Start with the decision your team needs to make, then choose the connection that supports it.
A ticket is appropriate when a team already owns an intake and resolution process. Give the handoff a concrete purpose, such as checking account context before a sales action, and keep its internal identity separate from a customer asking for help. This avoids polluting a support queue with unexplained prospect records.
A good fit when
Teams with a defined internal Zendesk workflow and an owner for the requested review.
Reconsider the plan when
For ordinary seller tasks, a CRM activity or task manager may fit better than a support ticket.
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 |
|---|---|
| Purpose | Define the request that the receiving team can resolve |
| Identity | Choose the internal requester deliberately |
| Visibility | Use an internal note and review ticket triggers |
| Resolution | Track the team outcome separately from ticket creation |
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.
Request an internal account check
A team must review context before a prospect handoff continues.
State the question without impersonating a customer request.
- Select the internal requester
- Write a focused review request
- Inspect the routed ticket
Validate ticket business rules
The new intake may interact with existing assignment and notification rules.
Test the account configuration before live delivery.
- Review relevant triggers
- Create a controlled internal ticket
- Inspect the audit and resulting actions
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
A ticket reaches the intended team with an internal note and correct requester.
Inspect the ticket audit and routing outcome. Confirm note visibility and notification behavior before enabling live intake.
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 Zendesk.
Is this a prospect email workflow?
This design creates an internal operational ticket, not an outbound sales message.[3]
How do I make the initial comment private?
Set public: false inside the comment object.[4]
Does a private note disable every automation?
No. Review ticket triggers and their configured actions separately.[5]
Why choose an internal requester?
Requester and submitter are distinct ticket roles; choose the identity that accurately represents the internal request.[3]
Does ticket creation prove the request is resolved?
No. The API creates the record; resolution is a later team outcome.[3]
Limits & decisions
Check these boundaries before designing a live workflow around the connection.
- This use case requires a legitimate operational or support handoff
- Private comment visibility does not disable all account business rules
- Repeated delivery can create another ticket without an explicit identity policy
- No live Zendesk ticket or notification was created
What the connection supports
Understand the connection, the data involved, and the behavior that matters for a Unify + Zendesk workflow.
Technical setup reference
References and requirements for the Zendesk connection.
Connection requirements and setup checklist
Before connecting
- A Unify Play with a Webhook action
- An authorized Zendesk agent or admin and API-token access
- A known internal requester ID and reviewed ticket triggers
Define the ticket purpose
Choose an internal requester and a concrete request the receiving team can resolve. Use the actual requester_id rather than automatically making the prospect the requester.[3]
Choose internal comment visibility
Place body and public: false inside ticket.comment. This creates an internal note; it does not replace reviewing all business rules for the account.[4]
Review routing rules
Inspect the triggers that run when tickets are created or updated. Validate assignment and notification behavior on a controlled ticket.[5]
Request configuration
- Method
POST- URL pattern
https://YOUR_SUBDOMAIN.zendesk.com/api/v2/tickets.json- Headers
Content-Type: application/json- Authentication
- Use Zendesk API-token Basic authentication: username is YOUR_AGENT_EMAIL/token and password is YOUR_ZENDESK_API_TOKEN. Configure Basic Auth in Unify rather than putting credentials in the JSON.
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
{
"ticket": {
"subject": "Review prospect handoff",
"requester_id": 123456789,
"comment": {
"body": "Internal review of fictional prospect Avery Morgan, avery@example.com.",
"public": false
}
}
}Fictional data. Replace sample values before using a real Play.
Replace the fictional requester ID with a real internal user. The private note setting does not guarantee that unrelated triggers cannot send notifications. 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 |
|---|---|
ticket.subject | State the action the receiving team should resolve |
ticket.comment.body | Map only relevant internal review context |
Use ticket.subject for the requested action and ticket.comment.body for the minimal context. Replace the fictional numeric requester_id with a known internal user ID. Keep public: false as a deliberate visibility setting.
Troubleshooting
Start with the stage where the expected data or action stops appearing.
The note is visible externally
Check ticket.comment.public and inspect the actual ticket comment.[4]
An unexpected notification fires
Review account triggers and their conditions and actions.[5]
The ticket cannot be created
Verify API-token authentication, requester identity, and the API error details.[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
