A morning desk with coffee and a laptop showing donation campaigns and contact records

Givebutter API: Automate Donor Thank-Yous and Alerts

The moment a gift lands in Givebutter, Carly can make it feel noticed. Carly sends the campaign-aware thank-you, alerts the development director to a major or first-time donor, updates the CRM, schedules the personal follow-up, and steps in quickly when a recurring plan fails. Givebutter records the transaction; Carly keeps the relationship moving.

Givebutter’s API is free, self-serve, and unusually open for this market. Their help center puts it directly: “Givebutter is proud to be among the few fundraising platforms that offer a free, open, and public API.” No sales call, no developer program, no paid tier to unlock it.

That’s the good news, and it’s real. The complication is that the spec file the documentation site serves is about six months out of date, and if you generate a client from it you’ll quietly end up unable to subscribe to refunds.


What nonprofits actually automate with it

The jobs worth setting up, all of which Givebutter already knows about the moment they happen:

  • Same-day thank-yous. A donation completes and the acknowledgement goes out within the hour with the right fund and campaign attached — rather than a monthly batch that arrives long after the moment has passed.
  • Failed recurring plans reached fast. A donor’s card expires and their monthly gift silently stops. Givebutter fires an event for this, and reaching them the same day is the difference between a restored plan and a lapsed one.
  • Large or first-time gifts flagged to the director for a personal call while it still feels personal.
  • New contacts routed into a welcome sequence without anyone exporting a CSV.

The recurring-plan one is worth singling out, because lapsed monthly donors are the quietest form of revenue loss most small nonprofits have.


Use the right spec file

Two OpenAPI documents exist. They are not the same:

  • docs.givebutter.com/api-reference/api.jsonstale, last modified January 2026, 35 paths and 10 webhook events
  • givebutter.com/docs/api.jsoncanonical, 40 paths and 12 webhook events

The stale mirror is missing plan.failed, refund.created, the /pledges endpoint, and the webhook signature field. It also documents obsolete tag routes — POST and DELETE on /contacts/{id}/tags, where the live API uses tags/add, tags/remove, and tags/sync.

Generate from the wrong one and nothing errors. You just get a client that can’t do things you assume it can.

Getting a key

You need an Admin role — Editors can’t reach the settings tab at all.

Givebutter documents two different click-paths, which is worth knowing so you don’t think you’re lost. The help center says Settings → Developers → API → New API key. The API docs say Settings → Integrations → API Keys. The Developers path matches where the webhooks article sends you, so it’s likelier the current UI.

The key is displayed once and stored hashed. There’s no recovery — regenerate if you lose it.

On cost: Givebutter runs on a donor-tip model (0% platform fee with tips on, 3% with tips off), and there’s a paid Givebutter Plus tier at $29–$129/month by contact count. API access isn’t listed as a Plus feature, and no primary source describes a gate. Worth noting the pricing page doesn’t positively state “API is on the free tier” either — the evidence is absence of a gate rather than a stated inclusion.

The basics

  • Base URL https://api.givebutter.com/v1
  • Auth is Authorization: Bearer {API_KEY}, HTTPS only
  • Rate limit is 500 requests per minute — generous for this market. Exceeding returns 429 with a Retry-After header. There are no X-RateLimit-* headers, so you can’t see your remaining budget.
  • Pagination is Laravel-style ?page= and ?per_page=, default 20, max 100. The docs page is titled as though cursor pagination exists; only offset is actually documented.
  • Validation failures return 422 with a {message, errors} shape

Version is a plain v1 in the path. No version header, no dated versioning — so no equivalent of the versioning traps in Planning Center or Fleetio.

What you can actually write

The read/write split here is unusually uneven, and it’s the thing most likely to derail a plan:

  • Full CRUD — contacts, contact activities, households, funds, campaigns, campaign discount codes, webhooks
  • Create and update, no delete — transactions
  • Create only — campaign ticket types
  • Delete only — campaign members and campaign teams. You can remove them; you can never add or edit one through the API.
  • Read-only — issued tickets, recurring plans, pledges, payouts, messages, webhook delivery activities

Recurring plans being read-only is the one that hurts. You can observe a donor’s plan, and you’ll get an event when it fails — but you cannot create, cancel, pause, or resume it. When a plan fails, your automation can notice and notify, and then it has to send the donor to the UI.

Contacts get two nice extras: a PATCH /restore for undeleting, and three dedicated tag routes.

Twelve webhook events, and good introspection

The full list:

  • transaction.succeeded — a donation completes
  • refund.created — a refund is processed
  • contact.created — a new contact
  • ticket.created — a ticket is issued
  • campaign.created, campaign.updated
  • Recurring plansplan.created, plan.updated, plan.canceled, plan.paused, plan.resumed, plan.failed

Webhooks are fully API-managed rather than dashboard-only, which is not a given at this price point. And the delivery log is queryable: GET /v1/webhooks/{id}/activities returns status, event, payload, and response for each delivery, with last_status, last_status_description, and last_used_at on the webhook record itself. That’s better introspection than most platforms three times the size offer.

Two gaps to design around. There is no contact.updated and no transaction.updated. Contact edits and transaction changes fire nothing, so anything depending on those has to poll.

Givebutter doesn’t document a retry policy, so don’t assume one.

Three traps

  1. Webhooks created through the API before roughly June 2026 have a null signing secret. Givebutter’s own changelog describes fixing “a long-standing bug where webhooks created through the public API were saved without a signing secret, which had left customers unable to verify incoming payloads.” If you have older API-created webhooks, they need re-creating, not just a code fix — this is a security issue, not a cosmetic one.
  2. POST /v1/webhooks only requires url. Both event and events are accepted, and neither is required. You can create a webhook subscribed to nothing at all, get a clean 201, and then wonder why it never fires.
  3. Contact activity types are not webhook events. The ContactActivityTypeEnum has 26 values including convincing lookalikes — recurring_plan.created, transaction.acknowledged, campaign.joined, and a misspelled transaction.recieved. Those are activity-feed rows. Subscribing to them isn’t a thing, and it’s an easy mistake to make from a quick skim of the spec.

The API is GA and shipping monthly — the changelog shows a docs rebuild in February 2026, new events in March, new filters in April, and the signing-secret fix in June.

Getting the donation to do something

A completed donation, a new contact, a failed recurring plan — Givebutter fires all three reliably, and at 500 requests a minute it’s one of the friendlier surfaces in nonprofit software. What’s usually missing is anything on the other end.

Handing that to an AI assistant runs into a specific limit.

Both ChatGPT and Claude will now do work on a schedule, unattended. Neither reacts to events. A task that runs hourly still finds out an hour late, and one that runs each morning finds out tomorrow — the trigger is the clock, never the thing you actually care about.

“Summarize last month’s campaign performance” is well within what ChatGPT or Claude will do with a Givebutter export. “Acknowledge the gift within the hour, in the donor’s name, with the right fund attached” is not, because nothing on that side is watching for the gift.

Carly covers that half:

  • Fires on the Givebutter eventtransaction.succeeded, contact.created, plan.failed
  • Runs the whole follow-up in one flow — read the transaction, pull the contact and fund, draft the acknowledgement, send it, log the activity
  • Actually sends — Gmail and Outlook, with attachments
  • Covers the read-only gaps sensibly — a failed recurring plan can’t be fixed through the API, but reaching the donor fast with the right link is exactly what turns a lapsed plan into a restored one

Because Givebutter exposes a free public API, you can connect it natively to Carly from the Integrations tab with your API key. Carly can then use Givebutter in on-demand, recurring, and event-triggered workflows. AI agents start at $35/month, and workflow steps that don’t use AI run free.


Frequently Asked Questions

Is the Givebutter API free?

Yes. Givebutter describes it as a free, open, public API, and no primary source documents a plan gate. API access isn’t listed among the paid Givebutter Plus features either. You need an Admin role on the account to create a key.

How do I get a Givebutter API key?

Settings → Developers → API → New API key, as an Admin. Givebutter’s API docs describe a slightly different path via Settings → Integrations, but the Developers tab matches where their webhooks documentation points. The key is shown once and stored hashed.

What is the Givebutter API rate limit?

500 requests per minute. Exceeding it returns a 429 with a Retry-After header. There are no rate-limit headers on successful responses, so you can’t check your remaining budget mid-run.

What webhooks does Givebutter support?

Twelve events: transaction succeeded, refund created, contact created, ticket created, campaign created and updated, and six recurring-plan events including plan failed. There’s no contact.updated or transaction.updated, so those changes need polling.

Can I cancel a donor’s recurring plan through the Givebutter API?

No. Recurring plans are read-only — you can observe them and receive events when they’re created, updated, paused, resumed, canceled, or failed, but you cannot create or modify one through the API.

Why doesn’t my Givebutter webhook signature verify?

Webhooks created through the API before around June 2026 were saved without a signing secret due to a bug Givebutter has since fixed. Those webhooks need to be re-created rather than patched in code.


More: AI agents for nonprofit directors · Best AI assistant for nonprofits · Bloomerang AI

Ready to automate your busywork?

Carly schedules, researches, and briefs you—so you can focus on what matters.

See what people say

"Before Carly, I relied on a Calendly link, but the whole process felt impersonal and not very professional. Carly changed that by handling all the back-and-forth, so I'm no longer stuck in endless email threads trying to line up schedules.

Now Carly reaches out to candidates, shares my real-time availability, lets them pick a slot, then sends a Zoom link and drops it straight into my calendar. She sends reminders to both of us before each call, which has significantly reduced no-shows and last-minute confusion.

On top of scheduling, Carly acts like a full executive assistant, sending me my schedule the night before so I can prepare for each call. It reminds me of the old x.ai assistant, but Carly is noticeably smarter, faster, and better suited to my healthcare recruitment business."

Gus Ibrahim, Founder & Director, IHR