Developers
One nonprofit data graph, exposed through governed APIs.
Use the REST API, webhooks, or the production MCP endpoint to work with permitted Gratona data. The public MCP surface is read-only by default, the ChatGPT app remains a private draft, and Tali is available with source context and human review.
Available and private-access surfaces
Each surface has an explicit launch state and inherits the same access boundaries.
REST API
Read and write through documented endpoints for donors, gifts, sponsorships, trips, campaigns, and engagement. Token scopes, webhooks, and idempotency controls protect production integrations.
API reference →MCP server
The production MCP endpoint exposes permission-scoped nonprofit data tools to compatible clients. The public surface is read-only by default; hidden mutations require separate controls and are not part of the current connector launch.
See the governance model →Private ChatGPT connector
The Gratona connector has a validated production MCP backend and remains a private draft while public app review is pending. Connected users see only the Gratona workspace data their current permissions allow.
Ask about private access →Other MCP clients
Claude and other compatible MCP clients can use the same governed endpoint when deliberately configured. Access remains bounded by authentication, scopes, and Gratona permissions rather than the client interface.
Review integrations →Webhooks and integrations
Use webhook events and supported integrations to move payment, accounting, communication, and workflow signals while keeping the source record identifiable.
All integrations →Tali
Tali prepares source-grounded fundraising work inside Gratona. Tali respects the same permission context, keeps source context attached, and waits for human review before donor-facing or external action.
Meet Tali →Nonprofit API governance
One identifier and audit context across API surfaces
Authentication, scopes, and Gratona permissions all apply
The public MCP tool surface is read-only by default
Source context remains identifiable for review
Human review before donor-facing or external AI action
Idempotency controls on supported mutations
What to verify before building
Plan access and endpoint coverage are separate questions. Review the current API reference against the records and actions your integration needs.
| Resource family | Current coverage | Confirm before contracting |
|---|---|---|
| Donors, organizations, households, and relationships | Documented read and write routes cover constituent records. Current application routes also manage household membership, primary contacts, and related-contact roles. | Confirm the fields, archive behavior, duplicate handling, relationship direction, and permissions required by the integration. |
| Gifts, commitments, designations, and soft credits | Current routes cover donation and commitment records, designations, refunds, donor giving history, soft-credit records, and scoped exports. | Confirm payment actions separately from historical record writes, including idempotency, settlement ownership, refunds, and reconciliation. |
| Sponsorships and recipients | Current routes cover sponsor-recipient relationships, commitments, program records, archive and restore actions, and program exports. | Confirm the exact recipient fields, commitment transitions, program boundary, and donor-facing action in scope. |
| Events and mission trips | Current application routes cover event registration, attendees, check-in, orders, sponsors, tables, exports, trips, participants, tasks, documents, budgets, and analytics. | Confirm which of these routes are included in the contracted API surface, because application coverage and external integration access are not the same promise. |
| Reports, activities, notes, and tasks | Current routes cover report definitions, previews, rows, schedules, exports, activities, notes, and fundraising work-item views. | Confirm write coverage, attribution fields, attachment handling, delivery method, and the permission context for each operator. |
| Webhooks and connected apps | Webhook handling is provider- and event-specific. Gratona records supported event and integration signals, but does not publish a universal customer-configurable outbound event catalog today. | List every event, direction, signature, retry rule, replay path, duplicate rule, payload version, and reconciliation owner in the implementation scope. |
Plan entry
Read API access begins with Growth. API writes and webhooks begin with Scale. Network covers custom and multi-entity integration scope.
Coverage
The API reference is the source for current resources, fields, actions, authentication, and response formats. Confirm the exact read, write, webhook, and idempotency path before signing the implementation scope.
Test access
Gratona does not list a self-service public sandbox today. Contact us to confirm the current test-access option for your integration and plan it into the implementation timeline.
Bring an integration contract
Name each source and destination, record type, identifier, direction, action, permission, expected volume, retry rule, duplicate rule, webhook event, reconciliation test, and owner. That is enough to determine whether the documented API covers the workflow or whether Network custom scope is required.
Build your member or staff experience on Gratona
Build your app on Gratona’s documented APIs. Connect donor records, giving and staff workflows to your member or staff interface.
Explore Gratona by fundraising goal
Map the integration before you build it.
Bring the systems, records, actions, and permission boundaries in scope. We will map the supported surface and the proof required before launch.