Skip to content
Moosewave
Demo

Integration directory preview

Connect the tools your business already runs.

Explore how ecommerce, CRM, forms, support, payments, analytics, and warehouse tools could share data with Moosewave. Each preview explains what would move, in which direction, and how changes would be recorded.

Directory preview. These 91 entries show designed connection paths, not a list of live connectors. Check current provider availability before implementation.
Browse directory previewsFollow a customer update
What comes in
Profiles & events
What goes out
Audiences & updates
What stays recorded
Activity history
Example customer update One customer story
SShopifyOrder paid
HHubSpotStage changed
TTypeformForm answered
ZZendeskCase opened
ACustomer record · AdaLatest customer details, with their sourcesProfile · permission · orders · sales · supportCombined
AudienceMembership updated
AutomationNext step checked
HistoryChange recorded
New data can change the next action. It cannot create an opt-in or remove someone from a do-not-send list.

How connections work

What is an email marketing integration?

An email marketing integration is a maintained connection between a marketing platform and another business system. In this Moosewave preview, customer records you are allowed to use and useful business updates could contribute to one profile. An order, form submission, or support change could then update an audience or automation. The data listed on a card does not confirm a live connector.

An integration moves information between systems. It does not create marketing permission or decide which system wins when records disagree.

The preview keeps choices about which fields match, which way data moves, activity history, and retry details with the connection instead of hiding them after setup. It describes the intended product, not current provider availability.

From source to decision

Follow one customer update from source to result.

These illustrative scenarios show how a useful connection would remember where the data came from, update the matching customer, change the next action, and record why it changed. They are not live connection records.

Example data flowFollow one customer updateExample only
SourceShopifyUpdateOrder paidRecordevt_shopify_purchase
  1. 01 · SourceOrder paid

    Shopify supplies the selected record, the change that happened, and the provider ID used to match it.

  2. 02 · Details4 useful details
    • Matching customer
    • Order #1842
    • Purchased products
    • Payment and discount state
  3. 03 · CustomerProfile updated

    The existing customer profile and order history are updated from the selected order fields.

  4. 04 · Next actionWhat changes next

    The cart reminder stops. The matching post-purchase automation can begin if this customer may receive it.

  5. 05 · HistoryResult recorded

    The connection history shows the original order, what changed, and where the next update will continue.

This rule still applies. A purchase does not create marketing permission. The customer's opt-in and do-not-send status still decide what may be sent.

01

Shopify purchase

In this example, a Shopify purchase would update the order, stop its cart reminder, and allow the matching post-purchase automation only when the customer may receive it.

02

Typeform signup

In this example, a Typeform response would update a matching profile and lead audience, then start a welcome automation only when the person opted in.

03

HubSpot customer-stage change

In this example, a HubSpot customer-stage change would update selected CRM fields, an audience and a follow-up automation. Two-way updates would affect matching records only.

04

Zendesk support case

In this example, a Zendesk case would add the current support status to a profile and pause promotional follow-up while the case is open without overriding permission.

Connection directory

Which tools integrate with Moosewave?

Browse 91 proposed provider connections, automatic webhook updates, APIs, automation services, and migration paths. Each card says which way data would move and what it would include; inclusion does not mean the connection is live, certified, or available for self-serve setup.

Popular preview entries, then every path

Showing 8 of 91 connections
Preview · Provider connection (managed)

Shopify

Would handle: Customers, products, carts, orders, refunds, events, and selected updates to existing customer profiles.

Intended direction
Two-way
Category
Commerce & payments
Preview · Provider connection (managed)

Stripe

Would handle: Customers, checkouts, payments, invoices, subscriptions, disputes, refunds, and credit notes.

Intended direction
Into Moosewave
Category
Commerce & payments
Preview · Provider connection (managed)

Typeform

Would handle: Forms, questions, responses, profiles, list membership, and submission events.

Intended direction
Into Moosewave
Category
Forms & lead capture
Preview · Provider connection (managed)

HubSpot

Would handle: Contacts, selected lists, deals, customer-stage changes, and selected updates to existing records.

Intended direction
Two-way
Category
CRM & customer service
Preview · Provider connection (managed)

Zendesk

Would handle: Requesters, tickets, ticket status, conversations, and support-status changes.

Intended direction
Into Moosewave
Category
CRM & customer service
Preview · Provider connection (managed)

Recharge

Would handle: Customers, subscriptions, charges, orders, cancellations, and subscription-status changes.

Intended direction
Into Moosewave
Category
Reviews, loyalty & subscriptions
Preview · Provider connection (managed)

Meta Custom Audiences

Would handle: People who have permission to join the audience, privacy-protected identifiers, additions, removals, and provider status.

Intended direction
From Moosewave
Category
Ads & acquisition
Preview · Provider connection (managed)

Snowflake

Would handle: Export file lists, import order, connection history, and warehouse status.

Intended direction
From Moosewave
Category
Analytics & warehouses

83 more preview entries in this view

Every card describes what the connection is designed to handle, not current availability. For an working connection, confirm the exact data, direction, sign-in method, available history, and any cleanup required in the provider before connecting it.

Integration planning detailsOpen the data list, setup steps, status checks, permission rules, and custom connection options when you need them.

Shared customer data

What data can Moosewave integrations share?

The table below describes the product model, not live coverage for every directory entry. For any available connector, the useful question is what its data may change, and which decision still needs approval.

On a small screen, swipe the table sideways to read every column.

Data typeData includedIntended Moosewave use
Customer profiles and matchingEmail, phone, provider IDs, customer details, original system, and a record of merged profiles.Match activity to the right customer record without pretending two source records are automatically the same person.
Permission and do-not-send statusWhat the person agreed to, where and when they agreed, the wording shown, channel choices, opt-outs, and any reason not to send.Decide whether a person may receive a message or join an advertising audience.
Forms and leadsForm IDs, response IDs, selected answers, landing-page details, and signup source.Update fields, add form-list membership, qualify a lead, and start a permitted follow-up.
Commerce and subscriptionsProducts, carts, orders, products in each order, discounts, payments, refunds, shipments, and subscription status.Stop outdated reminders and start the right cart, post-purchase, renewal, or win-back automation when allowed.
CRM and supportCustomer stage, deals, account fields, tickets, status, conversations, and selected tags.Keep sales and support details beside campaign decisions, with a named owner for every shared field.
Reviews and loyaltyReviews, ratings, points, tiers, rewards, referrals, and advocate activity.Recognise customer contributions and time review, loyalty, or referral automations from real activity.
Audience destinationsAllowed members, what they agreed to, do-not-send decisions, provider request IDs, and exclusions.Add or remove allowed audience members while keeping the provider's status for each request.
Analytics and warehousesCustomer activity, profile details, export file lists, import order, continuation points, and connection results.Bring useful data into the customer history or export selected records for analysis.

Setup and upkeep

How does a Moosewave integration work?

When a connection is available, setup begins with a clear job and ends with a record you can check. Granting access is one step, not the finish line.

  1. 01

    Choose the job

    Select the tool, the records you need, which way they move, and the result you want. A provider name alone is not a useful plan.

  2. 02

    Limit access

    Connect with the provider method and permissions required for the selected records, no broader than the job needs.

  3. 03

    Choose how data matches

    Choose how contacts and fields match, record opt-in details, name the owner of shared fields, and decide how conflicts are handled before data moves.

  4. 04

    Bring in history

    Import the available history, keep original provider IDs, match duplicate records, and review anything that does not fit the plan.

  5. 05

    Continue from there

    Use provider webhooks (automatic update messages) or scheduled checks, depending on the connection, and continue from the last saved point.

  6. 06

    Operate the connection

    Review connection history, retry temporary failures, pause updates, change access, or disconnect with clear cleanup steps.

See what happened

How do you know a connection is working?

For a working connection, “connected” only means access was granted. The proposed status view goes further: it shows whether expected data arrived, changed something, was excluded for a reason, or will retry after a temporary failure.

Continue from the last saved point.

The intended model keeps a recorded position so a recoverable failure can retry or resume without turning the whole history into new work.

01Last successful update

The latest time the connection completed its selected work without an unresolved error.

Answers: How fresh is this source?

02Records checked

How many records the connection checked, including records that correctly needed no change.

Answers: Were the expected records checked?

03Changes made

Profiles, fields, lists, events, or connected tools that changed after matching and permission checks.

Answers: What actually moved?

04Excluded or unchanged

Records left alone because a person was on a do-not-send list, had not opted in, matched another record, or already had the right value.

Answers: Why did some records not move?

05Retry status

Whether work will retry, what needs attention, and the saved point from which it will continue.

Answers: Will it recover without starting over?

06Disconnect checklist

Which local access was removed and whether an app, token, or webhook must also be removed in the provider console.

Answers: What remains after disconnect?

Permission and connection security

How are marketing permission and connection access protected?

These are two separate permissions. The provider sign-in controls which data a connection may read or change. A customer's opt-in controls which marketing they may receive.

01

Each connection gets only the access it needs

The intended setup uses the provider's sign-in method, such as OAuth, an API key, or an authenticated webhook, and limits access to selected records.

02

Every shared field has an owner

The proposed setup names which system controls each field, how its format changes, what happens when values disagree, and how deletions are handled.

03

Do-not-send always wins

A connection may carry an opt-in record but cannot invent permission. Anyone on a do-not-send list, sometimes called a suppression list, remains blocked.

04

Duplicates do not become new intent

The intended design uses provider IDs and duplicate checks so a retried update does not become a second customer action.

05

Every workspace stays separate

The proposed design keeps connections, sign-in details, field choices, and activity history inside one workspace.

06

Disconnect is explicit

The intended disconnect stops updates, removes access held by Moosewave, and tells you what app, token, or webhook must also be removed from the provider.

Read Moosewave securitySee how do-not-send rules work

For more on customer permission, read why email permission can change and why the safest audience often begins with who the send leaves out.

A path beyond the directory

What if your tool is not listed?

Start with the direction and operating job, then confirm which path is actually available. Depending on current product and provider support, that path could be a managed connector, webhook, API, bridge, MCP tool, or migration.

01

Managed integrations

The proposed provider-specific path covers selected records, historical import, continuing updates, connection status, and ways to pause or disconnect.

Best for
Commerce, CRM, forms, support, ads, and data

02

Inbound and outbound webhooks

The proposed webhook path receives or sends authenticated update messages, matches them to the same customer, retries temporary failures, and records delivery.

Best for
Your application and tools that react to updates

03

REST API and SDKs

The proposed developer path uses OpenAPI or TypeScript, Python and PHP software kits for teams building both sides of a connection.

Best for
Custom applications and internal data jobs

04

Automation bridges

The proposed bridge path uses a configured Zapier, Make, n8n, or Pipedream workflow when a simple automation fits the job.

Best for
Specialised tools and simple workflows

05

MCP tools and migrations

The preview compares an MCP request path with a controlled migration path. Neither label alone confirms current availability.

Best for
Agent workflows and platform changes

Explore the MCP previewExplore the migration previewExplore the email API

Compare an ongoing connection with a controlled email marketing migration, review compatible AI-tool patterns through Moosewave MCP, or review the model for application messages on the transactional email API.

One connected marketing system

The connection matters because the next decision can use it.

An order that lives only in a store, a ticket that lives only in support, or an opt-in that lives only in a form leaves every later decision partially blind. The intended integration model gives the rest of Moosewave one current customer story when the required connection is available.

01FormsKeep the person's opt-in and useful answers together when they ask to hear from you.02CommerceUse products, carts, orders, refunds, shipments, and subscriptions to start timely customer automations.03AudiencesUpdate who belongs in an audience using the latest customer details, opt-in, activity, purchases, and support status.04AutomationsLet useful updates start, change, pause, or end an automation under clear rules.05AnalyticsKeep where data came from, what Moosewave decided, what was delivered, and what happened next in one customer history.

In the intended model, delivery results would continue into email deliverability, while previewed Twilio and Telnyx paths would follow the channel-specific permission and operating rules explained in SMS marketing.

See the whole Moosewave ecosystem

Questions about Moosewave integrations

These answers explain the proposed data and behaviour. The directory is a product preview, not a list of 91 live connections.

What is an email marketing integration?

An email marketing integration is a maintained connection between a marketing platform and another business system. This Moosewave preview shows how customer records you may use and relevant activity could update a shared profile, audience, or automation. It does not confirm that a specific provider connection is live.

Which integrations does Moosewave support?

The directory lists 91 proposed paths across commerce, payments, CRM, forms, support, reviews, loyalty, subscriptions, shipping, ads, analytics, data warehouses, messaging and marketing platforms. The labels describe how each connection could be built; they do not mean 91 connections are live. Confirm current availability and supported data for the provider you need.

Does Moosewave integrate with Shopify?

The directory previews a Shopify path for customers, products, carts, orders, discounts, refunds, store activity and selected updates to existing records. It does not confirm a live Shopify connection. Ask Moosewave to confirm current availability and supported data.

Does Moosewave integrate with HubSpot and Salesforce?

The directory previews HubSpot and Salesforce paths for contacts, customer-stage fields, lists or campaign membership, deals or opportunities, related activity and selected updates to existing records. These entries do not confirm live connections; current availability and supported data must be checked.

Are Moosewave integrations two-way?

The directory marks whether data would move into Moosewave, out of Moosewave, both ways, or once during a migration. A two-way label does not confirm that updates back to the provider are live. For any available connection, confirm which data can change, which system owns shared fields, and whether it can create new provider records.

Can Moosewave import historical customer data?

The intended model can include past data when a provider makes it available. The plan states how far back it will read, how records match, what needs review and how later updates continue. The public preview does not import customer history; confirm provider coverage and evaluation terms first.

How does Moosewave protect marketing permission during updates?

The intended model preserves what a person agreed to, but cannot create permission the original form or system did not capture. Anyone marked “do not send” stays blocked, and exclusions remain visible. Confirm the exact fields and behavior for each available connection.

Can I connect a tool that is not listed?

Possibly. A webhook (an automatic update message), REST API, software kit, automation service, or controlled migration may fit. These are proposed approaches, not a promise that an unlisted tool connects today; ask Moosewave to confirm feasibility.

How can I check whether an integration is working?

For a working connection, the intended status view shows the last successful update, records checked, changes made, temporary errors, planned retries and where processing will continue. This page shows an example, not live customer history.

What happens when I disconnect an integration?

The intended disconnect flow stops updates, removes access held by Moosewave, and tells you what app, token or webhook must also be removed from the provider. Confirm the exact removal steps and saved history for the connection in use.

What is the difference between an integration and a migration?

An integration keeps selected records or events up to date. A migration moves selected data once: first it lists and maps the old account, then previews the result without changes, imports approved data, and checks later changes before the switch. These definitions explain the product model; current connection and migration availability must still be confirmed.

Plan the customer story

Start with the system your plan cannot leave out.

Explore the guided preview, or tell us which tool and data, direction, and business outcome you need so current availability can be confirmed before you plan implementation.

Explore the product previewDiscuss your integration