Givebear Connect

Givebear Connect is a versioned REST API and OAuth provider. It lets your platform act on one organization's giving data. You read its donations, donors, campaigns, funds, and payouts. You collect new donations that settle into the organization's own Stripe account.

Think of it the way you think of Stripe Connect. The organization owns the data and the money. Your app acts on its behalf with a credential the organization controls and can revoke at any time.

What you can build

Connect covers two jobs.

• Read giving data. List and fetch donations, donors, and payouts. Read campaigns, funds, and the organization profile to resolve the ids that donations reference.
• Collect donations. Create a payment intent on the organization's behalf, then render Stripe Elements with the returned values. The donation settles to the organization's Stripe account exactly like a donation made on Givebear.

Common integrations include syncing donations into a CRM, building a custom donation form, or reconciling payouts in accounting software.

The credential model

Every request to /api/v1 carries a bearer credential. That credential is bound to exactly one organization, so your code never passes an organization id. The API derives it from the token.

There are two credential types, and they hit the same endpoints with the same scopes.

Both are passed the same way, in any language (the quickstart shows this call in curl, JavaScript, Python, PHP, Ruby, and Go):

curl https://givebear.io/api/v1/donations \
  -H "Authorization: Bearer gb_live_..."

The key difference is attribution and reach. An API key sees the organization's direct resources. An OAuth token is also tagged with your app. Donations it creates and webhook endpoints it manages stay scoped to your app, not to other apps connected to the same organization.

See Authentication for the full token lifecycle, and the Quickstart to make your first call.

Scopes

A credential grants only the scopes it was issued. The authorizing admin can never grant more than their own permissions allow. A request missing a scope gets a 403 with type insufficient_scope.

There are no write scopes for campaigns, funds, or donors in v1. They are intentionally absent until read and collect are proven.

How money settles

When you collect a donation, money never touches your platform balance. It settles to the organization's own Stripe connected account, the same path a donation made directly on Givebear takes.

The flow keeps you out of PCI scope (SAQ-A):

The donation is attributed to your credential, so the organization can see which app collected it. Platform fees follow the organization's current plan: see pricing for the rates.

Staying in sync with webhooks

Polling the read API works, but webhooks tell you the moment something changes. You register an endpoint (with webhooks:write), pick events, and Givebear delivers a signed POST when each one fires.

Payloads are deliberately thin. An event carries its type and the affected record's id, not the record itself:

{
  "id": "8f3c2b1a-6d4e-4a90-9b2c-1f0e7d5c4b3a",
  "type": "donation.created",
  "created": "2026-06-30T12:00:00.000Z",
  "data": { "id": "don_123" }
}

You verify the x-givebear-signature header, then fetch the full record from the read API with data.id. This keeps donor data out of the delivery pipe. See Webhooks for the event list and signature verification.

The official client

The @givebear/connect package wraps the API with typed methods, cursor pagination, and a webhook verifier. It is dependency-free and runs anywhere with fetch and Web Crypto. Not on JavaScript? Every guide shows the same calls in Python, PHP, Ruby, and Go, and the API reference generates samples per endpoint in those and more.

import { GivebearConnect } from "@givebear/connect";

const gb = new GivebearConnect({ token: process.env.GIVEBEAR_TOKEN! });

const { data } = await gb.donations.list({ limit: 50 });
for await (const donation of gb.donations.listAll()) {
  console.log(donation.amount_cents);
}

If you want to embed a donation form on a marketing site instead of calling the API server-side, the browser SDK may be a better fit.

Where to go next