Let's talk about APIs
If you've ever connected Donorfy to another tool - maybe your website, a payment provider, or a reporting dashboard - there's a good chance you've used our API without even realising it. An API (Application Programming Interface) is essentially a way for different software systems to talk to each other. Think of it like a waiter in a restaurant: you tell the waiter what you want, the waiter goes to the kitchen, and brings back your food. You never need to know how the kitchen works.
The Donorfy API is that waiter. It lets external systems ask Donorfy for data ("show me this constituent's donations") or tell it to do things ("create a new supporter record"). It's been powering integrations, imports, and automations across hundreds of charities for years.
And now, we're hiring new staff as well as revamping the kitchen.
Why are we building a new API?
Our current API has served the Donorfy community well. It lets you search for constituents, manage transactions, handle Gift Aid declarations, work with tags, and more. If you've built integrations or used tools like Zapier or Power Automate with Donorfy, this is the API that's been doing the heavy lifting.
But let's be honest it was built in a different era of web technology. Here are some of the limitations you may have bumped into:
Authentication. The biggest limitation is that the current API only supports a single type of authentication. It is designed for simple external system integrations, and that's about it. We can't use the same API internally to power the Donorfy platform itself, or to drive the new EVO features you'll be hearing more about. That means we've ended up in a situation where external integrators get one interface, the platform gets another, and neither is as good as it should be.
One record at a time. Need to update 500 supporters? That's 500 individual API calls. There's no bulk operation support, which makes large-scale data work slow and painful.
No change tracking. Want to know what's changed since yesterday? You can't ask the API "give me everything that's been modified since Tuesday." You'd have to pull everything and figure it out yourself.
Limited filtering and sorting. Searching is basic - you can look up a constituent by email, phone number, or external key, but there's no way to say "give me all constituents in London, sorted by last donation date, page 3 of 20."
Synchronous and single-threaded in design. The underlying technology processes requests one step at a time, which limits how fast it can respond under load.
None of these are bugs they're just the natural limits of something built in a different era. The world's moved on, and it's time Donorfy's API caught up.
So what's in it for you?
Before I get into the technical weeds, let me cut to the chase: what does a new API actually mean for the people using Donorfy?
Your integrations get better
If you're connecting Donorfy to other systems, whether that's a website, an email platform, a data warehouse, or something bespoke, the new API makes those connections faster, more reliable, and more capable. Proper filtering means you only pull the data you need. Bulk operations mean large imports don't take all afternoon. Change tracking means your nightly sync only grabs what's actually changed.
If you've ever had an integration that was a bit flaky, a bit slow, or just couldn't quite do what you needed - this is for you.
The platform gets smarter
Donorfy now sits within the Access Evo platform, which connects over 180 products into one experience. You might have already heard about some of what Access Evo offers:
- Copilot - an AI assistant that can answer questions about your data and help you take action
- Analytics - a centralised reporting platform that can help you visualise data from Donorfy and other connected products
There are also new and exciting apps & features on the horizon:
- Navigator - a personalised command centre for managing your daily work across Access products
- Workflow Automation - build automated processes that work across systems, no coding required
- Agents - AI-powered helpers that can gather information, make decisions, and carry out tasks on your behalf
All of these features need a strong, modern API underneath them. The new Donorfy API is what will power agents looking up a supporter's giving history, workflows that trigger when a donation comes in, and Copilot answering questions about your data. Without it, these platform features can't reach into Donorfy properly. With it, they can.
Extensibility and customisation
Here's something I'm particularly excited by. The new API uses a hybrid approach. We are building both a traditional REST API and a GraphQL layer (more on what that means in the technical section below). The practical upshot is:
- External integrators and consultants get a clean, well-documented REST API that works with every integration tool going be that ones you love already like Zapier and Power Automate, or our very own Evo platform tools with you in the near future.
- Platform features and interactive tools get GraphQL, which is more flexible and efficient for building rich user experiences.
- We eat our own cooking. Because the API supports both system-level and user-level authentication, we use the same API to power Donorfy's own features that we give to customers. That means if something's slow or awkward for you, it's slow and awkward for us too which tends to get things fixed quickly.
For consultants and partners building on top of Donorfy, this opens up a much richer set of possibilities for customisation and extension.
What's actually changing?
Right, let's get into the specifics.
Dual authentication
The new API supports two ways to authenticate:
- System authentication for server-to-server integrations (your automated syncs, data imports, third-party connectors). We are keeping the concept of system authentication for those use cases that power large scale data syncs, integrations and many other use cases. The mechanism for this will be secure and we will provide more information as we move forward with the project.
- Identity authentication tied to the Access Identity platform, this allows us to use the power of the API for individual users without complex new auth setups and while honouring permissions and security you have already set up within Donorfy.
This is what lets us use the same API for external integrations and internal platform features. One API, two authentication models, everyone's happy.
Full CRUD Operations
CRUD stands for Create, Read, Update, and Delete, these are the basic operations you will want to perform on your data. The new API gives you the full set:
- GET allows you to access your data with filtering, sorting and paging built in.
- POST to create new records
- PATCH to update existing ones
- DELETE to remove records
We're starting with constituents and expanding across the system from there. Every area will follow the same consistent pattern.
Change tracking
One of the most requested features by our partners. You'll be able to ask the API "what's been created or modified since my last sync?" instead of pulling your entire dataset every time, this is both simpler and significantly more efficient than the current API. If you're running regular data syncs or building dashboards, this is the one you've been waiting for.
Bulk operations
We're building support for sending batches of records in a single request. These get processed as background jobs, so you fire off your batch and carry on. No more waiting until 3am to start routines waiting for thousands of records to churn through one by one.
Filtering, sorting, and pagination
Endpoints will support proper filtering ("only active constituents in this region"), sorting ("by last modified date, newest first"), and pagination ("give me results 51 to 100"). We will work with all of you to build this toolset up to support your use cases. This makes integrations more efficient and plays nicely with tools that expect paginated responses.
Interactive documentation
We're shipping with interactive API documentation built in. You'll be able to explore every endpoint, see exactly what parameters are available, and test requests right from your browser.
The hybrid: REST + GraphQL explained
I mentioned we're building two types of API, so let me explain what that means in plain English.
REST is the traditional approach. You call a specific URL for a specific thing, e.g. "give me constituent number 42" and you get back a fixed set of data. It's like ordering a set meal: you get the starter, main, and dessert whether you wanted them all or not.
GraphQL is more flexible. You specify exactly what data you want e.g. "give me constituent 42's name and their last three donations, nothing else" and that's exactly what you get back. It's like ordering a la carte.
Why not just pick one? Because they're genuinely good at different things.
REST is brilliant for system-to-system integrations. It's simple, predictable, and every integration platform in the world knows how to talk REST. If you're building a sync between Donorfy and your website, REST is your friend.
GraphQL is better for interactive, user-facing features where you need to pull together different bits of data efficiently. It's what will power the EVO platform's agents and workflows when they need to reach into Donorfy, an agent asking "show me this supporter's recent activity, their preferences, and their upcoming events" can get all of that in one request instead of three. By only returning the exact data requested these requests are also more efficient and scale for our thousands of users.
Both styles are backed by the same underlying business logic and security model. They're two doors into the same building.
Under the hood (for the technically curious)
Here’s a look at some of the principles behind how we’re building it - and why they matter for you.
How we're building it
I wanted to touch on this because it's genuinely changing how we work.
A few things about how we’re approaching this are worth calling out - because they have a direct bearing on the quality and reliability you’ll experience.
Built around concepts you already know
The new API is built around the real-world things that matter in Donorfy - constituents, transactions, donations, Gift Aid. Every endpoint maps to something you already understand. This isn’t just a design preference; it means integrations are more intuitive to build, easier to document, and simpler to maintain over time. If you know what you’re trying to do with your data, you’ll be able to find the right part of the API to do it.
Your integrations won’t break
The new API is versioned, which means we can keep improving and adding features without ever pulling the rug from under the integrations you’ve already built. When we do make a significant change, we’ll give you plenty of notice and a clear migration path. The integration you build today will still work tomorrow - and we’ll tell you well in advance if anything ever needs to change.
Built for AI - securely
One of the things we’re most excited about is that this API has been designed from the ground up to be used by AI agents - not just human developers. That means AI tools, whether our own or third-party, can interact with Donorfy in structured, reliable, and controlled ways.
Security isn’t an afterthought here. Every agent or tool that connects to Donorfy does so with granular permissions - it only gets access to exactly what it needs, nothing more. The same security model that protects your users also governs what any AI can see and do. That’s important to us: as AI becomes a bigger part of how people work, we want you to be able to trust that your data is always in safe hands.
This is also what underpins our own ambitions for Donorfy. The EVO platform features - Copilot, Agents, Workflow Automation - all rely on a well-structured, AI-ready API to reach into your data and act on your behalf. We’re not building a separate back door for our own AI; we’re using the same API we give to you. If it’s not good enough for us, it’s not good enough for you - and that’s a commitment we intend to keep.
How we’re delivering it
We’re using AI-assisted development to build the API itself. Our engineering team works alongside AI tooling that understands our codebase, our standards, and our conventions - helping to generate code, write tests, and review changes at pace. This isn’t about cutting corners; it’s about letting engineers focus on the things that matter most: the business logic, the security model, and getting the experience right for you.
We’ve also built on shared standards and templates from across the NPE division at Access. That means we’re starting from proven foundations, not from scratch - and when any team in the division finds a better way to do something, the whole division benefits. The result is an API built to a consistently high bar, delivered at a pace that keeps up with the rest of your Donorfy roadmap.
The roadmap
We're targeting the first endpoints to be available by summer 2026, starting with constituents the heart of any CRM. The infrastructure is already in place and we are actively building the core features now.
This is the first in what I hope will be an ongoing series of posts about what we're building and why. We want you along for the journey - your feedback, your use cases, and your war stories (of which I am happy to share my own!) help us build the right thing.
Get involved
If you've got integration needs, data challenges, or just opinions on what the new API should do, we'd genuinely love to hear from you. The best APIs are the ones built in partnership with the people who actually use them.
Watch this space.
Chris & the Donorfy Engineering Team
AU & NZ
SG
MY
US
IE