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 onCampaignModel give you everything you need in a single call per campaign:
JavaScript
Creating and updating Campaigns
Create
cURL
id.
Update
PUT /api/Campaign/{id} updates an existing campaign. Send the full record:
cURL
Delete
cURL
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
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.
Replace
PUT /api/Campaign/replace migrates dependencies (Segments, Forms, Gifts) from one campaign to another:
cURL
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
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
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
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.