Skip to main content
This page covers the Raise API host, the environment model, and the practical considerations for running an integration against real customer data versus test data.

​
The base URL

The Raise API is served from a single host: 
https://prod-api.raisedonors.com
Every endpoint in the spec is reached at this host. There is no per-customer subdomain, no regional variant, and no version segment in the path (e.g., no /v1/). The full URL for GET /api/Donor/list is: 
https://prod-api.raisedonors.com/api/Donor/list
Two things partners coming from CRM+ should note:
  • The host is different from CRM+‘s. CRM+ is served from api.virtuoussoftware.com; Raise is on its own host because it runs on a separate infrastructure (a product of Raise’s history as an acquired company). Tokens and endpoint paths are not interchangeable between the two.
  • The path is unversioned. Unlike CRM+‘s selective use of /api/v2/ for newer endpoint families, Raise paths are all under /api/ with no version segment. Future API versions may introduce a versioned prefix; for now, all production paths share the unversioned namespace.

​
TLS and HTTPS

All Raise API traffic must use HTTPS. The host does not accept plain HTTP, and TLS certificate validation is mandatory — clients that disable certificate verification will be considered insecure and may have requests rejected at the network layer. For HTTP clients, this typically means: use the default TLS configuration. Don’t disable certificate verification “for development” — use a tunneling or proxy tool that handles TLS correctly instead.

​
Environments

The current Raise API spec declares only the production environment. There is no documented staging URL, sandbox URL, or test-only environment in the OpenAPI spec itself. In practice, the platform supports two ways for partner integrations to develop and test safely:
MechanismPurpose
Test mode within a production organizationA flag on a Raise organization that processes donations in a test/sandbox mode without charging real payment methods. Used for development against an otherwise-live account.
Dedicated test API endpointsPOST /api/Raise/generate-test-payment-method returns a payment method usable for end-to-end test flows in test mode.
The exact mechanism for activating test mode on a Raise organization is a Raise admin UI concern, not an API concern, and it varies by the customer’s account configuration. Walk through it with the customer’s Raise administrator during integration onboarding.For partner integrations developing against the Raise API generally (before having a specific customer account), the partner team at Virtuous typically provisions a dedicated developer organization with test mode enabled. Contact your partner manager to arrange this — the process is handled outside the API.

​
Working against production with care

Without a dedicated staging environment in the API itself, partner integrations developing against Raise work against production hosts — with or without test-mode payment processing. A few practices help avoid mistakes:

​
Use a clearly-marked test organization

Whether through the partner-provisioned developer organization or a test-mode account at a customer’s organization, work against an account that is clearly identified as non-production. Most Raise admin UIs flag test organizations visibly so you don’t confuse them with real ones — confirm the indicator during setup.

​
Use the test payment method generator

POST /api/Raise/generate-test-payment-method returns a payment method that processes through Raise’s test rails without touching real card networks. Use it whenever you exercise the POST /api/Raise/give donation flow during development:
cURL
curl -X POST https://prod-api.raisedonors.com/api/Raise/generate-test-payment-method \
  -H "Authorization: Bearer YOUR_API_TOKEN"
Never hardcode real card numbers in tests, even ones marketed as “test cards” from upstream payment processors. The dedicated test-payment-method endpoint produces methods that are unambiguously safe for the Raise environment.

​
Be deliberate about reads

Read endpoints (GET /api/Donor/list, POST /api/Gift/query, etc.) are non-destructive — running them against a customer’s production organization is safe in the same sense that a SQL SELECT against a production database is safe (rate-limit budget aside). Reads against the customer’s real data during development are sometimes necessary to verify behavior with realistic data shapes. That said: log carefully (no PII in logs — see Security and Credential Management), and never store production read results in a development database without the customer’s awareness.

​
Be very deliberate about writes

Writes against a production organization — Donor creates, Gift refunds, Campaign updates — are real. The integration’s write should:
  • Use a known-test organization, OR
  • Be a planned production write that the customer has authorized.
Accidentally running a development test loop against a customer’s production data is an incident. Build credential separation between development and production environments so it’s hard to make this mistake. See Security and Credential Management.

​
Identifying your environment at runtime

When the same integration code can connect to multiple environments (a partner integration that supports multiple customers, plus a developer organization for testing), make the environment explicit in logs and metrics:
JavaScript
const ENV_LABELS = {
  'dev-org-internal': 'development',
  'customer-acme-test': 'customer-acme-test',
  'customer-acme-prod': 'customer-acme-production',
};

function getEnvironmentLabel(customerId) {
  return ENV_LABELS[customerId] || 'unknown';
}

console.log('Submitting donation', {
  customer_id: customerId,
  environment: getEnvironmentLabel(customerId),
  transaction_id: donation.id,
});
Two practices this enables:
  • Filter dev/test activity out of production metrics. Aggregate dashboards should default to “production environments only” rather than mixing developer-account traffic with real customer activity.
  • Alert on production-only. A failed donation on a developer account is rarely worth paging on; a failed donation on a production customer is.

​
What’s next

Your First API Call

A walkthrough of a real authenticated request against the production host.

Authentication

The token lifecycle that pairs with the host.

Error Handling

What error responses look like — what to expect from the production API.

Security and Credential Management

How to keep environment separation clean across development and production.
Last modified on May 21, 2026