> ## 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. # Overview > What the Raise API is, what partner integrations can build with it, and how Raise fits into the broader Virtuous platform. The Raise API powers donation-form-driven fundraising. Where CRM+ is the donor and gift system of record, Raise is the donation processing and form-management product — partners build against it when they need to capture donations through customizable forms, manage recurring giving schedules, or embed fundraising experiences inside another product. This page covers what Raise is, what you can build on it, and the conventions you'll see throughout the docs. ## What Raise is Raise is a donation-platform-as-a-service. Nonprofits configure Donation Forms in Raise — branded, customizable forms with their fields, designations, recurring options, and payment processing — and embed those forms on their websites, share them via email, or drive traffic to them through campaigns. When a donor completes a form, Raise processes the payment, creates the Donor and Gift records, and (in a Virtuous-platform customer's typical configuration) flows the gift data through to CRM+ for downstream stewardship. The API exposes the same surface partners need to integrate around this flow: | Resource family | What it does | | --------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | **Donation submissions** | The `POST /api/Raise/give` endpoint — the one path that creates gifts in Raise | | **Donors** | Donor records, contact details, address management, notes, archive, merge | | **Gifts** | Read, refund, and delete Gift records (Gifts are created via `POST /api/Raise/give`, not via a Gift POST) | | **Recurring Gifts** | Recurring donation schedules, payment history, cancellation | | **Campaigns** | Top-level fundraising campaigns that group forms and segments | | **Segments** | Sub-divisions of a campaign — typically one per donation form or appeal | | **Projects** | Funding destinations for Gift designations | | **Premiums, Motivation Codes, Custom Fields** | Configurable metadata Raise uses to track gift context | | **Webhooks** | Real-time event delivery for donations, recurring schedules, and form submissions | ## What you can build Three classes of integrations make up the bulk of Raise partner work: | Integration class | Examples | | --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Embedded donation experiences** | A nonprofit's website integrating Raise Donation Forms directly into the donor's flow; a giving widget for a partner application | | **Post-donation automation** | Webhook-driven flows that route donations to email platforms (welcome emails, thank-you sequences), accounting systems, donor analytics tools | | **Donor data sync** | One-way export of Raise donor and gift data into a third-party CRM, BI tool, or accounting platform | If your work involves donor stewardship workflows, multi-channel donor cultivation, or relationship management features that operate across communication and gift records, those are typically built against CRM+ — see [CRM+ Overview](/crm/overview). Raise's lane is the donation event itself and the form that produced it. ## How Raise fits with CRM+ For customers running both products, the data flow is one-directional: Raise gifts surface in CRM+ as Contact and Gift records through a platform-level sync that's outside the API surface of either product. Your Raise integration doesn't write to CRM+ directly, and your CRM+ integration doesn't write to Raise directly. Each product has its own API token, its own webhook subscriptions, and its own conventions. This has two implications for partners: * **Most integrations target one product, not both.** A payment-platform integration is a Raise integration. A donor-stewardship integration is a CRM+ integration. Partners that need both surfaces typically build two separate integrations against two separate APIs. * **Cross-product reconciliation is sometimes necessary.** If your integration writes Gifts via Raise and also reads them from CRM+ (for example, to surface them alongside other Contact history), expect a delay between the Raise write and the CRM+ visibility, and design reconciliation accordingly. A dedicated [How Raise Data Flows to CRM+](/raise/concepts/data-flow-to-crm) concept page covers this in more detail. ## Conventions you'll see throughout the docs A few Raise-specific conventions worth knowing upfront — partners coming from CRM+ will notice some differences: | Convention | Raise | CRM+ | | --------------------------- | --------------------------------------------------- | ---------------------------------------------------- | | API host | `https://prod-api.raisedonors.com` | `https://api.virtuoussoftware.com` | | Paginated response envelope | `{ items: [], total: 123 }` | `{ list: [], total: 123 }` | | Gift creation path | `POST /api/Raise/give` (no `POST /api/Gift`) | `POST /api/Gift` and `POST /api/v2/Gift/Transaction` | | Pagination parameter casing | `Skip`, `Take`, `SortBy`, `Descending` (PascalCase) | `skip`, `take`, `sortBy`, `descending` (camelCase) | | Custom-field surface | First-class resource with dedicated endpoints | Embedded in resource payloads | These differences are products of Raise's separate history and codebase. The platform team is working on a future v2 of all three APIs that will reconcile conventions; for now, treat each API's conventions as authoritative and don't carry assumptions from one to another. ## Where to go next Make your first successful API call against Raise in a few minutes. How to authenticate against the Raise API. The Raise API host, environment selection, and sandbox setup. A deeper look at how Donors, Gifts, Forms, and Campaigns relate.