The Raise Data Model

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.

​

The resources

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.

​

Donor-side records

​

Gift-side records

​

Campaign and form configuration

​

Relationships at a glance

The most important relationships:

• 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 $500 gift split evenly between two Projects has two allocations of$250 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 data flow

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.

​

Gift creation paths

To be explicit about how Gifts come into existence in Raise — because this is one of the most distinctive aspects of 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.

​

Identifiers used throughout the API

Several identifier types appear across the resources. Knowing what they mean helps when reading payloads: 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.

​

Lifecycle states across resources

Some resources have meaningful lifecycle states. The ones partner integrations encounter most: 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.

​

Test mode

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.

​

Where to go next