How to integrate Unify with Linear

To integrate Unify with Linear, configure a Unify Play Webhook action to call the documented API with POST, the required credentials, and the destination-specific JSON body. Use this connection to create a Linear issue for a defined account handoff.[1][2][3]

By UnifyDocumentation reviewed September 15, 2026

Explore scenarios Technical setup Open Unify

Connection: Via API; Team collaboration
Tool: Linear; Linear
Data flow: Unify → Linear; JSON payload

At a glance

Via API: Linear receives the handoff
POST request with an explicit JSON contract and destination authentication
Test scenario: Distinguish an API error from success

When this workflow makes sense

Start with the decision your team needs to make, then choose the connection that supports it.

An issue should represent work someone has agreed to do. Use it for a specific account review or operations task with a clear completion condition. Avoid flooding an engineering backlog with raw prospect events that have no assigned decision.

A good fit when

Teams that want to create a Linear issue for a defined account handoff and have an owner for the receiving process. The destination account must permit the documented request and the chosen downstream action.

Reconsider the plan when

The receiving team has not agreed how this Linear operation should behave when the same record arrives again. Resolve the matching rule before enabling retries.

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	Create a Linear issue for a defined account handoff
Receiving contract	Agree which of the 2 example data fields the receiving process actually needs. Set missing-value and identity rules in the field mapping below.
Execution boundary	Give one owner access to inspect the Linear request and its resulting action.
Completion	Decide who can confirm the Linear 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.

Create a Linear issue for a defined account handoff

Start with one controlled record and one intended Linear outcome. Keep the test destination separate from live operations.

The decision that matters

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 Linear 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

Your validation checklistThe Linear destination and record identity are correctThe required fields match the controlled recordThe completion evidence is saved and the next action has an owner

0 of 3 checks marked by you

Distinguish an API error from success

Distinguish an API error from success: use an invalid team ID in a controlled request and inspect the GraphQL response. Ensure monitoring catches application errors rather than accepting every HTTP 200.

The decision that matters

Decide whether this case should be held for review, corrected, or retried. Make that decision before running Linear 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

Your validation checklistThe intended edge case has an observable resultRecovery does not create unintended additional workThe Linear owner has a documented recovery decision

0 of 3 checks marked by you

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

Create a Linear issue for a defined account handoff

Open the returned issue in the correct team and verify its description and intended owner. Inspect GraphQL errors as well as HTTP status.

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 Linear.

Why can HTTP 200 still mean the Linear action failed?

GraphQL responses can include an errors array. Inspect that array and issueCreate.success, then confirm the actual issue exists.[3]

Limits & decisions

Check these boundaries before designing a live workflow around the connection.

GraphQL can report application errors inside an HTTP success response. The Unify HTTP result alone does not establish issue creation.[3]
API and trigger access depend on the destination account, permissions, and configuration. This request pattern is not a claim of native Unify sync.[3]

What the connection supports

Understand the connection, the data involved, and the behavior that matters for a Unify + Linear workflow.

Connection flowVia API

Unify

Linear

Prospect data

POST / JSON

Documented behavior at a glance
Decision	What to know
Unify action	Outbound HTTP request with configurable method, authentication, headers, and body[1]
Receiving operation	Select the receiving Linear team and obtain its UUID. Decide which Play records justify an issue rather than a notification.[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 Linear connection.

Unify reference: Webhook action Linear reference: official connection reference

Connection requirements and setup checklist

Before connecting

A Unify Play with a Webhook action and a controlled record for testing
Access to the intended Linear environment and the permissions required by the cited API or trigger
The destination identifiers, credentials, and schema used by the request below
An agreed record identity, duplicate policy, and owner for failed handoffs

Prepare the Linear destination
Select the receiving Linear team and obtain its UUID. Decide which Play records justify an issue rather than a notification.[3]
Configure the destination action
Use issueCreate with variables for title, description, and teamId. Inspect GraphQL errors and issueCreate.success even when the HTTP request succeeds.[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://api.linear.app/graphql
Headers: Content-Type: application/json
Authorization: YOUR_LINEAR_API_KEY
Authentication: For a personal API key, send Authorization: YOUR_LINEAR_API_KEY without the Bearer prefix. OAuth access tokens use Bearer instead.

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

Example request body

{
  "query": "mutation CreateHandoff($input: IssueCreateInput!) { issueCreate(input: $input) { success issue { id title } } }",
  "variables": {
    "input": {
      "teamId": "YOUR_TEAM_UUID",
      "title": "Review Example Company",
      "description": "Prospect handoff: Alex Morgan, alex@example.com. Source: Unify."
    }
  }
}

Fictional data. Replace sample values before using a real Play.

Illustrative JSON for the documented receiving operation. All prospect values are fictional. Replace credentials, identifiers, schema-specific fields, and fixed example values before a controlled test. 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
`query`	string / static / Request configurationKeep the literal "mutation CreateHandoff($input: IssueCreateInput!) { issueCreate(input: $input) { success issue { id title } } }" 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.
`variables.input.teamId`	string / configured / Destination settingsReplace this placeholder with the actual destination identifier or credential from the receiving account. Keep credentials out of prospect fields and shared examples. If missing: Do not send the request until this setting has been supplied and checked.
`variables.input.title`	string / dynamic / Message template plus selected person/company fieldsKeep the editorial message template and replace only its fictional person name, email, or company name with available source fields. Preserve JSON escaping. If missing: Remove optional missing context from the message; hold it if the receiving team cannot identify the record.
`variables.input.description`	string / dynamic / Message template plus selected person/company fieldsKeep the editorial message template and replace only its fictional person name, email, or company name with available source fields. Preserve JSON escaping. If missing: Remove optional missing context from the message; hold it if the receiving team cannot identify the record.

Keep the GraphQL query fixed and map prospect data into variables.input. Do not build query syntax by concatenating untrusted prospect text.

Troubleshooting

Start with the stage where the expected data or action stops appearing.

The request is rejected

For a personal API key, send Authorization: YOUR_LINEAR_API_KEY without the Bearer prefix. OAuth access tokens use Bearer instead. 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 Linear 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 Linear 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: 2026-09-16. Report a correction to Unify with the tool name, source URL, and behavior you observed.

How to integrate Unify with Linear