Interpret imported-gift API fields and replacement behavior

POST creates an imported gift associated with the supplied school's person ID; it does not create a new payment charge. The path rejects an existing transaction ID within that school's imported gifts. That check is not proof of automatic deduplication against every native GiveCampus payment. Agree a source/identity strategy before importing overlapping history.

Gift value is the imported gift amount; each designation amount is its allocation. The schema does not define whether the caller should subtract incentive FMV, nor does its payment_date example specify a required timezone. Confirm those integration semantics before loading production data. payment_date means the date the organization considers the payment successful, and the field requires a valid date after 1900. Do not silently invent a timezone convention.

source is a string describing how payment was made; the field does not have a fixed list of allowed values. Imported designation selections store a separate name, backend identifier and amount. Creating them does not rename the school designation master. Matching school backend identifiers can link imported selections to existing designations; the API path does not create a new form designation merely because an unknown identifier was supplied. Check saved result selections rather than assume all links were resolved.

custom_fiscal_year is an optional integer greater than 1850. It is used by donor-status recalculation to place the gift in the specified school fiscal year instead of relying only on payment_date; it is not an unused note field.

PUT requires the documented complete field set for that API version and replaces designation selections. An empty designation array removes those selections. Review the returned results before retrying. The POST and PUT paths differ in the write-in input key they consume, so confirm that detail with integration support before relying on write-in round trips. Confirm gross versus net amounts, time zones and cross-system duplicate handling with your integration and finance teams.

Deleting imported gift history

The public imported_gifts routes expose GET, POST and PUT, with no DELETE endpoint. PUT replacement of fields/designations is not deletion. Ask authorized data support to review removal of an imported-history record and its upstream source so a later import does not recreate it. Do not refund a native payment or submit an invented zero gift as a substitute for deleting imported history.