Zapier workflow automation ends where the public API ends. There is a three-line spec for picking up the rest.

The shape of the ceiling

Every Zapier integration is a connector, and every connector is a REST or RPC client wrapping someone else's public API. The Salesforce connector talks to api.salesforce.com. The HubSpot connector talks to api.hubspot.com. The Google Sheets connector talks to sheets.googleapis.com. When the connector exists, the Zap is one form away from working. When the connector does not exist, the Zap is, structurally, not the tool.

The places connectors do not exist are not random. They cluster around systems that predate the public REST era and around proprietary desktop clients that never were re-platformed. A non-exhaustive list of where Zapier hits its ceiling on enterprise workflows we see:

• SAP GUI on Windows, including SAP Business One and the green-screen flows in S/4HANA that ops teams actually use day to day. The data eventually gets to SAP servers, but the path through the GUI is what an operator drives, and there is no equivalent public REST.
• Jack Henry, Fiserv (Premier, DNA), and FIS core banking platforms. The screens that open accounts, post wires, and run end-of-day are Windows desktop terminals reached through private host protocols that banks do not expose to a SaaS orchestrator.
• Epic, Cerner, eClinicalWorks. FHIR covers some patient data; it does not cover the order-entry, charge-capture, and check-in screens that a medical assistant actually fills out twenty times a shift.
• Oracle EBS, JDE, PeopleSoft forms-based clients on Windows. Some have a SOAP face; the day-to-day clerk-facing screens are not on it.
• Mainframe terminals (3270/5250 emulators), insurance carrier policy admin clients, and the long tail of homegrown internal tools that were written in Delphi or VB6 and have not changed since. No public API. No connector. No Zap.

A workflow whose only desktop hop is one of those is the workflow that stalls on Zapier and gets quoted at $500K by an enterprise RPA vendor. The reason it stalls on Zapier is structural; the reason it costs $500K elsewhere is not.

The three-line trigger spec

The hand-off point that turns a desktop runtime into something a Zap can talk to is a webhook trigger. In Mediar's desktop agent, webhook is a literal type, defined alongside cron and manual as a TypeScript discriminated union. There is no fourth case. The full definition fits on a screen and is what every workflow author writes against.

The same union is what the desktop scheduler dialog reads at apps/desktop/src/components/ui/scheduler-dialog.tsx:13 when it renders the cron builder, the manual run button, and the webhook URL panel. Two facts follow from this being a discriminated union and not a feature flag. First, the executor branches on the discriminator; a workflow with trigger: { type: "webhook" } gets a stable URL provisioned automatically, no extra SKU. Second, an author can switch a workflow from cron to webhook by changing one field in src/terminator.ts; the runtime, the queue, the source loader, the per-execution timeout, and everything else stays the same. The union is the contract a Zap (or any other orchestrator) signs.

The bridge, on the wire

The composition is one HTTP POST. The Zap does whatever Zapier does best: trigger on a SaaS event, reshape the payload, route it to the right downstream. Then, instead of trying to drive SAP itself, it calls the desktop runtime and lets the runtime drive SAP. The wire trace looks like this:

The Zap is the orchestrator; Mediar's desktop agent is the worker. Read the diagram bottom-up and the responsibilities split cleanly: Zapier owns identity, retries, and the SaaS-to-SaaS half; Mediar owns the desktop session, the legacy app, and the half that required a Windows machine in the first place. Neither side is doing the other's job, which is why the seam is small enough to fit on a wire diagram.

What the two sides actually look like in code

The Zapier side is a Zap whose action is Webhooks by Zapier with a POST to the Mediar workflow's run URL. The Mediar side is a workflow file in source control whose trigger is the webhook variant of the union above. Toggle between them; the things to notice are how thin the Zapier side is and how unaware the Mediar side is of who called it.

// A Zapier "zap" that fires a Mediar workflow
// Trigger: New row in Google Sheets (Zapier connector)
// Action:  POST webhook (Zapier's built-in "Webhooks by Zapier")

POST https://<your-mediar-host>/runs/<workflow-uuid>
Authorization: Bearer <MCP_SERVICE_TOKEN>
Content-Type: application/json

{
  "inputs": {
    "vendor_id":    "{{spreadsheet_row.vendor_id}}",
    "invoice_pdf":  "{{spreadsheet_row.invoice_pdf_url}}",
    "post_to_sap":  true
  }
}

The Mediar workflow does not import a Zapier SDK, does not check a Zapier signing secret, and does not branch on whether the call came from Zapier, Make, n8n, or curl. Its only contract is the trigger discriminator and the input schema. That is what makes the bridge orchestrator-agnostic in practice; the same desktop workflow can be driven by a Zap on Monday and by a Postgres pg_net POST on Tuesday.

Three patterns this composition keeps showing up in

The shapes below are not hypothetical. They are the three Zap-to-desk shapes we keep seeing across F&B, insurance, and community banking. None of them require a Zapier connector that does not exist. All of them require something Zapier does not ship: a desktop agent that can drive a Windows app.

1. Sheet to SAP B1 invoice post

A regional F&B chain's AP team logs incoming vendor invoices in a Google Sheet. The Zap watches the sheet for a new row, formats the row into { vendor_id, invoice_pdf, amount }, and POSTs it to a Mediar workflow. The Mediar workflow opens saplogon.exe, navigates to the AP module, types the fields, attaches the PDF, posts the invoice, and returns the SAP document number. A second Zap step writes the document number back to the sheet. We moved an LG-customer chain from UiPath to this exact pattern; their CFO told the board they are now saving 70% on costs.

2. Inbound email to Jack Henry account open

A community bank's onboarding email lands in a shared inbox. A Zap parses the email with Email Parser, validates the customer record against a CRM step, then POSTs the parsed fields to a Mediar workflow. The Mediar workflow drives the Jack Henry teller terminal, opens the account, sets the right product code, prints the welcome packet, and returns the new account number. The Zap routes the account number back to the CRM and to a Slack channel. Onboarding at one regional core went from 8 weeks to 2 weeks on this pattern.

3. PDF claim to insurance carrier desktop intake

A mid-market carrier receives FNOL PDFs by email. A Zap routes the PDF's URL to a Mediar workflow. The Mediar workflow extracts the fields directly from the PDF, opens the carrier's policy admin desktop client, types the fields into the claim screen, attaches the PDF, and assigns the claim by line of business. Claims intake went from 30 minutes per claim to 2 minutes. That is $750K per year on AP-team headcount math, not press-release math.

What unifies the three is that the Zap is short, the Mediar workflow is the part that does the work no SaaS-to-SaaS connector could have done, and the seam between them is a single POST. Adding a fourth shape (HubSpot deal-won to Oracle EBS, Stripe invoice paid to a regional ERP, a webhook from a vendor portal to a homegrown desktop tool) is the same composition with the SaaS connector swapped.

Honest limits

The composition is not free. The seams that earn most of the support tickets are predictable, and a buyer who is honest about them in design beats a buyer who is honest about them in production.

• Identity on the desktop side. The Mediar agent runs as a real Windows user with a real session. That user has to be logged in to whatever the desktop app needs: SAP, the banking core, the EHR. A locked screen at 2 AM kills the run. Plan for a dedicated unattended-bot user with the right role and a screen-lock policy that does not blank the session out.
• Modal dialogs that only appear once. Many legacy apps show a one-time-per-day dialog (legal disclaimer, login warning, license reminder) that the recorder did not see on the day it captured the workflow. The fix is a recorder pass on a real machine and a fallback step in the workflow; it is not a Zap problem and not a Zapier-side fix.
• Payload size on Webhooks by Zapier. Zapier caps payloads on the webhooks action. For invoice PDFs, do not send the bytes; send a URL the Mediar agent can fetch. The Mediar workflow does the download server-side, then drives the desktop with the local file path.
• Latency budgets. The webhook POST is synchronous up to the per-execution timeout (600 seconds in the queue processor's tokio::time::timeout). For workflows that take longer, the right shape is a queued webhook that returns immediately with an execution_id, followed by a poll step in the Zap. The runtime exposes both shapes; picking one is a workflow design question, not a runtime question.
• Compliance and audit. Two systems mean two audit logs. Zapier's task history covers the Zap; Mediar's execution history covers the desktop run. A real audit query crosses the seam. Mediar is SOC 2 Type II certified and HIPAA compliant on its side; Zapier publishes its own posture. For a regulated workload, plan for the seam in the audit story up front.

Frequently asked questions