Skip to content

Resources

The Live API explorer renders every operation in the platform’s OpenAPI feed, including a long tail of internal admin endpoints that aren’t part of the supported public API. This page is the curated map: which resource groups are part of the supported public surface, what each one does, and which groups are deliberately off-limits for external integrators.

Not every endpoint in the live explorer is part of the supported public API surface. Build against the groups listed below; the others are for internal admin tooling and may change without a changelog entry.

CRUD plus the dashboard aggregate, audit feed, and duplicate detection. The starting point for almost every integration — most other resources hang off a contactId.

  • GET /api/tenants/{tid}/contacts
  • GET /api/tenants/{tid}/contacts/{contactId}
  • GET /api/tenants/{tid}/contacts/{contactId}/dashboard
  • POST /api/tenants/{tid}/contacts
  • PUT /api/tenants/{tid}/contacts/{contactId}
  • POST /api/tenants/{tid}/contacts/check-duplicates
  • GET /api/tenants/{tid}/contacts/{contactId}/audit-logs

Recipe: Import a contact.

A donation is an OrderDonation line on an Order. To record a gift, create an order. To inspect history, read orders.

  • GET /api/tenants/{tid}/orders — paginated list with filters.
  • GET /api/tenants/{tid}/orders/{orderId}
  • POST /api/tenants/{tid}/orders — covers donation-only and item orders. Idempotent via IdempotencyKey.

Operator-only (require dedicated scopes; surface in support tooling, not in customer-driven integrations):

  • POST /api/tenants/{tid}/orders/{orderId}/void (orders:void)
  • POST /api/tenants/{tid}/orders/{orderId}/refunds (orders:refund)

Recipes:

Read recurring schedules and cancel them. Recurring donation creation flows through the order endpoint — pass a recurringDonations array on POST /orders. See the charge-a-card recipe.

  • GET /api/tenants/{tid}/recurring-donations
  • GET /api/tenants/{tid}/recurring-donations/{scheduleId}
  • POST /api/tenants/{tid}/recurring-donations/{scheduleId}/cancel

Read-only for most integrations — what items the tenant has, current stock, pricing.

  • GET /api/tenants/{tid}/inventory
  • GET /api/tenants/{tid}/inventory/{itemId}

Tenant-admin-only (require admin-tier scopes):

  • POST /api/tenants/{tid}/inventory (inventory:create)
  • PUT /api/tenants/{tid}/inventory/{itemId} (inventory:edit)

Run saved reports and pre-built report types, paginate the results, or export to Excel/PDF/CSV.

  • GET /api/tenants/{tid}/reports — list saved report definitions.
  • POST /api/tenants/{tid}/reports/{reportId}/run — paginated run.
  • POST /api/tenants/{tid}/reports/{reportId}/export — file download.
  • GET /api/tenants/{tid}/reports/types — list pre-built report types.
  • POST /api/tenants/{tid}/reports/types/{typeKey}/run

Recipe: Run a saved report.

Outbound delivery so you don’t have to poll. Covered separately on the Webhooks overview and event catalog.

  • GET /api/tenants/{tid}/webhooks
  • POST /api/tenants/{tid}/webhooks
  • PUT /api/tenants/{tid}/webhooks/{webhookId}
  • DELETE /api/tenants/{tid}/webhooks/{webhookId}
  • GET /api/tenants/{tid}/webhooks/event-types
  • GET /api/tenants/{tid}/webhooks/{webhookId}/deliveries
  • POST /api/tenants/{tid}/webhooks/{webhookId}/test

Recipe: Listen for events.

Self-managed credential CRUD. Use the in-app Administration → Integrations → API Keys for first-time provisioning; use the API for programmatic rotation.

  • GET /api/tenants/{tid}/api-keys
  • POST /api/tenants/{tid}/api-keys
  • DELETE /api/tenants/{tid}/api-keys/{apiKeyId}

Covered in Authentication.

The endpoints below ship in the OpenAPI feed (so the in-app admin tooling that lives on the same shape can call them) but are not part of the supported public API surface. They exist to support tenant operators and host administrators inside the workspace. Building against them externally is not blocked by access control today, but stability is not promised — they may change shape, scope, or disappear without a changelog entry.

  • Tenant administration — branding, tax-statement org profile, feature toggles, behaviors. Operator UI only.
  • Multi-factor authentication — enrollment, verify, recovery, trusted devices. Cookie-auth only; API keys can’t authenticate to MFA flows.
  • Impersonation — host-admin and tenant-admin sessions for support tooling.
  • Tax statements — annual receipt generation and CSV exports. Operator-driven; expect heavy changes as the module evolves.
  • Audit logs and operations log — read-only views of internal events, served to in-app dashboards.
  • Dashboards (role + user-composed) and cohorts — UI configuration.
  • Batches and fulfillment — operator workflow tooling. The batch.* and shipment.* webhook events surface enough for replication; the REST endpoints for managing them are operator-driven.
  • Imports and onboarding — wizard-driven, not for headless use.
  • Documents (letters, packing slips, tax-statement templates) — operator UI for template editing.
  • Marketing-form submissions (/api/contact-form) — public, unauthenticated, rate-limited; called from the marketing site.

If you have a clear use case that lives in one of those groups, contact support — we’d rather promote a stable subset to public than leave you building against shifting ground.

  • Conventions — pagination, errors, idempotency, rate limits.
  • Recipes — five end-to-end workflows showing how the public surface composes.
  • Changelog — breaking and notable additive changes.