ZapBounce and Workato

Workato is used where recipes go through review and change control. That changes the right design. A check copied into fifteen recipes is fifteen places to update when anything changes.

A custom connector, built once, is what makes the change controllable.

A call pasted into fifteen recipes is fifteen migrations later

Enterprise Workato setups pile up recipes. Put an HTTP call in each one, and every key rotation, error fix and schema change has to be made fifteen times by fifteen owners.

That is how a field name change becomes a six-week project and how one recipe keeps calling a deprecated shape for a year.

A custom connector centralises it: one definition, one set of credentials, one place where an error is handled.

How the data moves

  1. Build a custom connector, not an HTTP action

    Define the verify and jobs actions once with their schemas, and every recipe uses the same interface.

  2. Use Workato's connection framework for the key

    Credentials live in the connection rather than in recipe steps, which is what makes rotation a single operation.

  3. Handle errors in the connector

    Retry on 429 and 5xx inside the connector, so fifteen recipes inherit the behavior rather than each reimplementing it.

  4. Expose the verdict as a typed output

    Typed output lets recipe conditions read the verdict without string matching. A schema change shows up at design time.

Setting it up

  1. Build a custom connector defining the verify and jobs actions with typed schemas.
  2. Configure the connection to hold the API key rather than putting it in recipe steps.
  3. Implement retry with backoff inside the connector for 429 and 5xx responses.
  4. Publish the connector to your workspace so recipes reference the shared version.
  5. Build recipes against the connector's typed outputs rather than parsing JSON.
  6. Version the connector so a schema change can be rolled out under change control.

Workato: common questions

Custom connector or HTTP action?

Connector, in any environment with more than a couple of recipes. The HTTP action duplicates the key, the error handling and the schema everywhere it appears.

How do I handle key rotation?

Through the connection, which is the point of centralising it. Rotating a key embedded in recipe steps means editing every recipe.

What happens when the API adds a reason value?

One more argument for the connector. The four result values are fixed and recipes should branch on those. A new reason is one connector version rather than fifteen recipe edits.

Check a Workato export today

100 free checks a month, no card. Unknown results are refunded.