The resources Raise exposes, how they relate to each other, and how data flows from a donation event through the API to downstream products.
This page is the reference for how data is organized in Raise. The resources, their relationships, and the flow of a donation from form submission through Gift record creation are covered here. Later concept pages drill into specific resources; this page is the map.
Raise exposes 15 resource families through the API. The ones partners interact with most often are organized into three layers — donor-side records, gift-side records, and the configuration that ties them to fundraising campaigns.
A Donor is the parent of everything donation-related. Every Gift belongs to exactly one Donor.
A RecurringGift is a schedule, not a payment. It produces Gifts over time; each generated Gift has a recurringGiftId pointing back to the schedule.
A Gift designates to one or more Projects via GiftProjectAllocations. A 500giftsplitevenlybetweentwoProjectshastwoallocationsof250 each. Single-Project gifts have one allocation for the full amount.
A Gift originated from a Donation Form, which lives under a Segment, which lives under a Campaign. This lets the customer trace any Gift back to the channel and campaign that produced it.
The most common partner-relevant flow is what happens when a donor completes a donation through a form:A few things to call out about this flow:
POST /api/Raise/give is the single entry point for new gifts. There is no POST /api/Gift — the only way to create a Gift record in Raise is via the /api/Raise/give donation submission path.
Donor matching is automatic. The endpoint matches the incoming donor information against existing Donor records (typically by email) and creates a new Donor only if no match is found.
The webhook fires immediately on Gift creation, not after the platform-level sync. Partners that subscribe to webhook events see gift activity in real-time.
The sync to CRM+ is a platform behavior, not an API action. Your Raise integration doesn’t call CRM+ directly. See How Raise Data Flows to CRM+ for details.
To be explicit about how Gifts come into existence in Raise — because this is one of the most distinctive aspects of the API:
Source
Endpoint or trigger
Donation through a Raise-hosted form
POST /api/Raise/give (called by the form on submit)
Donation through an embedded or custom form
POST /api/Raise/give (called directly by the partner integration)
Recurring gift payment processing
Automatic — Raise’s payment processor charges on schedule and creates the Gift
Manual entry by a customer’s staff
Through the Raise admin UI, not the API
Import from another system
Through a customer’s data import process (admin UI), not the API
There is no API endpoint for manually creating a Gift outside of POST /api/Raise/give. Integrations that need to record historical or back-dated gifts coordinate that through the customer’s admin team using the platform’s import tools.
Several identifier types appear across the resources. Knowing what they mean helps when reading payloads:
Identifier
What it identifies
Where it appears
id (Donor)
The internal Raise primary key for a Donor
Donor.id, Gift.donorId, RecurringGift.donorId
id (Gift)
The internal Raise primary key for a Gift
Gift.id, return value from POST /api/Raise/give
id (RecurringGift)
The internal Raise primary key for a recurring gift schedule
RecurringGift.id, Gift.recurringGiftId
crmKey
The donor’s primary key in an external CRM (typically CRM+)
Donor.crmKey
crmSecondKey
A secondary CRM identifier
Donor.crmSecondKey
transactionId
The payment processor’s transaction reference
Gift.transactionId
authorizationNumber
The payment gateway authorization number
Gift.authorizationNumber
donationId
An additional donation identifier (typically used for the donation flow’s session)
Gift.donationId
paymentMethodId
The tokenized payment method
Request body on POST /api/Raise/give
The crmKey fields are the linkage point between Raise records and CRM+ records when a customer runs both products. The platform sync uses these to keep the two systems aligned.
The Gift.status is an integer enum without documented labels in the spec — the statusText field provides the human-readable display version. Partner integrations should rely on statusText for display and on the documented status enum once published. See Statuses and Lifecycle States for the catalog.
Raise resources carry an isTestMode flag throughout — on Donors, Gifts, and the donation submission request itself. Donations submitted with isTestMode: true do not charge real payment methods and the resulting records are flagged as test data.The flag is set per-record, not per-organization — meaning the same organization can carry both real and test records. Filtering by isTestMode is a common reporting pattern to exclude development activity from production metrics.See Base URLs and Environments — Working against production with care for the broader pattern.
