Changelog

Release 26.08.0

Integrators: New minStatusUpdatedOn and maxStatusUpdatedOn Parameters for Transaction Endpoints

Tenant Administrators → Learn More

Give Employees → Learn More

Overview

Six transaction API endpoints now support minStatusUpdatedOn and maxStatusUpdatedOn query parameters, letting integrators filter transactions by when their status last changed rather than only by when they were created.

Previously, integrators could only filter transactions by creation date, which made it difficult to detect transactions whose status changed after the fact (for example, a transaction that was created earlier but only recently cleared or failed). Starting with release 26.08.0, integrators can filter directly on the status-updated date across contributions, grants, installment grants, transfers, operational transactions, and returns.

Integrators: Webhook Events for Contributions, Grants, Transfers, and Money Movement (Part 1)

Tenant Administrators → Learn More

Give Employees → Learn More

Overview

Give now sends webhook events when a Contribution, Grant, Transfer, or Money Movement detail is created, updated, or changes status. Previously, API clients had no way to be notified of these changes in real time and had to repeatedly poll and diff responses to detect them.

This is Part 1 of a broader webhook rollout covering 10 resource types; this release covers 4 of them. Return, Grant Series, Contribution Series, Batch, Administration Fee, and Investment Management Fee do not send events yet and are planned for a future release.

Each event's data payload contains the complete resource as it exists after the change, using the same field names and meanings as the existing REST response for that resource. Events do not include the prior version of the resource or a list of what changed, and existing records are not backfilled: events begin only with changes made after this release deploys.

Integrators: New minClearedOn and maxClearedOn Parameters on the List Admin Fees Endpoint

Tenant Administrators → Learn More

Give Employees → Learn More

Overview

The List Admin Fees endpoint now supports minClearedOn and maxClearedOn query parameters, letting integrators filter admin fees by the date they were actually cleared rather than the date they were created.

Previously, integrators syncing fee data could only filter by creation date using minCreatedOn. This made it difficult to reliably capture fees that were still pending at the time of a given integration run and only cleared afterward, those fees could be missed entirely if the integration's cursor had already moved past their creation date.

Starting with release 26.08.0, integrators can filter directly on the cleared date, making it possible to pick up fees once they are actually paid and complete, regardless of when they were originally created.

Release 26.07.0

Integrators: Deny Grant via REST API

Tenant Administrators → Learn More

Give Employees → Learn More

Overview

The Give REST API now includes an endpoint to deny a grant programmatically. The new POST /api/v1/transactions/grants/{id}/deny endpoint accepts grants in SUBMITTED, IN_DUE_DILIGENCE, or IN_REVIEW status and returns the updated grant object with a DENIED status. This allows integrators to build denial workflows without requiring manual action in the Give admin portal.

Integrators: Ending Balance Added to Statement Metadata API

Tenant Administrators → Learn More

Give Employees → Learn More

Overview

The GET /statement-periods/{id}/documents endpoint now returns a new statementEndingBalance field in the response metadata. This is a fully additive change — no existing fields are modified or removed. Integrators can use this field to display or reconcile the ending balance for a statement period without making a separate request.

Integrators: Soft Credit and Joint Donor Attribution via Contributions API

Tenant Administrators → Learn More

Give Employees → Learn More

Overview

The Contributions REST API now supports assigning additional donor attributions at the time of contribution creation or update. A new donorAttributions array is accepted on POST /transactions/contributions and PATCH /transactions/contributions/{id}. The array supports Soft Credit and Joint Donor attribution types. When using the PATCH endpoint, the full donorAttributions array is replaced with each request.

Integrators: destinationGLAccountId — Standardized Property Name Across Contribution API Endpoints

Tenant Administrators → Learn More

Give Employees → Learn More

Overview

The Give REST API now uses a single, consistent property name for the destination GL account across all Contribution API endpoints. The canonical property name is destinationGLAccountId. The legacy property name destinationAccountId is still accepted but has been deprecated — requests using it will receive a deprecation warning in the response. Sending both properties with different values in the same request returns a 400 error.

Integrators: Give REST API Documentation Has Moved to Scalar

Tenant Administrators → Learn More

Give Employees → Learn More

Overview

Starting with release 26.07.0, the Give REST API documentation is hosted at Scalar instead of Stoplight. The documentation itself - endpoints, fields, parameters, and schemas is unchanged. What changed is where you go to read it.

Stoplight served as the primary API documentation host since the Give REST API was first published. Over time it became unreliable when publishing updates after releases, difficult to extend with guides and supplemental documentation, and slow to use. Scalar provides a faster, cleaner interface, native support for multiple API versions side-by-side, the ability to add markdown-based guides alongside the reference documentation, and an MCP integration that allows AI tools to consume the docs directly.

Stoplight will remain available for approximately six months after this release as a transition period. A banner on the Stoplight site will direct visitors to the new Scalar location. After the transition window closes, Stoplight will be decommissioned.

Release 26.06.0

Integrators: Investment Balance Details - Price per Unit and Number of Units

Learn More: Tenant Administrators | Give Employees

Overview

The GET /api/v1/funds/{id}/balances and bulk GET /api/v1/funds/balances endpoints previously returned each investment balance as a single net dollar figure, with no mechanism for API consumers to see the underlying securities, unit counts, or price-per-unit that composed the balance. For integration partners reconciling fund balances against custodial records, this created a data gap: the API could tell you that a fund held $250,000 in a pool account, but could not explain how many units at what price produced that figure.

This change adds a balanceDetails array and a companion balanceDetailsStatus enum to every item in the investmentBalances array returned by both endpoints. These new fields are always present in the response — no opt-in parameter is required. Both endpoints are updated identically.

Integrators: Update Operational Expense and Revenue Transactions via API

Learn More: Tenant Administrators | Give Employees

Overview

The Give REST API previously supported creating Operational Expense and Operational Revenue transactions through the existing Create Operational Transaction endpoint, but provided no mechanism for updating those transactions once created. If an operational transaction was entered with an incorrect amount or date, the only correction path was a manual process outside the API, typically involving a support request or a file-based upload, which did not scale for organizations running high-volume automated workflows.

This change introduces a new Update Operational Transaction endpoint modeled on the structure of the existing Create endpoint. Integrations can now submit corrections to the amount and/or date fields of an existing operational transaction without recreating the record. The response returns the updated transaction in the same format as the Get Operational Transactions List, giving integrations an immediate confirmation of the updated state.

Integrators: Add Grant Cash Out postedOn Timestamp to Get Grants List

Learn More: Tenant Administrators | Give Employees

Overview

The GET /api/v1/transactions/grants (Get Grants List) endpoint previously included a clearedOn field to indicate when a grant payment was finalized. However, clearedOn represents the bank clearing date — the date the bank marked the transaction as settled — which is distinct from the date the batch containing the grant's cash-out was actually posted in Give and the fund balance was reduced.

For integration partners using clearedOn as a proxy for grant completion, this distinction created a data accuracy gap. In practice, the bank clearing date can precede or follow the Give batch posting date, meaning downstream systems that populated a "completed date" from clearedOn could end up with a date that did not correspond to when the fund balance actually moved. Integration partners that used clearedOn as a proxy for grant completion experienced this discrepancy directly: downstream systems populated a completed date from the bank clearing date rather than the Give posting date, causing the donor-visible balance to appear to fluctuate in ways that seemed incorrect when the two dates did not align.

This change adds a new response field, postedOn, to each grant record in the Get Grants List response. The value is the timestamp from the batch that contains the grant's CASH_OUT transaction detail, specifically from batch.source_info -> 'postedOn'. This is the precise moment at which Give posted the batch and the fund balance was reduced. Integrations can now use postedOn to accurately represent when the grant cash-out took effect in Give, eliminating the timing discrepancy introduced by relying on the bank clearing date.

Integrators: Add transferType Filter to Get Transfers List Endpoint

Learn More: Tenant Administrators | Give Employees

Overview

The GET /api/v1/transfers (Get Transfers List) endpoint previously returned all transfer records regardless of the underlying transfer type, with no mechanism for API consumers to isolate grant-related transfers from general fund-to-fund transfers. Integration partners consuming this endpoint received a mixed dataset and were required to handle the separation logic on their own side, introducing additional processing overhead and the risk of misclassification.

This change adds a new optional query parameter, transferType, that allows API consumers to scope the response to only the transfer type they care about. When provided, the filter is applied server-side before pagination is calculated, meaning all count and cursor values accurately reflect the filtered dataset, not the unfiltered total.

Release 26.05.01

Integrators: Blackbaud Financial Edge NXT Now Includes Additional Journal Entry Custom Fields

Tenant Administrators → Learn More

Give Employees → Learn More

Overview

Give's Blackbaud Financial Edge NXT integration now includes nine custom fields on journal entries posted from Give. These fields surface transaction context — including Give identifiers, payment details, and linked project or vendor information — directly within Blackbaud FE NXT, supporting reconciliation, reporting, and operational workflows without requiring manual cross-referencing between systems.

Previously, journal entries posted to Blackbaud FE NXT did not include Give-specific transaction identifiers or payment details, requiring organizations to manually match transactions between systems during reconciliation.

The nine new fields are applied automatically when Give posts journal entries — no configuration changes are required. Fields include Give Batch ID, Give Transaction ID, Payment Method, and Payment Number for all transaction types, with additional conditional fields for transfers (Related Project ID and Description), grants (Related Vendor ID and Description), and New Horizons Foundation only (FDR).

Note: All existing Blackbaud FE NXT journal entry fields and posting behavior remain unchanged. These fields are additive and do not affect existing reconciliation logic or journal entry structure. The FDR field applies to New Horizons Foundation only.

Release 26.05

Integrators: NHF API Recurring Grant Series Endpoints (Create, Edit, Cancel, List)

Tenant Administrators → Learn More

Give Employees → Learn More

Overview

The Give REST API now supports the full lifecycle of recurring grant series, allowing integrations and custom donor portals to create, retrieve, update, cancel, and manage recurring grants programmatically.

Previously, the API only supported one-time grant operations. Organizations using custom donor portals or integrations could not create or manage recurring grant schedules through the API and were required to rely on the Give Admin interface for recurring grant management.

With this enhancement, recurring grants now have the same level of API support as one-time grants. Integrators can create recurring grant schedules, retrieve generated grant instances, update recurring grant amounts and end conditions, and cancel future recurring grants directly through the API.

Note: Existing one-time grant endpoints and grant processing workflows remain unchanged. This enhancement introduces a new set of recurring grant series endpoints alongside the existing grant APIs.

Release 26.04

Integrators: REST API CurrentBalanceUpdatedOn

Click HERE to learn more.

We’re updating the Get Fund Balances API so you can tell the difference between:

• a fund balance being refreshed/updated (even if the value stayed the same), and
• a fund balance actually changing (the value is different than before).

This helps integrations process only funds with real balance changes, instead of reprocessing every fund after nightly refreshes.

Integrators: REST API Changes for Managing Fund Users and Status

Click HERE to learn more.

We’ve expanded the Funds REST API so that your internal systems and integrations can fully manage the relationship between funds and fund users (contacts), and can control the status of a fund over time.

The API now supports:

1. Remove a user from a fund
2. Update a fund–user relationship (role or relationship details)
3. Clarified documentation for the existing “Create fund user” endpoint
4. Update a fund’s status through the “Update fund by ID” endpoint

These changes are additive: existing integrations that don’t call the new endpoints or new fields will continue to work as-is.

Note: Admins must have client_credentials for authentication.

Integrators: REST API Functionality to Disable/Reenable Fund Investments

Click HERE to learn more.

We’re adding a new REST API capability that allows customers to disable/reenable a specific fund investment for a fund.

Previously, once an investment was associated with a fund, there was no way to disable that investment via the API when a donor no longer wanted that investment. With this enhancement:

• A new REST API endpoint, Update Fund Investment Status, Give Admins with client_credentials for authentication can:
  • Disable a fund investment (so it no longer appears in the UI or standard API responses), or
  • Re-enable a previously disabled investment.
• Disabled investments are excluded from standard Get fund investments list responses and from the UI, unless explicitly requested.
• Every status change (disable/reenable) is logged in event history for auditability.

Release 26.03

Institution Account Positions/Transactions API

We’ve introduced new APIs to support deeper integration with institution account data, enabling management of bank-side transactions and positions.

What’s new:

• Bank-Side Transactions APIs
  https://{env}.giveinteractive.com/api/v1/banktransactions
  • Create bank-side transactions (POST)
  • List bank-side transactions (GET)

• Bank-Side Positions APIs
  https://{env}.giveinteractive.com/api/v1/bankpositions
  • Create bank-side positions (POST)
  • List bank-side positions (GET)

Scope:

• Available for Institution Accounts

Why it matters:

• Streamline ingestion of external banking data
• Improve reconciliation between bank and platform records
• Enable more robust reporting and data synchronization workflows

Merge User Profiles

We’ve introduced a new API to help consolidate duplicate or related user records into a single, unified profile.

What’s new:

https://{env}.giveinteractive.com/api/v1/users/{id}/merge

• Merge two user records into one
• Retain a designated primary user while merging data from the secondary record
• Preserve associated data such as transactions, relationships, and history

Why it matters:

• Maintain cleaner, more accurate user data
• Eliminate duplicates and reduce data fragmentation
• Simplify reporting and downstream integrations

Release 26.02

Contribution API Standardization & Tax Lot Alignment

In line with security contributions enhancements, we have made updates to standardize the Contribution API and align Tax Lot functionality.

What’s New
The Contribution API has been updated to expose standard enhancements to security contributions sale proceeds, providing a reliable "single source of truth" for external systems. This includes new fields and updated naming conventions to better align with our Tax Lot data model. 

How it Works

• Response object: A new total_sale_proceeds field has been added to the Contribution response. It dynamically pulls either the system-calculated sum (for Tax Lots) or the stored manual value (for historical records).
• Updated Schema: Within the Tax Lot payload, the field totalProceeds has been renamed to totalSaleProceeds for global consistency.
• Partial Sell Support: The API now accurately reports the sum of all sell amounts to date, regardless of whether a lot is partially or fully sold.

Impact
Consuming systems can now rely on a single, authoritative field for gross proceeds without needing to perform manual calculations or reconcile disparate data points. Please refer to GIVE API Documentation

Allow Processing Fee on Contribution Create API

In this release, we have enhanced the Create Contribution API endpoint to accept an optionalfeeAmountparameter, aligning its behavior with the Update Contribution endpoint.

What’s New

• Endpoint: Create Contribution API
• New Parameter: feeAmount
  • Type: number
  • Optional: Yes
  • Functionality
• When feeAmount is provided, it is processed in the same manner as in the Update Contribution API.
• If feeAmount is null, it is treated as if the parameter was not provided.
• If omitted, the API behaves as before.

This change is fully backward compatible. Existing clients that do not send feeAmount will experience no change in behavior. For more information, please refer to GIVE API Documentation.

Add Ability to find Grant Divestment status from API

In this release, we have exposed Grant divestment details through the API to support enhanced Treasury Management and improved visibility into grant payments. We have also updated the batch response to include the actual bank date of the transaction in the financial account, both source and destination.

Updated Grant Endpoints

The following endpoints have been updated:

• Get Grants by ID
• List Grants

(New) Divestments Response Object

A new divestments array has been added to grant responses, containing the following fields:

• amount
• onHold(boolean)
• status
  • PENDING – Divestment created but not batched
  • PENDING_RECONCILIATION – Batched but not posted on both source and destination
  • COMPLETE – Batched and posted on both source and destination
  • CANCELED – Divestment canceled
• sourceGLAccountId
• destinationGLAccountId
• batch – Standard batch response object (see updates below)

(Updated) Batch Response Object

The batch response object now includes actual bank posting dates for financial accounts:

• sourceAccountClearedOn – Date the source transaction posted
• destinationAccountClearedOn – Date the destination transaction posted

These fields reflect bank activity dates and are independent ofbatch.clearedOn

If you would like to see grant divestment status through the API, please reach out to your account manager. Please refer to the Give API Documentation for the API updates.

Enhanced Grant API to include Sub Type

In this release, we have enhanced the Grant Create & Update APIs to support an optional subTypefield to enable subtype-based communication and processing.

What's New:

• The subType field (string) is now accepted in the request body for:
  • Create Grant
  • Update Grant
• The subType field is now included in the response for:
  • Create Grant
  • Update Grant
  • Get Grant List
  • Get Grant By ID

Functionality

This enhancement enables subtype-driven workflows while maintaining compatibility with existing API integrations. For more details, please refer to the Give API Documentation.

Release 25.08

Reissue Grant Payment

The Reissue Grant Payment endpoint has been updated to include additional details when a grant payment is reissued, including the original check number and the newly generated check number.

payment: {paymentDate: <date>paymentNumber: <integer>reissueDate: <date>reissuePaymentNumber: <integer>}paymentDate - Date of original grant payment paymentNumber

- Original check number of grant, if applicablereissueDate - Date of most-recent reissued payment, if applicablereissuePaymentNumber - Check number of most-recent reissued payment, if applicable

Money Movements Endpoints

A new API endpoint has been added to allow bulk creation of money movements within the platform. This endpoint enables users to create multiple money movements in a single request, with validations to ensure data integrity.

Endpoint Details:

• Method: POST
• Path: /transactions/money-movements
• Body: Array of moneyMovementInput objects

Functionality:

• Creates multiple money movements in bulk.
• Returns a success message including the number of money movements created.

For more details, please refer to the Give API Documentation.

Contribution Endpoints Enhancement

We have updated the contribution list (GET /transactions/contributions) and detail (GET /transactions/contributions/{id}) endpoints to add Tax Lot information to the response data IF the paymentType of the contribution is SECURITY.

securityTaxLot object

Field Name	Data Type	Always included in response
securityName	string	Yes
tickerSymbol	string	No (Security may only have CUSIP)
cusip	string	No (Security may only have ticker)
totalProceeds	number	Yes
unitsContributed	number	Yes
unitCost	number	Yes
totalCost	number	Yes
unitsRemaining	number	Yes
latestUnitPrice	number	Yes
latestValue	number	Yes
latestValueAsOf	date	Yes
sellLots	Array of sellLot objects	Yes (could be empty array)

sellLotobject

Field Name	Data Type	Always included in response
id	string	Yes
amount	number	Yes
units	number	Yes
unitPrice	number	Yes
accountedOn	date	Yes

Release 25.07

Return Transaction Endpoints

What’s New:
The Give API has been enhanced to include new endpoints for Return Transactions, allowing integrated systems to create, retrieve, and manage returned contributions directly through the API.

Why It Matters:
This update expands API functionality to provide a more complete view of the donation lifecycle. It enables external systems to accurately reflect returned or refunded transactions without manual intervention.

How It Works:

• New API endpoints are available for Return Transactions, supporting standard operations such as retrieval and status tracking.
• Returned contributions can now be programmatically linked to their original transactions for accurate reconciliation.
• Responses and data structures align with existing Give API conventions for consistency and ease of use.

Impact:
Developers and integration partners can now maintain full parity between the platform and external systems by managing both active and returned transactions through the API.

Pledges & Campaigns Endpoints

What’s New:
We’ve expanded our API capabilities with new endpoints for Pledges and Campaigns, enabling developers to integrate, manage, and report on these objects programmatically.

Why It Matters:
These new APIs allow external systems to seamlessly connect with pledge and campaign data, supporting deeper integrations for fundraising management, analytics, and donor engagement workflows.

How It Works:

• Pledge API: Enables the creation, retrieval, updating, and tracking of pledges, including amounts, schedules, and fulfillment status.
• Campaign API: Provides access to campaign details, goals, progress, and related pledge or contribution activity.
• Both APIs follow existing authentication and response standards for consistency with other platform endpoints.

Impact:
Organizations and integration partners can now automate the management of pledges and campaigns, synchronize data across systems, and enhance reporting accuracy — all through the API.