Myphoner

Myphoner is a calling queue, and the object it is built around is the list: a set of leads with list-specific columns, list-specific outcome categories, and a claim state that decides whose queue a lead appears in. That is a different shape from a sequencer, and it changes what agents are for here. The high-value work is keeping the queue fed with correctly shaped records and making the outcome of a call matter somewhere else within seconds instead of at the end of the week.

Agents read the lists in an account with their lead counts and configuration, the column definitions for any list, and per-list statistics broken down by lead state and category. They create lists, create and update leads, find leads by exact field match within a list, and run free-text search across the whole account. They record the four dispositions a caller produces, Mark Lead as Winner, Mark Lead for Call Back, Mark Lead as Loser and Archive Lead, each with an optional comment, a category that must exactly match one configured on that list, and a follow-up schedule. They move work between people and lists with Delegate Lead and Migrate Lead, read a call's duration, destination number and recording URLs with Get Call, and invite users with scoped roles and list access. Two things constrain how a flow should be built. Create Lead, Update Lead and Find Leads accept a free-form object keyed by the target list's column keys, and Myphoner does not validate unknown keys, so a mistyped key fails silently rather than loudly. And duplicate detection is asynchronous: after a single lead is created it can take around two minutes, and a bulk upload can take up to an hour, so the detected_duplicates field lags right after a load.

On events, be precise. This connector ships no trigger, and Create List Webhook, Create Account Webhook and Delete Webhook are webhook management actions that subscribe an external endpoint of your choosing. They create no FlowRunner trigger. Myphoner publishes no signature or verification scheme for its deliveries, and the notification body carries only a resource_url pointer to the affected entity rather than the entity itself, so a handler would need a follow-up fetch to know what happened. There is a second constraint that matters more for flow design than the missing trigger: Myphoner does not fire webhooks for leads and events manipulated through the API, only for changes made in the app. A disposition your agent records will not come back to you as a webhook. Build the downstream step into the same flow that recorded it, and poll List Leads, Search Leads or Get List Statistics when you need to notice in-app activity.