ZapBounce and Tray.io

Tray.io workflows handle volume and real conditional logic, which means a verification verdict can drive genuine routing rather than a binary include or exclude.

That is the design worth building here: four results, several destinations, and nothing thrown away because a single check was inconclusive.

A binary filter discards a quarter of a B2B list

Treating verification as pass or fail sends catch-all and unknown addresses to the same bin as the invalid ones. On a business list that is roughly a third of the rows.

Those are not the same thing. An invalid address is permanently dead. A catch-all address is unconfirmable and often real. An unknown is a server that would not answer today.

Tray's branching makes it practical to send each one somewhere different, which is what turns the verdict from a filter into information.

How the data moves

  1. Use the HTTP client connector with a Tray auth

    Credentials live in the auth rather than in the step, so rotation is one operation.

  2. Branch on the verdict with a switch

    Four cases on the result field, not two. Valid to the sending path, catch_all to a slower one, unknown to a re-check queue, invalid to suppression. Read the role and disposable flags in a second step, since either can be true on any of the four.

  3. Use the batch endpoint for list work

    A callback trigger workflow receives the completion event, which is cleaner than a loop with a delay.

  4. Keep a re-check queue with a delay

    Unknown addresses go into a queue that re-verifies after two weeks. Greylisting and throttling resolve on that timescale.

Setting it up

  1. Create a Tray auth holding the API key.
  2. Add an HTTP client step calling the verify endpoint for single-record flows.
  3. Add a switch step branching on all four result values: valid, invalid, catch_all and unknown.
  4. Route each branch to its own destination rather than filtering to one.
  5. Build a callback trigger workflow for batch completion events.
  6. Add a delayed re-check path for unknown results.

Tray.io: common questions

How many branches should I build?

One per verdict that gets a different treatment. In practice that is usually four: send, slow send, re-check, suppress.

How long should an unknown wait before re-checking?

Around two weeks. Greylisting and throttling resolve over days, and a shorter delay mostly returns the same answer.

Batch or single calls?

Batch for anything list-shaped. A callback trigger workflow handles the completion event.

Check a Tray.io export today

100 free checks a month, no card. Unknown results and duplicates are never billed.