nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

New Constituent API Endpoints and Parameters

Paula Koetter

We have added and made the following changes to constituent endpoints.

The new Profile picture endpoint allows you to update a constituent’s profile picture.
You can now access the following new properties for addresses returned from the GET Address and the GET Address list (Single constituent) endpoints. These properties are also available on the POST Address endpoint and the PATCH Address endpoint.
- region
- information_source
- lot (Line of Travel)
- cart(Carrier Route)
- dpc (Delivery Point Code)
You can now access the following new properties on constituent records returned through the GET Constituent endpoint, set on the new constituents created through the POST Constituent endpoint, and edited through the PATCH Constituent endpoint.
- birthplace (Individuals only)
- ethnicity (Individuals only)
- income (Individuals only)
- religion (Individuals only)
- industry (Individuals only)
- matches_gifts (Organizations only)
- matching_gift_per_gift_min (Organizations only)
- matching_gift_per_gift_max (Organizations only)
- matching_gift_total_min (Organizations only)
- matching_gift_notes (Organizations only)
- num_employees (Organizations only)
- is_memorial
- is_solicitor
- no_valid_address
- receipt_type
- target
The Constituent node endpoint now allows you to supply an Author property.

The POST Relationship endpoint now allows you to create a non-constituent record as a relationship.

For more information, see the Constituent changelog.

Find more posts tagged with

Comments

Lindsey Rix

Steven Cinquegrana‍ Thanks for your feedback, i’ll pass it on to the team!

Steven Cinquegrana

Great thanks.

Steven Cinquegrana

No fixes are evident in the latest release Lindsey Rix‍, and, unfortunately, I don't expect to see any following advice from Ben Wong‍ that we can no longer depend on any consistency in the OpenAPI definitions. Quite disappointing, but it's your API.

Steven Cinquegrana

You've - again - blown up your OpenAPI definition:

1. AddressRead has been changed to AddressReadExtended.

2. ConstituentRead has been changed to ConstituentListItem.

As I've said many times, this is effectively a breaking change for anyone using your OpenAPI definitions to generate client code.

It also, concerningly, demonstrates that whoever is making these changes either doesn't understand their impact or isn't testing. At the very least they are providing no advance warning of the changes.

Please, please, please don't do this. Or at least don't do it without some decent advance notice. It is incredibly frustrating and creates a lot of unnecessary manual work.

If anything here isn't clear or you need further explanation of the impact, please contact me directly.

We look forward to a reversal of these changes asap.

Thank you.