Vision6

Vision6 is an Australian email and SMS marketing platform, now part of Constant Contact. Agents manage lists and contacts, create and send messages, send transactional email, and read the full set of send reports.

Verified 20 actions API key available

Vision6 website Platform Documentation Capability data verified 2026-08-19

A weekly sync of members from the association database is due

Get List with fields expanded tells the agent what keys this particular list actually accepts

List Contacts finds who already exists, so the batch splits into genuine creates and updates

Agent confirms the batch respects the thousand-per-request ceiling and that no opt-out is being overwritten

Agent posts the create count, the update count, and the automations that will fire to the marketing channel

Update Contacts writes the changes for people already on the list

A marketer approves the create batch, because writing new contacts starts every welcome series armed against this list

What This Integration Enables

Vision6 is an Australian email and SMS platform, now part of Constant Contact, and its REST API draws an unusually clear line between design and delivery. It reads lists and messages, and it writes contacts. It does not create a list, and it does not design a message: those happen in the platform. Once you accept that line, what the API is for becomes obvious. It exists to put the right people into audiences that a marketer built, and to report honestly on what happened when they were mailed. That is a narrower job than most platforms claim, and it is a job an agent can do continuously without ever touching creative work.

FlowRunner agents keep contacts current inside those lists, send transactional messages through reporting groups, and pull the full set of send reports including per variant A/B data, social statistics, and the contacts a message actually reached. Two Vision6 specifics shape the design. Contact fields are the list's own fields, so a workflow reads the definitions before it writes rather than assuming a shared schema. And writing contacts fires automations, which is the platform behaving as documented and also the largest thing an agent can set in motion without meaning to. That is where the digital andon cord goes.

Without FlowRunner

Contact fields assumed A sync writes the same keys into every list, and the ones that do not exist on that list are quietly dropped

Imports with an invisible blast radius A bulk write fires the account's automations, and nobody counts the sequences that started

Reports read as rates Open figures arrive as a percentage with no visible denominator, so a small send looks like a triumph

With FlowRunner

Fields read before they are written The list's own field definitions are fetched first, so the payload matches the list rather than the template

Blast radius named before the write The agent states how many creates it is about to make and what that will start, and waits

Reports read as counts Vision6 returns opened and not opened as two numbers, so the denominator is explicit in every chart built from them

Use Case Scenarios

A member sync that respects each list's own schema

Membership records live in Airtable. Before writing anything, the agent calls Get List with fields expanded, because each Vision6 list defines its own fields and a key that works against one list may simply not exist on another. It maps the Airtable columns onto the list's real field names, splits the batch at the thousand-per-request ceiling that the connector enforces locally rather than letting the platform reject it, and calls Update Contacts for existing members. The remove-unsubscribers switch on the create route stays off, which is its default and which keeps opt-outs intact, so a routine sync cannot walk over somebody's decision to leave.
Reporting that survives being questioned

On a schedule, the agent walks List Reports, pulls each Get Report, and lands the rows in BigQuery. Vision6 reports opens as an opened count and a not-opened count rather than a rate, which means every chart built downstream carries its denominator, and a send to two hundred people never gets presented next to a send to two hundred thousand as though they are comparable. Get AB Test Data fills in per variant figures where a report is flagged as a test, Get Social Statistics covers the sharing side, and List Sent Contacts answers the question that always follows a campaign, which is whether one specific person was actually included.
Transactional mail through a named reporting group

Order confirmations from Shopify go out through Send Transactional Message, up to a hundred recipients per request. Each send names a transactional group, which is what makes the reporting attributable later, and the agent uses an existing group ID rather than a name, because passing a name that does not exist creates a new group and quietly fragments the reporting. Content comes either from a stored message or from the body fields, and placeholders are filled from each recipient's own properties. If the account owner's email confirmation has lapsed, every transactional send fails, so the agent surfaces that specific failure to Slack with the vendor's own remedy attached rather than retrying into a wall.

Human-in-Loop Highlight

Vision6 documents plainly that Create Contacts triggers the account's "when a contact is created from the REST API" automations, and Update Contacts triggers the update ones. That sentence is the whole reason this connector has a gate. An import of ten thousand new members can therefore start ten thousand welcome series, and nothing in this REST API can tell an agent which automations are currently armed against a list. That knowledge lives in the platform's automation screen, where a person can see it and an API call cannot.

So the sync agent runs the update half unattended, week after week, and stops before the create half. It posts: "Weekly member sync ready. 1,847 updates to existing contacts, and 612 genuine new contacts across the Members and Events lists. Creating those 612 will fire whatever REST-created automations are armed on those lists. Last month's equivalent batch was 40. Confirm the welcome series should run for all 612, or hold the batch for a staged import?" The marketer checks the automation screen, sees the welcome series they built in March is still live, and answers. The agent's matching, field mapping, batching, and opt-out protection all happened without anyone asking. The one decision it hands over is the one whose consequences arrive in six hundred inboxes.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

20 actions

Account

Get API Root Confirms the API endpoint and the key work together. Because a key from the platform's legacy interface authenticates nothing here, this is the test that distinguishes a wrong key from a wrong endpoint.

Lists

List Lists Lists the account's contact lists. Lists are created in the platform, so this read is how a workflow finds one rather than makes one.
Get List Reads one list, and with fields expanded returns the list's own field definitions. The read that runs before any contact write.

Contacts

List Contacts Lists and filters the contacts on a list. Filter keys are the list's own field names, so they differ from list to list.
Get Contact Reads one contact with its stored field values.
Create Contacts Writes up to a thousand new contacts per request, and fires the account's automations for contacts created through the API. The remove-unsubscribers switch is off by default, which keeps opt-outs intact.
Update Contacts Updates up to a thousand contacts per request, and fires the account's update automations.
Update Contact Updates one contact. The precise write for a single correction.
Delete Contacts Deletes up to a thousand contacts per request, by IDs or by a filter. A call with neither is refused rather than allowed to select an entire list.

Messages

List Messages Lists the messages designed in the platform. Designing happens there, so this read is how a workflow finds one.
Get Message Reads one message's configuration.
Get Message Content Reads a message's content. Used to preview what a transactional send will actually look like.

Transactional Sending

Send Transactional Message Sends to up to a hundred recipients per request through a named reporting group, with content from a stored message or from the body fields. Its include-unsubscribed switch overrides an opt-out and exists for genuinely transactional mail, which is why it is off by default.
List Transactional Groups Lists the reporting groups transactional sends are attributed to. Used so a send names an existing group rather than creating a new one by accident.
Get Transactional Group Reads one transactional group's configuration and volumes.

Reports

List Reports Lists send reports. The entry point for scheduled reporting sweeps.
Get Report Reads one report. Opens arrive as opened and not opened counts rather than a rate, and SMS sends carry their own delivery, acknowledgement, failure, and response counters.
Get AB Test Data Reads per variant figures, and returns data only where the report is flagged as an A/B test.
Get Social Statistics Reads the sharing and social figures for a send.
List Sent Contacts Lists the contacts a message actually reached. The answer to whether one specific person was included.

Frequently Asked Questions

What can FlowRunner do with Vision6?

FlowRunner agents can run Get API Root, List Lists, and Get List in Vision6, plus 17 more actions.

Does connecting Vision6 to FlowRunner require OAuth?

No. Vision6 connects to FlowRunner with an API key, no OAuth flow required.

Can Vision6 trigger a FlowRunner workflow automatically?

Vision6 doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Vision6

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us