recurringGiftId.
This page covers the RecurringGift resource shape, the relationship between the schedule and the Gifts it produces, the lifecycle states the schedule moves through, and the operations partner integrations use most: updates, cancellations, and activity inspection.
The RecurringGift record
The RecurringGift record is one of the richest in the Raise API — over 50 fields covering identity, schedule, payment method, status, and processing history.Schedule and amount
| Field | Type | Description |
|---|---|---|
id | integer | The Raise primary key for this schedule. Immutable. |
amount | number | The per-payment amount. |
currencyCode | string | The currency for the schedule. |
formattedAmount | string | The per-payment amount pre-formatted for display. |
frequency | integer enum | How often the schedule runs (monthly, quarterly, yearly, etc.). |
formattedFrequency | string | The frequency display string. |
startDate | string | When the schedule began. |
startDateFormatted | string | Formatted start date for display. |
nextChargeDate | string | The next scheduled charge date. |
nextChargeDateFormatted | string | Pre-formatted next charge date. |
successfulCycles | integer | The count of successfully-processed payments so far. |
total | number | The total committed amount for a finite-duration schedule (when applicable). |
formattedTotal | string | Formatted total amount. |
frequency is an integer enum (the spec shows the type as a $ref to a Frequency enum without documented label-to-integer mappings). Use formattedFrequency for display. For programmatic logic, discover the integer-to-label mapping through the live API or coordinate with the platform team before relying on specific integer values.⚠️ Spec gap: RecurringGift frequency enum values are not documented in the spec. Same applies to status (see below). Future spec updates are expected to label these.Status and processing health
| Field | Type | Description |
|---|---|---|
status | integer enum | Current lifecycle status (active, cancelled, etc.). |
statusText | string | Display string for the status. |
hasPaymentFailed | boolean | true if the most recent payment attempt failed. |
isLegacy | boolean | true if the schedule was created in a legacy system. |
isAnonymous | boolean | true if the donor chose to remain anonymous. |
isTestMode | boolean | true for schedules in test mode. |
hasPaymentFailed flag is one of the most important fields for stewardship integrations. When true, the schedule has not been able to charge the donor’s payment method — typically because the card expired, was reissued, or had insufficient funds. The customer’s team needs to reach out to the donor to update payment info before the schedule can resume.
Donor and linkage
| Field | Type | Description |
|---|---|---|
donor | DonorModel | Embedded donor data. |
crmKey | string | The schedule’s primary key in the external CRM (e.g., CRM+). |
crmKeyUrls | object | CRM URLs by integration type. |
organizationId | integer | The Raise organization ID. |
profileNumber | string | A donor-facing identifier for the schedule. |
Designation
| Field | Type | Description |
|---|---|---|
projectAllocation | array of RecurringGiftProjectAllocationModel | The breakdown of each recurring payment across Projects. Same model as a Gift’s projects[] allocation. |
premium | object | The Premium associated with the schedule (one-time premium given at signup). |
recurringPremium | object | A Premium given on each recurring payment (when applicable). |
tribute | object | Tribute or memorial information. |
motivationCode, motivationCodeId, motivationCodeGroupId | various | Attribution codes. |
segmentId, segmentName, segmentCode | various | Segment attribution. |
sourceCode | string | Source code attribution. |
Payment method
| Field | Type | Description |
|---|---|---|
paymentMethodId | string | The tokenized payment method. |
paymentInfo | string | Display string summarizing the payment method (e.g., “Visa ending in 4242”). |
cardBrand | string | The credit card brand, when applicable. |
expMonthAndYear | string | The card’s expiration. |
paymentMethodCountryCode | string | The country code of the payment method. |
paymentProviderType | enum | The payment provider type. |
paymentTenderType | enum | The payment tender type. |
gatewayId | integer | The payment gateway. |
gateway | string | The gateway display name. |
gatewayCustomerKey | string | The gateway’s identifier for the customer. |
merchantType | enum | The merchant type. |
merchantAccount | string | The merchant account identifier. |
tokenizationKey | string | The tokenization key. |
expMonthAndYear) and proactively contact donors to update their cards before the schedule fails.
Costs and currency
| Field | Type | Description |
|---|---|---|
donorCoverCosts | boolean | true if the donor opted to cover processing fees. |
costs | number | The processing fee amount the donor is covering. |
baseCurrencyCode | string | The base currency code (when different from currencyCode). |
currencyExchange | object | Currency exchange information. |
Audit and other
| Field | Type | Description |
|---|---|---|
createdDate | string | When the schedule was created. |
modifiedDate | string | When the schedule was last changed. |
notes | string | Internal notes. |
comments | string | Donor-provided comment. |
page | object | The donation page the schedule was created through. |
How RecurringGifts produce Gifts
The RecurringGift schedule is the durable schedule record. The actual Gifts the schedule produces are separate records — see Gifts. The data flow on each payment cycle: Two patterns this implies for partner integrations:- Each recurring payment is a separate Gift. Subscribing to
giftCreatewebhooks captures recurring payments alongside one-time donations. Distinguish them by checkinggift.recurringGiftId— if non-null, the gift came from a schedule. - Schedule state changes are visible on the RecurringGift record, not via dedicated events. When a schedule’s
nextChargeDateadvances orsuccessfulCyclesincrements, the RecurringGift record changes — partner integrations that need to track schedule state pull the record on a cadence rather than rely on an event.
Reading RecurringGifts
| Pattern | Endpoint | Use |
|---|---|---|
| List all | GET /api/RecurringGift/list | Paginated list of all schedules |
| Query by filter | POST /api/RecurringGift/query | Advanced filtering — see Pagination and Filtering |
| Get by ID | GET /api/RecurringGift/{id} | Single schedule with full detail |
cURL
donorId filter.
Reading the activity (payment) history
cURL
Creating RecurringGifts
The Raise API doesn’t expose a dedicatedPOST /api/RecurringGift create endpoint. RecurringGifts are created in one of two ways:
| Source | Path |
|---|---|
| Donor opts into recurring giving on a donation form | POST /api/Raise/give with isRecurring: true and frequency set |
| Manual entry | Through the Raise admin UI |
POST /api/Raise/give with the recurring fields set:
cURL
nextChargeDate advances to the next interval after the first payment.
The
frequency integer value needed for the request is not documented in the spec. Confirm the integer-to-frequency mapping (monthly = 1, quarterly = 2, etc.) before relying on it in production.Updating a RecurringGift
PUT /api/RecurringGift/{id} updates an existing schedule. Common updates partner integrations make:
| Change | Fields to update |
|---|---|
| Donor changes the recurring amount | amount, projectAllocation (must sum to the new amount) |
| Donor changes the frequency | frequency, nextChargeDate |
| Donor updates payment method | paymentMethodId (plus card-specific fields) |
| Donor changes the designation | projectAllocation |
| Customer’s team adds an internal note | notes |
JavaScript
Cancelling a RecurringGift
Cancellation has a dedicated endpoint — don’t try to cancel by settingstatus directly via PUT:
cURL
nextChargeDate no longer triggers payment processing. Whether the schedule can be reactivated depends on the platform’s lifecycle rules — confirm with the platform team before designing any “resume cancelled schedule” workflow.
Detecting payment failures
Schedules withhasPaymentFailed: true are the most actionable signal for stewardship integrations. Query for them on a regular cadence:
JavaScript
POST /api/Donor/{donorId}/generate-page — see Donation Forms) is the typical mechanism for delivering an update-payment URL.
Detecting upcoming card expirations
Another high-value stewardship signal: schedules with payment methods that will expire soon. TheexpMonthAndYear field on each RecurringGift indicates the card expiration.
JavaScript
The exact format of
expMonthAndYear (e.g., MM/YYYY, MM/YY, or another shape) is not documented in the spec. Confirm the format against live data before parsing.Where to go next
Gifts
The Gift records that recurring schedules produce on each cycle.
Configure a Recurring Gift
The workflow for setting up a recurring schedule.
Donors
The donor records that schedules belong to, including the transfer-recurring-gift operation.
Statuses and Lifecycle States
The full lifecycle catalog including RecurringGift status values.