Webhooks

To create a webhook:

1. Go to Settings > Webhooks.
2. Click Create webhook.
3. Enter a Webhook name that helps you recognize it later, such as Production sync.
4. Enter your Endpoint URL. This must be an HTTPS address that is publicly reachable.
5. Under Event types, select the events you want to receive. You can search, expand a group, or select All events. You must select at least one event.
6. Click Create webhook.

After you create the webhook, Fundraise Up shows the signing secret once in the Webhook created dialog. Copy it and store it securely, since you use it to verify incoming requests. You can view a masked version later on the webhook page.

Each webhook delivers only the events you subscribe it to. Fundraise Up groups the available events into four categories.

Donations:

• Donation created
• Donation successful
• Donation scheduled
• Donation updated
• Donation refunded

Recurring plans:

• Recurring plan activated
• Recurring plan scheduled
• Recurring plan canceled
• Recurring plan payment terms updated
• Recurring plan supporter preferences updated

Tribute:

• Tribute created
• Tribute updated

Supporter:

• Supporter created
• Supporter updated

Every delivery is an HTTP POST request with a JSON body. The body has the same top-level shape for all events, and the contents of data.object depend on the event type.

1{
2  "id": "evt_5f8b2a1c4d6e8f0000000123",
3  "type": "donation.created",
4  "created_at": "2026-05-06T12:34:56.789Z",
5  "data": {
6    "object": { ... },
7    "previous": null
8  }
9}

The top-level fields are:

• id: A unique identifier for the event, in the format evt_ followed by a hexadecimal string. Test deliveries use the evt_test_ and evt_ping_ prefixes. This value stays the same across retries, so use it to deduplicate events on your side.
• type: The event type, such as donation.created.
• created_at: The time the event occurred, as an ISO-8601 timestamp in UTC.
• data.object: The record the event is about.
• data.previous: The changed fields with their previous values. This appears only for update events, such as donation.updated. It is null for all other events.

Each request also carries these headers:

• Fundraise-Signature: The signature you use to verify the request. See the Verify the signature section.
• Content-Type: Always application/json.

Fundraise Up does not follow redirects, so your endpoint must respond directly at the URL you registered. For the full structure of data.object for each event type, see the API reference.

Verify the signature on every request so that you accept only genuine deliveries from Fundraise Up. Fundraise Up signs each request with your signing secret using HMAC-SHA256 and sends the result in the Fundraise-Signature header:

1Fundraise-Signature: t=1735689600,v1=<signature>

The header contains two values: t, the Unix timestamp of the request in seconds, and v1, the signature.

To verify a request:

1. Read the t and v1 values from the Fundraise-Signature header.
2. Build the signed string by joining the timestamp and the raw request body with a period: <t>.<raw_body>.
3. Compute an HMAC-SHA256 of that string using your signing secret.
4. Compare your result to the v1 value from the header. If they match, the request is authentic.

Use the exact raw request body for the comparison. Parsing and re-serializing the JSON first can change the bytes and break the match.

During the 24 hours after you rotate the secret, the header carries two v1 values — one signed with the current secret and one with the previous secret:

1Fundraise-Signature: t=1735689600,v1=<current>,v1=<previous>

A request is valid if it matches either signature. This lets your endpoint keep verifying requests while you switch to the new secret.

Your signing secret proves that a request came from Fundraise Up. It starts with whsec_ and is shown in full only when you create the webhook or rotate the secret.

On the webhook page, open the Settings tab and find the Signing secret section. There you can:

• Click the eye icon (Show secret) to reveal the full secret. Only Organization Administrators can view the secret.
• Click the copy icon to copy the secret.
• Click Rotate secret to replace it.

Rotate the secret if it is exposed or as part of routine security maintenance. To rotate it, open the webhook, go to the Settings tab, click Rotate secret, then confirm.

Rotation generates a new secret and keeps the previous one valid for 24 hours. During that window, Fundraise Up signs each request with both secrets, so deliveries keep verifying while you update your endpoint. Update your endpoint with the new secret within 24 hours. After the window closes, the previous secret stops working.

Test your endpoint from the Delivery log tab before you rely on live events. Both test options are available only when the webhook is enabled.

• Ping sends a lightweight request to confirm your endpoint is reachable from Fundraise Up.
• Send test events sends a sample payload for each event type the webhook is subscribed to, so you can confirm your signature check and event handling work.

A Ping request carries only id, type, and created_at — it has no data key. Send test events requests use the full payload shape with sample data.

Test requests do not create real activity in your account, and Fundraise Up does not retry them. Both appear in the delivery log, labeled so you can tell them apart from live deliveries.

Fundraise Up delivers each event at least once, so your endpoint may occasionally receive the same event twice. Order is not guaranteed. Deduplicate using the event id, and treat delivery as independent of sequence.

Your endpoint has 10 seconds to respond to each attempt. Fundraise Up classifies the response as follows:

• A 2xx response marks the delivery as succeeded.
• A 4xx response other than 408 or 429 marks the delivery as failed, with no retry. These usually point to a problem your endpoint must fix. Fundraise Up does not follow redirects, so a 3xx counts as a failure.
• A 408, 429, or 5xx response, a network error, or a timeout is retried.

Retries follow an exponential backoff over roughly 8 hours: the delay grows with each attempt — 10 seconds, 30 seconds, 1 minute 30 seconds, 4 minutes 30 seconds, 13 minutes 30 seconds, 40 minutes 30 seconds, 2 hours, and then 3 hours for the final attempts — up to 10 attempts in total. Retries also stop 24 hours after the event was queued, even if fewer attempts have been made. Once retries stop, Fundraise Up sends a failure notification.

Fundraise Up disables a webhook automatically if its endpoint goes 48 hours without a single successful delivery. This check runs on each failed delivery: once the 48-hour window passes with no success, the webhook is switched off and stops receiving events until you enable it again.

The Delivery log tab on each webhook page records deliveries at two levels: each delivery, and the individual attempts within it.

The first level lists deliveries, each with a status of Succeeded, Failed, or Pending, the event type, and the time of the last attempt.

Open a delivery to see its individual attempts. Each attempt shows the Status, HTTP status code, Event ID you can copy, Response time, Request text, and Response text. Retried attempts are labeled Resent automatically or Resent manually. When every attempt has failed, the delivery is marked All delivery attempts have failed.

To send a delivery again, click Resend on a failed delivery. This adds a new attempt and does not change the automatic retry schedule.

Fundraise Up can email you when deliveries start failing. This notification is on by default. To manage it, go to Settings > Notifications > System issues and toggle Webhook delivery failures.

Fundraise Up sends the email after the first failed delivery in your account. It then waits 24 hours before sending another failure email, even if more deliveries fail during that time. The email names the affected endpoint and links to its delivery log so you can investigate.

Fundraise Up also emails you when it disables a webhook automatically, after its endpoint goes 48 hours without a successful delivery.

You can pause or delete a webhook from the list or from the webhook page.

• To pause deliveries, click three-dots (…) and select Disable webhook. A disabled webhook stops receiving events until you enable it again. Its delivery history stays available.
• To resume deliveries, select Enable webhook.
• To delete a webhook, select Remove.

If your organization uses subaccounts, a parent company can view and edit the webhooks of its subaccounts. When any child-company webhooks exist, the list shows an Account column so you can tell which subaccount each webhook belongs to. New webhooks are always created in the account you are currently logged in.

Webhook activity is recorded in your account Audit log, including when a webhook is created, updated, enabled, disabled, or removed, and when its signing secret is rotated. Each entry records what changed and when.