Skip to main content
A Campaign in Raise is a top-level fundraising effort — an annual appeal, a capital campaign, a specific initiative. It owns the Segments and Forms that produce donations and tracks aggregate metrics like total raised, donor count, and conversion rate against configured goals. Unlike the donation submission and form-management surfaces, the Campaign resource has full CRUD plus several specialized operations. Partner integrations that need to read or manage Campaign-level data have a solid endpoint surface to work with.

The Campaign record

Sync configuration

The canSync flag is particularly important for customers running CRM+ alongside Raise — it controls whether the campaign and its gifts surface in CRM+ at all. See How Raise Data Flows to CRM+ for details.

Goal tracking

The goal tracking is comprehensive — partner integrations doing campaign-progress reporting have direct access to the same metrics the customer sees in the Raise admin UI without needing to compute them client-side.

Reading Campaigns

The list endpoint uses the standard Filter, Skip, Take, SortBy, Descending, IncludeDetails parameters described in Pagination and Filtering.

Reading campaigns for analytics

For partner integrations building campaign-progress dashboards, the goal-tracking fields on CampaignModel give you everything you need in a single call per campaign:
JavaScript
No need to query Gifts and aggregate them yourself — the campaign record carries the rollup.

Creating and updating Campaigns

Create

cURL
A successful create returns the new Campaign record with its assigned id.

Update

PUT /api/Campaign/{id} updates an existing campaign. Send the full record:
cURL
The PUT semantics are documented as full-replace — send every field you want to retain. Unlike the Donor endpoint, the Campaign endpoint doesn’t expose a PATCH variant in the spec, so partial-update workflows need to GET-then-PUT.

Delete

cURL
Deleting a Campaign that has dependent Segments, Forms, or Gifts may be blocked by referential integrity. Use the dependency-count endpoint to check before attempting deletion — see Checking dependencies below.

Special operations

Toggle sync

PUT /api/Campaign/{campaignId}/toggle-sync enables or disables the campaign’s CRM sync without requiring a full update:
cURL
This is the safer way to flip canSync because it’s a single-purpose operation — no risk of inadvertently changing other fields. Use it whenever the customer needs to pause or resume sync for a specific campaign. When sync is disabled (canSync: false):
  • New gifts created against this campaign continue to flow into Raise normally.
  • Those gifts do not propagate to CRM+ via the platform sync.
  • Existing gifts already synced to CRM+ remain there — toggle-sync doesn’t retroactively remove records.
When sync is re-enabled, the platform sync resumes for new gifts. Gifts that occurred during the disabled window are not automatically backfilled — coordinate with the customer’s admin team if backfill is needed.

Replace

PUT /api/Campaign/replace migrates dependencies (Segments, Forms, Gifts) from one campaign to another:
cURL
Useful for campaign restructuring — when the customer realizes mid-year that several Segments belong under a different Campaign than originally configured, replace moves them in a single atomic operation. After the replace completes, the source Campaign typically has no dependencies left and can be safely deleted.
Confirm the exact request body shape for PUT /api/Campaign/replace against the live API. The spec’s endpoint description says “Replace a campaign with another campaign for its dependencies” but the body structure for source/target identification isn’t detailed in the schema.

Checking dependencies

cURL
Returns counts of how many Segments, Forms, Gifts, and other resources depend on this Campaign. Use this before attempting deletion to avoid blocked-delete errors, and to surface a clear “this campaign has N gifts attached — are you sure you want to delete it?” warning in your integration’s UI.

Campaign lifecycle in practice

A typical Campaign goes through a small number of states over its lifetime: The Raise spec doesn’t expose a separate isArchived flag on Campaigns the way it does on Donors. Campaigns past their endDate continue to exist with their historical data; the customer chooses whether to delete them (via the API or admin UI) or leave them in place for historical reporting.

Common patterns

Campaign-by-name lookup

A frequent partner pattern: looking up a Campaign by name rather than ID. The Raise API doesn’t expose a dedicated lookup-by-name endpoint, but the Query endpoint handles it:
JavaScript
The integer operator value for “equals” needs to be discovered through GET /api/Query/options/{queryType} — see Pagination and Filtering: Discovering query options.

Active-campaigns cache

Most partner integrations need a current list of active campaigns. Cache the result at startup and refresh on a slow cadence:
JavaScript
A 1-hour TTL is reasonable for most integrations — Campaigns don’t change minute to minute.

Where to go next

Recurring Gifts

The other core resource — recurring donation schedules.

How Raise Data Flows to CRM+

The platform-level sync controlled by the canSync flag.

Donation Forms

The forms that sit under Campaigns and Segments.

Statuses and Lifecycle States

The lifecycle states that apply to Campaigns, Gifts, and RecurringGifts.
Last modified on May 20, 2026