How to Reconcile Support Tickets Between Front and an External Helpdesk via REST

Build a Spojit workflow that runs every morning, pulls open conversations from Front and open tickets from an external helpdesk's REST API, diffs the two sets, and posts a reconciliation summary to Slack so nothing falls between your two support systems.

What This Integration Does

When a support team runs two systems side by side, for example Front for shared inboxes and a separate helpdesk for engineering or back-office tickets, items drift out of sync. A conversation gets resolved in Front but its linked ticket stays open in the helpdesk, or a ticket is closed in the helpdesk while the customer thread in Front is still waiting. This workflow gives you a daily safety net: it lists what is currently open on each side, compares them on a shared reference, and flags anything that exists in one system but not the other before it turns into a missed reply.

A Schedule trigger fires the workflow on a cron expression in your timezone. A Connector node lists open Front conversations, and a second Connector node on the http connector calls your helpdesk's REST API to fetch its open tickets. A Transform node builds two keyed sets and diffs them, a Condition node checks whether any mismatches were found, and a Connector node on slack posts the summary. The workflow is read-only against both systems: it never closes or reopens anything, so re-runs are safe and idempotent. Each run leaves a fresh summary in Slack and an entry in your execution history.

Prerequisites

A Front connection in Spojit (Connections → Add connection → Front) with an API token that can list conversations.
An API key for your external helpdesk, stored as an API-key connection or referenced directly in the Authorization header of the http connector node.
A Slack connection with permission to post to your target channel, and the channel ID or name you want the summary sent to.
A shared reference field that links the two systems, for example a ticket number, order ID, or email address that appears on both a Front conversation and a helpdesk ticket. Reconciliation is only as good as this key.
Your helpdesk's REST endpoint and query parameters for listing open tickets (most helpdesks expose something like GET /api/v2/tickets?status=open).

Step 1: Add the Schedule trigger

Open the Workflow Designer, add a Trigger node, and set its type to Schedule. Enter a 5-field cron expression and an IANA timezone. For a weekday 8am run in Sydney use:

0 8 * * 1-5
Australia/Sydney

The trigger output is { scheduledAt }. A single Schedule trigger can hold more than one schedule, so you can add a second cron line if you also want a mid-afternoon pass.

Step 2: List open Front conversations

Add a Connector node on the front connector in Direct mode and pick the list-conversations tool. Filter to open conversations and the inbox you care about. A typical configuration:

{
  "q": "is:open",
  "limit": 100
}

Map the result to an output variable such as frontResult. Front returns conversations in pages, so capture the conversation array from {{ frontResult }} for the next step. If your inbox can exceed one page, see the Tips section on pagination.

Step 3: Pull open tickets from the helpdesk REST API

Add a Connector node on the http connector in Direct mode and pick the http-get tool. Point it at your helpdesk's list endpoint and pass your API key in the Authorization header. This is the standard Spojit pattern for any system without a native tile.

URL:     https://api.yourhelpdesk.com/v2/tickets?status=open&per_page=100
Headers: {
  "Authorization": "Bearer YOUR_HELPDESK_API_KEY",
  "Accept": "application/json"
}

Map the response to an output variable such as helpdeskResult. The parsed JSON body is available at {{ helpdeskResult }} (for example {{ helpdeskResult.body.tickets }}, depending on your API's shape). For a deeper walkthrough of calling external APIs this way, see the cross-linked REST tutorial in Learn More.

Step 4: Diff the two sets with a Transform node

Add a Transform node to normalize both lists onto your shared key and compute the differences. Build a set of keys present in Front and a set present in the helpdesk, then derive three lists: items open in Front but missing from the helpdesk, items open in the helpdesk but missing from Front, and the matched pairs. Shape the output so the next step can read counts and arrays directly, for example:

{
  "frontOnly":    [ { "key": "...", "subject": "...", "frontId": "..." } ],
  "helpdeskOnly": [ { "key": "...", "subject": "...", "ticketId": "..." } ],
  "matchedCount": 0,
  "mismatchCount": 0
}

Save this to a variable such as diff. Use the shared reference field from your Prerequisites as the key on both sides, and lowercase or trim it so casing and whitespace do not create false mismatches. If you prefer to write the comparison logic explicitly, you can instead use a Connector node on the code connector with execute-javascript, but a Transform node is enough for a straight set diff.

Step 5: Branch on whether mismatches were found

Add a Condition node that checks whether the diff turned up anything. Set the condition to evaluate {{ diff.mismatchCount }} greater than 0 (or test that {{ diff.frontOnly }} and {{ diff.helpdeskOnly }} are non-empty). Wire the true branch to the Slack step in Step 6. Leave the false branch empty if you only want to be notified when there is something to act on, or wire it to a separate "all clear" Slack message if your team prefers a daily confirmation either way.

Step 6: Post the reconciliation summary to Slack

On the true branch, add a Connector node on the slack connector in Direct mode and pick the send-message tool. Set channel to your support-ops channel and build the message from the diff variables:

{
  "channel": "#support-reconciliation",
  "text": "Daily Front / helpdesk reconciliation ({{ scheduledAt }})\n\n:inbox_tray: Open in Front, missing in helpdesk: {{ diff.frontOnly.length }}\n:ticket: Open in helpdesk, missing in Front: {{ diff.helpdeskOnly.length }}\n:white_check_mark: Matched: {{ diff.matchedCount }}"
}

To list the individual mismatched items rather than just counts, wrap the message body in a Loop node over {{ diff.frontOnly }} (and a second loop over {{ diff.helpdeskOnly }}), appending one line per item, then send a single consolidated message. If your team would rather review before acting, you can add a Human approval node ahead of any future write-back step, but this reconciliation workflow stays read-only by design.

Tips

Both list calls are paginated. If an inbox or queue can exceed one page, wrap the relevant Connector node in a Loop (While) node that follows the next-page cursor until the API stops returning one, accumulating results before the Transform step.
Pick the cron time to land after both systems have settled for the day but before your team starts, so the summary is waiting when they log in. Always set the IANA timezone explicitly so daylight-saving shifts do not move the run.
Keep the comparison key strict and stable. Normalizing case and whitespace in the Transform node prevents the same item showing up as both "Front only" and "helpdesk only".
Ask Miraxa, the intelligent layer across your automation, to scaffold this for you with a prompt like "Add a Transform node that diffs {{ frontResult }} and {{ helpdeskResult }} on a shared ticket key and a Condition node that posts to Slack when there are mismatches", then fine-tune the fields in the properties panel.

Common Pitfalls

A wrong or expired Authorization header on the http node returns 401 and the run fails before the diff. Confirm the key and the exact Bearer versus raw-token format your helpdesk expects.
If the two systems use different status vocabularies, "open" on one side may include states the other side already considers closed. Filter both queries to comparable statuses, or normalize status in the Transform node.
Reading {{ helpdeskResult }} at the wrong path is a common error. Inspect the execution log for the node to see the real response shape before wiring the Transform node.
Schedule triggers do not back-fill missed runs. If the workflow is disabled for a day, that day is simply skipped, so do not treat the Slack summary as a complete audit trail on its own.

Testing

Before scheduling it, validate the logic on a small scope. Temporarily narrow both list queries (for example limit: 5 on Front and per_page=5 on the helpdesk), then use the Run button to execute once. Open the execution history and step through each node: confirm frontResult and helpdeskResult hold the records you expect, that diff contains the right frontOnly and helpdeskOnly arrays, and that the Condition node routes correctly. Hand-create one known mismatch (resolve a conversation in Front but leave its ticket open) and confirm it shows up in the Slack message. Once the summary reads correctly, restore the full limits and enable the Schedule trigger.