The Gift resource in Raise — the donation submission path through /api/Raise/give, the read-and-refund endpoint set, and the relationships to Donors, Projects, and recurring schedules.
A Gift in Raise is a single completed donation. It carries the donation amount, payment processor result, status, project allocations, optional premium and tribute, and references to the donor and (if applicable) the recurring gift schedule that produced it.The most distinctive aspect of the Gift resource: Gifts are not created via POST /api/Gift. The Gift POST and PUT endpoints don’t exist. Donations enter Raise exclusively through the POST /api/Raise/give donation submission path, which processes payment and then creates the Gift record. This page covers both the resource shape and the unique creation flow.
The Gift record has 56 fields covering identity, payment, designation, status, and a number of optional attribution and analytics fields. The most important groups:
true if the Gift is eligible for refund through the API.
isAnonymous
boolean
true if the donor opted to give anonymously.
isTestMode
boolean
true if the Gift was created in test mode.
status is an integer enum, but the Raise OpenAPI spec doesn’t document the mapping of integer values to status labels. Use statusText for display purposes; for programmatic logic, discover the status enum’s meanings against the live API and store the mapping in your integration.⚠️ Spec gap: Gift status enum values are not documented in the spec. Future spec updates are expected to label these. Until then, partners should rely on statusText and not switch on the integer status directly.
Google UTM tracking parameters captured at the time of donation.
googleGclid
string
Google Click Identifier — connects a gift back to a specific ad click.
submissionUrl
string
The URL of the page the donor was on when they submitted.
browserInfo
object
Browser fingerprint information captured during submission.
UTM and Google Click ID tracking is useful for closing the loop on paid acquisition campaigns — partners building donation-attribution analytics use these fields to attribute gifts back to the marketing channel that drove them.
This is the most distinctive aspect of the Raise Gift surface. There is no POST /api/Gift. Every Gift record in Raise originates from a donation submission through POST /api/Raise/give.
POST /api/Raise/give isn’t a plain “create a Gift” endpoint — it’s the full donation flow:
Processes the payment through the configured payment gateway using the tokenized paymentMethodId.
Creates or matches the Donor record from the embedded donor information.
Creates the Gift record with the payment result.
Fires the webhook notifying subscribers of the new Gift.
Initiates platform-level sync to downstream products like CRM+.
Each of these steps is tightly coupled — you can’t create a Gift record without payment processing because the gateway response data is part of the record. This is why the spec exposes no general Gift POST.
The donor-matching algorithm processes the embedded donor block — typically by email — and either creates a new Donor or attaches the Gift to an existing one. See Process a Donation for the end-to-end workflow including donor matching detail and error handling.
The paymentMethodId must be a tokenized payment method, not a raw card number. Raise uses tokenization to keep partner integrations out of PCI scope. For development and testing, use POST /api/Raise/generate-test-payment-method to mint a test token without touching real card data.
The Gift resource exposes read endpoints in three patterns:
Pattern
Endpoint
Use
List all
GET /api/Gift/list
Paginated list of all Gifts. Supports the standard /list parameters.
Query by structured filter
POST /api/Gift/query
Advanced filtering via groups[]/conditions[].
Get by ID
GET /api/Gift/{id}
A single Gift with full detail.
For reading Gifts associated with a specific Donor, prefer the GET /api/Donor/{donorId}/gifts endpoint — it’s filtered to the donor at the source rather than requiring you to query by donorId.
A refund initiates the reverse payment flow with the original gateway, returns the funds to the donor’s payment method, and marks the Gift as refunded on the Raise side. The canRefund flag on the Gift indicates eligibility — typically false for Gifts that have already been refunded, settled past the gateway’s refund window, or have other constraints.Partial refunds (refunding less than the full Gift amount) may be supported depending on the gateway. Confirm with the customer’s gateway configuration before relying on partial refund behavior.
DELETE /api/Gift/{id} removes a Gift record entirely. Use sparingly — deletion erases the gift’s history and accounting impact. The refund endpoint is the right choice for most “cancel this donation” scenarios because it preserves the audit trail.Deletion is most appropriate for:
Test gifts created during development that need cleanup.
Genuine data-entry errors caught before any downstream system has acknowledged the gift.
For donations that were successfully processed but need to be reversed, refund instead.
Gift notes have a dedicated update endpoint, parallel to the Donor notes pattern:
cURL
curl -X PUT https://prod-api.raisedonors.com/api/Gift/9876/notes \ -H "Authorization: Bearer YOUR_API_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "notes": "Acknowledged via thank-you email on 2025-01-15" }'
This is the only field-level update available on a Gift through the API. Other field changes (amount corrections, designation reallocations, gateway adjustments) are not exposed as API operations and must be performed by the customer’s staff in the Raise admin UI.
To recap the complete creation flow, since this is one of the most-asked questions for partners new to Raise:
Scenario
Path
Donor completes a Raise-hosted donation form
The form’s submit handler calls POST /api/Raise/give
Partner integration embeds a donation form on its own site
The integration code calls POST /api/Raise/give
Recurring schedule processes a scheduled payment
Raise’s payment processor creates the Gift automatically — no API call needed from your side
Customer’s staff manually records a gift
Through the Raise admin UI, not the API
Customer imports historical gifts
Through Raise’s bulk import tools in the admin UI
There is no API path for partners to create Gifts that bypass POST /api/Raise/give. Integration designs that need “create a Gift record without processing a payment” should route through the customer’s admin team using import tools rather than the API.
