Using Make (Integromat) instead of Zapier — gotchas?

Hey all — been using Zapier for a while but hit some limits on data transformation and branching logic. Looking at moving a few of our FieldPulse workflows over to Make (Integromat).

Specifically wondering about:

  • Webhook payload differences — any fields that come through differently?
  • Authentication refresh — does the OAuth token handling behave the same?
  • Custom field values in triggers — I saw this thread about Zapier missing custom fields, curious if Make hits the same issue

Also any general YMMV stuff — I've found Make's error handling way more granular which is nice, but the FieldPulse module seems less polished than the Zapier one.

What gotcha am I missing?

  • Two things:

    • Webhook payloads are identical — same JSON structure. The difference is Make parses nested objects differently in the trigger data mapper. Check the "Data structure" settings on your webhook module.
    • Custom fields: same limitation as Zapier. The custom_fields array is not expanded in trigger payloads. You need a second API call to /work_orders/{id} with include=custom_fields.

    See Setting Up Webhooks — the payload examples there apply to both platforms.

  • Devon — yeah this one tripped me up too when I first looked at it. Leo's right on the custom fields thing, that's a platform limitation on our end not a Zapier/Make thing.

    The OAuth refresh is actually smoother in Make in my experience. Their "Connection" model handles token refresh automatically without the extra "Refresh Token" step you need in Zapier. Heads up though: if you're using a custom OAuth app (not the default FieldPulse one in Make's app directory), you'll need to manually configure the token endpoint. That's auth.fieldpulse.io/.../token with grant_type refresh_token.

    One gotcha that got me: Make's "FieldPulse" app in the directory is on v1 of our API. If you need v2 features (like the new checklist endpoints), use the generic HTTP module and hit the endpoints directly. The v1 app works fine for work orders and customers, just not the newer stuff.

    Also worth noting — Make doesn't have the same "Test Trigger" behavior as Zapier. You often need to run the scenario once to see sample data, which can be annoying when you're building against production. I usually set up a filter early in the scenario to catch only test records while I'm building.

    Documentation link for the direct API approach: Using the FieldPulse API

  • Perfect — the v1 vs v2 thing is exactly the kind of detail I needed. Already running into the "run it once to see data" pain, good to know that's expected behavior and not me missing something.

    Will likely go HTTP module route for the newer endpoints. Appreciate the confirmation on OAuth refresh too.

  • From a reliability perspective, Make's error handling is indeed more granular — i.e., you can configure specific error routes per module rather than Zapier's all-or-nothing approach.

    One edge case to consider: Make's webhook module does not currently support signature verification out of the box (unlike Zapier's "Webhooks by Zapier" which has a raw body option). If you need to verify the X-FieldPulse-Signature header, you'll need to use the HTTP module with "Get request headers" enabled, then run the HMAC verification in a Code module.

    Relevant for security posture if you're processing sensitive work order data. The signature verification flow is documented in Setting Up Webhooks — worth implementing if this is customer-facing.

  • From a governance perspective, it is worth noting that Make's data residency differs from Zapier. Make offers EU data residency; Zapier does not. If your organization has data localization requirements, this may influence platform selection regardless of functional considerations.

    Additionally, Make's audit logging is more comprehensive — i.e., you can export execution logs via API, which may satisfy internal compliance requirements that Zapier's dashboard-only logs do not meet.