> ## Documentation Index
> Fetch the complete documentation index at: https://docs.virtuous.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Zapier Trigger Patterns

> How the Raise–Zapier connector enables customer-facing automation, what it does and doesn't replace for partner integrations, and the patterns for coexistence.

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                 |

<Warning>
  **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](/raise/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.
</Warning>

***

## 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).

```mermaid theme={null}
graph LR
  Raise["Raise<br/>(giftCreate event)"]
  Partner["Partner integration<br/>(thank-you email,<br/>major-gift alerts)"]
  Zapier["Zapier<br/>(Slack post,<br/>Sheets append)"]

  Raise -->|webhook| Partner
  Raise -->|webhook via Zapier connector| Zapier
```

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:

```mermaid theme={null}
graph LR
  Raise["Raise"]
  Zapier["Zapier<br/>(simple workflows)"]
  PartnerWebhook["Partner webhook<br/>(complex processing)"]
  CustomLogic["Custom business<br/>logic"]

  Raise -->|trigger| Zapier
  Zapier -->|POST to partner API| PartnerWebhook
  PartnerWebhook --> CustomLogic
```

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.

### "Should I disable my Zapier integration when I sign up for your partner integration?"

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:

1. **Audit the customer's existing Zapier workflows** during partner onboarding.
2. **Identify which ones the partner integration will replace** (typically thank-you emails, major-gift alerts, CRM sync).
3. **Identify which ones should stay in Zapier** (spreadsheet logging, simple cross-tool routing).
4. **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 JavaScript theme={null}
// 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

<CardGroup cols={2}>
  <Card title="Sync Raise Gifts to an External System" icon="arrows-rotate" href="/raise/recipes/sync-raise-gifts-to-an-external-system">
    The partner-integration alternative to Zapier-based sync — for workflows that exceed Zapier's capabilities.
  </Card>

  <Card title="Webhooks Overview" icon="webhook" href="/raise/webhooks/overview">
    The general webhook surface that partner integrations use (instead of the Zapier-specific endpoints).
  </Card>

  <Card title="Post-Donation Thank-You Flows" icon="envelope-open-text" href="/raise/recipes/post-donation-thank-you-flows">
    The thank-you flow recipe — typically a partner-integration replacement for Zapier-based thank-you workflows.
  </Card>

  <Card title="Embed a Form on a Website" icon="globe" href="/raise/recipes/embed-a-form-on-a-website">
    The foundational integration recipe that this Zapier-coexistence guidance fits around.
  </Card>
</CardGroup>