Zapier Trigger Patterns - Virtuous API Docs

The Raise–Zapier connector is a customer-facing automation tool. It lets customers (typically nonprofit operations teams without developers) build no-code workflows that react to Raise events — sending donations to spreadsheets, triggering thank-you texts, posting to social media, syncing to other no-code tools. For customers, it’s an alternative to bespoke partner integrations for common automation needs. For partner integrations, the Zapier connector matters for two reasons: customers may already be using it for some workflows, and partner integrations should know when Zapier is the right answer versus when a custom integration is. This recipe covers what the connector enables, what’s distinct about it versus a partner-built integration, and the patterns for coexistence.

What the Raise–Zapier connector is

A Zapier connector is a Zapier-published integration that exposes a service’s events and actions to Zapier’s workflow builder. The Raise–Zapier connector exposes:

Capability	Description
Triggers	Raise events that start a Zapier workflow — new donation, new recurring gift, donor update, etc.
Actions	Operations Zapier can perform against Raise — typically read operations like “find a donor”
Sample data	Test payloads Zapier uses when the user is building a workflow

In Zapier’s UI, a customer can build workflows like:

When a new gift arrives in Raise (trigger) → send a Slack message (action in Slack’s connector) → add a row to Google Sheets (action in Sheets’ connector).
When a recurring gift is cancelled (trigger) → create a task in Asana (action in Asana’s connector) → send an email (action in Gmail’s connector).
Daily at 8am (Zapier’s schedule trigger) → search Raise donors created yesterday (action in Raise’s connector) → append to a Google Doc.

These workflows are configured by the customer in Zapier. The customer’s Raise account is connected to Zapier through an OAuth-style flow that the connector handles.

How the connector works under the hood

The connector uses a small set of Raise API endpoints that exist specifically for this integration:

Endpoint	Use
`GET /api/Zapier/test`	Verifies the connection and authentication — used when the customer first connects Zapier to Raise
`POST /api/Zapier/subscribe`	Registers a webhook subscription on behalf of Zapier when the customer creates a trigger
`DELETE /api/Zapier/unsubscribe/{id}`	Removes the subscription when the customer disables the trigger
`GET /api/Zapier/samples/{eventType}`	Returns sample records for Zapier to display while the user is testing the trigger

The /api/Zapier/* endpoints are not for partner integration use. They exist specifically for the Raise–Zapier connector to manage its own webhook subscriptions and sample-data display. Partner integrations should use the standard /api/Webhook/* endpoints documented in Webhooks Overview, which expose the full subscription lifecycle.Calling /api/Zapier/* from a custom integration produces unsupported behavior and may break if the connector’s contract changes. The general webhook surface (/api/Webhook) is the canonical path for partner-managed webhook subscriptions.

When Zapier is the right answer

For some workflows, Zapier is genuinely better than a custom partner integration:

Use Zapier when	Use a partner integration when
The workflow connects Raise to common cloud apps (Slack, Sheets, Gmail, Mailchimp, Salesforce)	The workflow needs custom logic the partner application is better positioned to provide
The customer’s team can maintain the workflow themselves	The workflow requires technical maintenance the customer can’t perform
The workflow is one of several similar ones (let the customer build them all in one place)	The workflow needs to integrate with the partner’s own product UI
The workflow tolerates Zapier’s per-task pricing	High-volume workflows where Zapier’s pricing becomes prohibitive
The workflow doesn’t need transformation logic beyond Zapier’s built-in functions	The workflow needs significant data transformation or business logic
Customer engagement is sufficient as a “low-touch” experience	Customer needs a high-touch, integrated experience inside the partner’s product

The simplest test: if a non-developer at the customer could build the workflow in Zapier in an hour, Zapier is probably the right answer. Custom integrations are for cases where the workflow exceeds Zapier’s capabilities or the integration needs to live inside the partner’s product experience.

Coexistence patterns: when both exist

A common scenario: a customer has both a partner integration and Zapier workflows configured on their Raise account. The partner integration team should be aware of both and design accordingly.

Pattern: complementary triggers

The partner integration handles one set of post-donation actions (those requiring custom logic), and Zapier handles others (simple notifications and routing). Both subscriptions are independent — Raise delivers the event to both. The partner’s webhook subscription was created via POST /api/Webhook; Zapier’s was created via POST /api/Zapier/subscribe (managed by the connector). This pattern works well as long as the two systems don’t duplicate work. If Zapier is posting to Slack for every donation and the partner integration is also posting to Slack for every donation, the customer’s team sees double notifications.

Pattern: clear ownership boundaries

For customers running both, establish clear ownership of which workflows live where:

Workflow	Typical home
Donor-facing thank-you emails	Partner integration (needs customer-branded templates, conditional logic)
Internal Slack notifications for the customer’s team	Either — typically Zapier if simple, partner integration if conditional
Spreadsheet logging for the customer’s accountant	Zapier (the customer manages their own spreadsheets)
CRM sync (to a CRM the partner doesn’t natively support)	Zapier (use the CRM’s Zapier connector)
Major-donor alerts with rich context (lifetime giving, etc.)	Partner integration (needs API queries Zapier can’t easily do)
Donor segmentation tagging	Partner integration (needs business logic)
Daily summary emails to the customer’s team	Either — Zapier is simpler

When onboarding a new customer, ask them what’s already configured in Zapier so the partner integration doesn’t duplicate it.

Pattern: hand off complexity to the partner integration

For workflows that start in Zapier but exceed its capabilities, the partner integration can serve as a downstream destination: The customer builds a Zapier workflow that POSTs to a partner-exposed endpoint when something happens. The partner endpoint runs the complex logic that Zapier can’t. This pattern is useful when:

The customer wants the workflow ownership in Zapier (where they can modify it) but needs the partner’s processing capabilities.
The trigger comes from a non-Raise source (e.g., a row added to a spreadsheet) and the partner integration provides the Raise-side action.

What the customer sees in Zapier

For partner integrations supporting customers using Zapier, it helps to know what the customer’s Zapier experience looks like:

Available triggers (from Raise)

The exact list of triggers exposed by the connector depends on the connector’s version, but typically maps to the Raise event types — new gift, new recurring gift, donor created, donor updated, etc. Each trigger gives the customer access to fields from the resulting Raise record (donor name, amount, project, campaign, etc.).

Available actions (against Raise)

The connector exposes a small set of read actions — typically “find a donor by email” and similar lookups. Write actions (like submitting a donation) are less common in Zapier connectors; the customer-facing donation form is the canonical write path.

Sample data

The GET /api/Zapier/samples/{eventType} endpoint returns recent Raise records that Zapier uses to populate the workflow builder. When the customer is configuring a trigger and selects “New gift,” they see real (anonymized or sample) gift data to map fields from.

When customers ask about Zapier

A few common situations partner integration teams encounter:

“Why isn’t my Zapier workflow firing?”

Common causes:

The Zapier workflow is paused (in Zapier’s UI).
The Raise event isn’t firing (check via webhook log endpoints — the same logs that show partner deliveries also show Zapier deliveries).
The connector’s webhook subscription was deleted (run GET /api/Webhook/list to see if a Zapier-managed subscription is still listed).
Zapier’s task quota is exhausted (Zapier’s pricing tier limits).

For partner integrations with customer-support responsibilities, the first investigation step is checking whether the underlying event fired in Raise. If yes, the issue is in Zapier; if no, the issue is in Raise (or in the source data).

”Can I use Zapier for X?”

A useful framework when a customer asks:

Question	If yes → Zapier likely	If no → Partner integration
Is the destination a common SaaS tool with a Zapier connector?	Yes	No
Can the workflow be expressed as a linear sequence of steps?	Yes	No
Is the volume reasonable (under a few thousand events per month)?	Yes	No
Can the customer’s team maintain the workflow themselves?	Yes	No
Does the workflow need to display data inside the partner’s product?	No	Yes

A customer who answers “yes” to all four is a good Zapier candidate. A customer who answers “no” to several should likely use a partner integration for those workflows. Typically no — the two can coexist. The partner integration should clearly communicate which workflows it handles so the customer knows what to leave in Zapier and what to migrate over. A reasonable migration framework:

Audit the customer’s existing Zapier workflows during partner onboarding.
Identify which ones the partner integration will replace (typically thank-you emails, major-gift alerts, CRM sync).
Identify which ones should stay in Zapier (spreadsheet logging, simple cross-tool routing).
Help the customer disable the ones the partner integration replaces to avoid duplication.

Custom integrations that work alongside Zapier

For partner integrations that explicitly want to work with customers using Zapier, two design patterns help:

Pattern: be Zapier-aware in onboarding

During customer onboarding, ask:

“Do you currently use Zapier with Raise?”
“What workflows do you have configured?”
“Are any of those workflows things you’d want our integration to take over?”

The answers shape the partner integration’s setup. If the customer already has thank-you emails in Zapier, the partner’s email setup is replacing that — make sure the customer disables the Zapier version. If the customer has spreadsheet logging in Zapier, leave it alone.

Pattern: expose partner APIs that Zapier can call

For partner integrations that want to be a destination in customer-built Zapier workflows, expose stable HTTP endpoints that Zapier can POST to:

JavaScript

// Partner integration exposes a "log a donation" endpoint
app.post('/api/v1/customers/:customerId/donations', async (req, res) => {
  const { customerId } = req.params;
  const { amount, donorEmail, source, ...rest } = req.body;

  // Validate the payload
  if (!amount || !donorEmail) {
    return res.status(400).json({ error: 'amount and donorEmail required' });
  }

  // Process and store
  await partnerDb.donations.create({
    customerId,
    amount,
    donorEmail,
    source: source ?? 'zapier',
    ...rest,
  });

  res.status(200).json({ success: true });
});

The customer can then build a Zapier workflow:

Trigger: New Gift in Raise → Action: POST to partner API → Action: Log to spreadsheet

Now the partner integration is a Lego brick in the customer’s Zapier toolkit, not a replacement for it.

What partner integrations should not do

A few patterns that look attractive but cause issues:

Anti-pattern	Why it’s bad
Call `POST /api/Zapier/subscribe` from a partner integration	These endpoints are for the Zapier connector’s internal use. Use `POST /api/Webhook` instead.
Try to read Zapier-managed webhook subscriptions and modify them	Same — Zapier owns its subscriptions. The partner shouldn’t touch them.
Compete head-on with Zapier for simple workflows	Zapier is genuinely good for simple workflows. Differentiate on the workflows it can’t do, not on duplicating what it can.
Hide Zapier from the customer	Customers benefit from knowing both options exist. Be honest about when each is right.

The general principle: complement Zapier, don’t replicate it. Build the workflows that exceed Zapier’s capabilities; let Zapier handle the simple cross-tool routing.

Where to go next

Sync Raise Gifts to an External System

The partner-integration alternative to Zapier-based sync — for workflows that exceed Zapier’s capabilities.

Webhooks Overview

The general webhook surface that partner integrations use (instead of the Zapier-specific endpoints).

Post-Donation Thank-You Flows

The thank-you flow recipe — typically a partner-integration replacement for Zapier-based thank-you workflows.

Embed a Form on a Website

The foundational integration recipe that this Zapier-coexistence guidance fits around.

​What the Raise–Zapier connector is

​How the connector works under the hood

​When Zapier is the right answer

​Coexistence patterns: when both exist

​Pattern: complementary triggers

​Pattern: clear ownership boundaries

​Pattern: hand off complexity to the partner integration

​What the customer sees in Zapier

​Available triggers (from Raise)

​Available actions (against Raise)

​Sample data

​When customers ask about Zapier

​“Why isn’t my Zapier workflow firing?”

​”Can I use Zapier for X?”

​”Should I disable my Zapier integration when I sign up for your partner integration?”

​Custom integrations that work alongside Zapier

​Pattern: be Zapier-aware in onboarding

​Pattern: expose partner APIs that Zapier can call

​What partner integrations should not do

​Where to go next