--- title: "Get events" method: GET path: "/v1/events" tags: ["Events"] --- # Get events `GET /v1/events` This request helps you track updates and changes in your account in the same way as in the [Audit Log](https://fundraiseup.com/docs/audit-log/). While the `Donations` endpoint shows the current state of a donation when queried, it doesn't reflect changes that happen after the initial creation (for example, finalized fees or status updates). The `Events` endpoint logs all updates as they occur, giving you the most current view of activity when you query it. ### Use cases - **Retrieving finalized fees**. The `platform_fee` field in a donation will initially show 0 until Stripe finalizes the fee data. To get the updated fee values, use the `Events` endpoint to track the `donation.success` event, which confirms that the finalized fees have been updated. - **Monitoring donation status changes**. Donations can move through multiple statuses — `pending`, `success`, `failed`, and more. Use the `Events` endpoint to track status changes. For example, a donation might be `pending` while awaiting payment processor confirmation and later transition to `success` or `failed`. - **Tracking refunds and disputes**. If a donation is refunded or disputed, you'll receive corresponding events like `donation.refunded`, `donation.success_dispute_created`, or `donation.success_dispute_won`. This helps keep your records accurate without manually checking each donation. - **Handling recurring plan updates**. Recurring donations generate events like `recurring_plan.activated`, `recurring_plan.failed`, or `recurring_plan.canceled`. Monitoring these events allows you to track subscription activities and take appropriate actions if a recurring payment fails or is canceled. - **Updating supporter information**. When a supporter updates their information or requests personal data deletion, events like `supporter.updated` or `supporter.personal_data_deleted` are triggered. This is especially important for maintaining compliance with data protection regulations. - **Monitoring tribute activity**. Use events like `tribute.created` or `tribute.updated` to keep track of tribute donations and ensure that tribute cards are sent as expected (`tribute.shared`). ## Query parameters - `livemode` boolean - `created` CreatedQuery — Filters results by the record creation date. Accepts a single date or a date range in RFC 3339 format. - `created[gt]` string, date-time — Minimum creation date (exclusive). Returns records after this timestamp. - `created[gte]` string, date-time — Minimum creation date (inclusive). Returns records from and after this timestamp. - `created[lt]` string, date-time — Maximum creation date (exclusive). Returns records before this timestamp. - `created[lte]` string, date-time — Maximum creation date (inclusive). Returns records up to and including this timestamp. - `starting_after` string - `ending_before` string - `limit` integer - `types` string[] ## Response `200` On success, the API returns the list of events. The response includes the event data array and a boolean indicating if more records are available. - EventsResponse — Contains the response for a list of events, including paginated event data and metadata indicating if more records are available. - `data` EventResponse[], required — An array containing the entity records, paginated by any request parameters. - `account` AccountResponse, required — Organization account information. - `code` string, nullable, required — Custom identifier for the organization, set as the Account code in the Fundraise Up account. - `id` string, required — Unique identifier of the organization in the format A[A-Z]{7}. - `name` string, required — The name of the organization as set in the Fundraise Up account. - `created_at` string, required — Timestamp in ISO 8601 format, indicating when the event was created in UTC. - `donation` string, nullable, required — Deprecated. This field is kept for backward compatibility and will be removed after 2026-10-30. Use the payments array instead. See the migration guide. - `id` string, required — Unique identifier for the event. - `livemode` boolean, required — Test mode indicator. `true` for live mode donations, `false` for test mode donations. - `payments` EventPaymentItem[], required — An array of donations and recurring plans associated with the event. Example: [{ "donation": "DXXXXXXX", recurring_plan: "RXXXXXXX" }]." - `donation` string, nullable, required — Donation identifier, formatted as D[A-Z\d]{7}. - `recurring_plan` string, nullable, required — Recurring plan identifier, formatted as R[A-Z\d]{7}. - `recurring_plan` string, nullable, required — Deprecated. This field is kept for backward compatibility and will be removed after 2026-10-30. Use the payments array instead. See the migration guide. - `supporter` string, nullable, required — Unique ID of the related supporter. Example events: `donation.personal_data_deleted`. - `type` 'donation.created' | 'donation.success' | 'donation.pending' | 'donation.failed' | 'donation.updated' | 'donation.refunded' | 'donation.success_early_fraud_warning' | 'donation.pending_ach_verification_required' | 'donation.pending_incomplete' | 'donation.pending_scheduled' | 'donation.pending_waiting_for_transfer' | 'donation.pending_paypal_action_required' | 'donation.pending_retrying' | 'donation.personal_data_deleted' | 'donation_benefit.updated' | 'donation.success_dispute_created' | 'donation.success_dispute_lost' | 'donation.success_dispute_won' | 'donation.success_dispute_in_review' | 'recurring_plan.activated' | 'recurring_plan.scheduled' | 'recurring_plan.failed' | 'recurring_plan.completed' | 'recurring_plan.canceled' | 'recurring_plan.terms_updated' | 'recurring_plan.paused' | 'recurring_plan.retrying' | 'recurring_plan.details_updated' | 'recurring_plan.personal_data_deleted' | 'transaction_attempt.pending' | 'transaction_attempt.success' | 'transaction_attempt.failed' | 'tribute.created' | 'tribute.updated' | 'tribute.shared' | 'tribute.personal_data_deleted' | 'supporter.created' | 'supporter.personal_data_deleted' | 'supporter.updated', required — Type of event that occurred in the system. Include donation events (for example, `donation.created`), recurring plan events (for example, `recurring_plan.activated`), transaction attempt events (for example, `transaction_attempt.success`), tribute events (for example, `tribute.created`), and supporter events (for example, `supporter.created`). [Event types explained](https://fundraiseup.com/support/api-event-types/) - `has_more` boolean, required — Indicates whether there are more records available. For `starting_after`, it shows that there is a page with older records. For `ending_before`, it indicates that there is a page with newer records. ## Other responses - `403` — Forbidden. The API key does not have permission to access events. --- [API](https://skmtc.net/fundraiseup/apis/fundraise-up-api.md) · [All operations](https://skmtc.net/fundraiseup/apis/fundraise-up-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/fundraiseup/fundraise-up-api/revisions/f59881dadecd/schema)