How to integrate Unify with monday.com
To integrate Unify with monday.com, send a Play webhook to a receiver that creates a board item with monday.com’s GraphQL API. The receiver maps the board and item fields, then checks the response body for errors and the created item ID. HTTP 200 alone does not establish that the item was created.[1][3]
- Connection
- Via webhook + endpoint
- Team collaboration
- Tool
- monday.com
- Receiver → monday.com board
- Data flow
- Unify → Custom receiver → monday.com
- JSON payload
At a glance
- Define the decision represented by one board item
- Separate incoming facts from owner-maintained columns
- Inspect the GraphQL result and board item
When this workflow makes sense
Start with the decision your team needs to make, then choose the connection that supports it.
A board works best when a card represents a decision someone can finish. Define whether the item is a review request, research assignment, or handoff. Keep the incoming facts separate from the status and notes the owner will maintain, and preserve that distinction on repeat deliveries.
A good fit when
Teams already managing prospect review in a monday.com board with an assigned intake owner.
Reconsider the plan when
If the item only duplicates a CRM record without creating a distinct review action, simplify the process first.
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 |
|---|---|
| Meaning | Define the decision represented by one board item |
| Mapping | Separate incoming facts from owner-maintained columns |
| Evidence | Inspect the GraphQL result and board item |
| Repeat | Track the item ID before retrying an uncertain write |
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.
Create an account research item
A prospect needs research before a rep follows up.
Give the board owner a concrete question to answer.
- Choose the board and research question
- Create a fictional intake item
- Ask the owner to review its useful context
Handle an invalid board mapping
A board changes after the automation was designed.
Treat body-level API errors as failed writes.
- Test an invalid column mapping
- Inspect the response errors
- Correct the mapping and reconcile the job
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 item appears on the intended board with the agreed review context.
Require a usable item ID without a relevant GraphQL error, then inspect the board. Keep the item identity for replay handling.
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 monday.com.
Why use a receiver for monday.com?
The receiver can inspect GraphQL errors, whereas Unify does not pass the response body into subsequent Play steps.[2]
Is the destination a webhook URL?
The worker uses the GraphQL endpoint and create_item mutation.[3]
Can I copy board column labels as API IDs?
Use actual column IDs and the documented column value shapes.[3]
Does a successful HTTP status prove creation?
No. Inspect the GraphQL errors and data fields.[5]
Whose permissions apply to the API token?
Token access is constrained by the associated account permissions.[4]
Limits & decisions
Check these boundaries before designing a live workflow around the connection.
- A receiver is required for the proposed result tracking
- Board columns and permission rules are account-specific
- Item creation does not guarantee a person completed the review
- No monday.com board was changed
What the connection supports
Understand the connection, the data involved, and the behavior that matters for a Unify + monday.com workflow.
Create a board item and inspect GraphQL results
Technical setup reference
References and requirements for the monday.com connection.
Connection requirements and setup checklist
Before connecting
- A Unify Play with a Webhook action
- An owned HTTPS receiver with validation and durable job storage
- A controlled test record and a policy for repeat delivery
- A monday.com token with access to the selected board
- A board ID and a defined intake group and column contract
Choose the board contract
Select the board, optional group, and item name. Use actual column IDs and each column type’s expected value format when adding columns.[3]
Authorize the GraphQL call
The worker calls POST https://api.monday.com/v2 with the token in Authorization and Content-Type: application/json.[4]
Construct the mutation
A minimal body is {"query":"mutation { create_item(board_id: 1234567890, item_name: "Review Avery Morgan") { id } }"}. Replace the board ID. Use variables in your implementation rather than interpolating untrusted text into GraphQL.[3]
Inspect the response and item
Check errors as well as data.create_item.id. Record failures in the receiver and compare a successful result with the actual board item.[5]
Request configuration
- Method
POST- URL pattern
https://YOUR_APP.vercel.app/api/unify-to-monday- Headers
Content-Type: application/jsonX-Unify-Webhook-Key: YOUR_WEBHOOK_SECRET- Authentication
- Validate a custom X-Unify-Webhook-Key header in your receiver. This is an example contract you implement. Keep destination credentials 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 prospect body below belongs to your receiver. It is not a GraphQL request. The receiver chooses the board and constructs the mutation; column_values requires the documented JSON representation.
Troubleshooting
Start with the stage where the expected data or action stops appearing.
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
