Improved: Endpoint-specific error documentation
Every error response in the Raise API reference now says what it means for that endpoint, instead of just Bad Request or Not Found.
400 responses name the likely cause — the 116 documented 400 responses now describe what that endpoint rejects: which query parameter was at fault on a list endpoint, which fields the errors map covers on a create or update, and which IDs must be present and distinct on Merge Donors, Transfer a Donor Gift, and the campaign, segment, and project replace endpoints.- They say what happened to your data — a
400 on a write means nothing was persisted, so Update a Campaign leaves the stored campaign untouched, a refused refund leaves the gift unchanged, and a refused transfer leaves the gift with its current donor.
400 versus 404 where both apply — on Cancel a Recurring Gift, 400 means the schedule exists but isn’t cancellable (including one that’s already cancelled) and 404 means the ID doesn’t resolve. On the nested donor resources, 404 also covers a child record that belongs to a different donor.401 is now documented on all 145 endpoints — every Raise endpoint requires Bearer authentication, but none of them declared the 401 it returns when the header is missing or the token is expired or revoked. Each one now documents it with the ProblemDetails body.- Endpoints with no documented errors are flagged —
Process a Donation Payment, Capture a Lead, the seven Query endpoints, and five others carry a note saying the spec doesn’t enumerate their failure cases, rather than implying they can’t fail.
403, 429, and 500 are still not documented per-endpoint because the spec doesn’t confirm their behavior — Error Handling covers handling them defensively. No paths, schemas, or fields changed.Improved: Realistic response examples across the API
Every endpoint that returns a body now shows a filled-in example response instead of <string> and 0 placeholders — 112 success responses, plus a worked error example on the 116 endpoints that document a 400 and the 27 that document a 404.
- One example world — the examples all come from the same fictional nonprofit, Riverside Hope Foundation, and the same donors. Marcus Castellano is donor
200234 in Get a Donor, the donor on gift 602198 in Get a Gift, and the top donor of the YE25-EMAIL segment in List Segment Donors. Priya Sharma’s $50 monthly schedule is recurring gift 700089, the gift it generated on November 15 is 602401, and the two line up in List Recurring Gift Activities.
- The shapes partners actually handle —
List All Gifts shows a recurring instance, an anonymous online gift, and a major gift in one page; List All Donors shows an individual, a monthly donor, and an organization; Cancel a Recurring Gift shows the cancelled schedule the call leaves behind.
- Endpoint-specific examples —
List Donor Phone Numbers shows phone numbers and List Donor Email Addresses shows email addresses, the donor-scoped lists show one donor’s gifts and schedules rather than the organization-wide set, and the campaign, motivation, and segment statistics endpoints each show their own kind of totals.
- Errors —
400 responses show the errors map with field-level messages for that endpoint, and 404 responses name the record that wasn’t found. Both use the ProblemDetails envelope described in Error Handling.
- Safe sample data — all names,
@example.org addresses, and 555-01XX phone numbers are reserved for documentation, and every date is anchored to a single point in time so the totals and histories agree with each other.
Where an integer enum such as status, frequency, or type still has no published labels, the examples show the accompanying display field — statusText, formattedFrequency, typeDisplay — rather than guess at a value. See Statuses and Lifecycle States.No paths, schemas, fields, or behavior changed — this only affects the examples shown in the docs.Improved: Described parameters and request and response fields
Every parameter in the Raise API reference now has a description, and the fields you send and read are described in the language of the product rather than the source code.
- Paging and filtering —
skip, take, sortBy, descending, filter, and includeDetails were blank on 27 list endpoints and now read the same everywhere. Each filter says what it searches, and includeDetails says what it adds — the segments, pages, and page statistics on List All Campaigns, the addresses and contact methods on List All Donors, the donor, gateway, and segment on List All Gifts.
- Path parameters — the 21
{id} parameters that showed nothing now say which record they identify, including the donor an address, contact method, email, or phone belongs to.
- Payments — the eight query parameters on
Calculate Payment Processing Cost are described, and every field of the Process a Donation Payment body is too: nonce versus paymentMethodId, the recurring fields (isRecurring, frequency, startDate, timeZone), the fee-covering fields (donorPaidCosts, coverAdminFee, adminFee), and the tribute and project blocks.
- List responses —
items and total are described on every paged response, including how to use total with skip and take to page through the full set.
- Errors — the
type, title, status, detail, and instance fields of the error response returned across the API are now described.
- Newly described areas — motivation codes and groups, knowledge sources, tributes, page design settings, currency exchange, campaign goals, premiums, projects, segments, and saved queries.
- Wording — about 700 field descriptions that started with the source code’s “Gets or sets the…” now read as plain statements, and the ones that said only “the identifier” or “a value indicating whether organization” now say what they mean.
Paths, fields, and operations are unchanged — this only affects the descriptions shown in the docs.Improved: Consistent endpoint names and cleaned-up wording
Endpoint names across the Raise API reference now follow a consistent verb + concise object pattern, and the wording carried over from the source code has been cleaned up.
- Names that collided or read vaguely are now specific: the two donor activity endpoints are
List Donor Activities (organization-wide) and List Activities for a Donor, the two log endpoints are List All Webhook Logs and List Logs for a Webhook, and Look Up Query Parameter Options is now Get Query Parameter Values, which is what it returns.
Check if Segment Exists is now Check if Segment Code Exists, matching the project code endpoint and the code it checks.- Run-together words from the source code’s comments are fixed throughout the field descriptions —
crmkey, customfield name, entitytypedisplay name, pay load, java script version, tributefirst name, and about 30 more.
- Descriptions that trailed off mid-sentence now say what the field means — for example,
isValid on a donor contact method and canSync on a campaign, and the supports java applets and [active] flags.
- Schema summaries built from class names now read as English (“Represents a gift transfer request.” instead of “Represents a transfergift request.”), leftover .NET member names are replaced with the JSON field they refer to, and parameter descriptions have consistent sentence punctuation.
Paths, fields, and operations are unchanged — this only affects the names and descriptions shown in the docs.Improved: Endpoint summaries and descriptions
Every endpoint in the Raise API reference now has a summary and a description explaining what it does — 139 endpoints that previously showed nothing beyond their name, 8 that were unlabeled entirely, and a few whose copy was a leftover developer note.
- What each endpoint does — each description is a one-line statement of what the call returns or changes. The detail that used to be missing entirely — the fields you most often need to send, what a flag such as
includeDetails adds, and the related endpoint to use when there is a better one for the job (Delete a Gift to Refund a Gift, Delete a Premium to Deactivate a Premium, Search Donors to Query Donors) — now appears above the reference on the endpoint page.
- Callouts — the things worth pausing on are flagged: an
Info for the paging, filtering, and “use this other endpoint” pointers, and a Note for the ones that cost you if you miss them — Delete a Gift not refunding the donor, PUT replacing the values you leave out, includeDetails slowing large result sets, and checking a dependency count before a delete.
- Named endpoints —
List All Donors, List All Gifts, List Donor Custom Field Responses, Search Email Lists, Capture a Lead, and the motivation code and motivation code group endpoints are no longer unlabeled in the reference.
- Queries — every
Query endpoint points to Get Query Options for the parameters, operators, and result fields its query type supports, and explains what includeDetails adds to the response.
- Placeholder copy removed —
Query Campaigns no longer shows raw <list> markup and internal class names, and the Update a Donor and Partially Update a Donor descriptions now read like the rest of the reference.
These are documentation-only changes — no paths, schemas, fields, or behavior changed.New: Raise API Documentation Changelog
We’ve launched the Raise API Documentation Changelog to help developers and partners stay up to date on changes to the Raise API and related documentation.This changelog will include updates such as:
- New and updated Raise API endpoints
- Donation, campaign, transaction, and supporter data updates
- Request and response schema changes
- New fields, objects, filters, and parameters
- Deprecation notices and breaking changes
- Improvements to examples, guides, recipes, and API reference documentation
Last modified on July 28, 2026
