> ## Documentation Index
> Fetch the complete documentation index at: https://docs.virtuous.org/llms.txt
> Use this file to discover all available pages before exploring further.
# Raise Changelog
## 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](/raise/error-handling#status-codes-that-occur-but-arent-in-the-spec) 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 `` 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](/raise/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](/raise/concepts/statuses-and-lifecycle).
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 `` 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