GuidesAPI ReferenceChangelogHelp
Changelog
Start typing to search…
Back to All

2024 Q3 Newsletter

about 1 year ago by David

This edition covers changes to the facts available on living persons and upcoming enhancements to the response when updating persons.

Scheduled Maintenance

Current User data getting internal update

The internal data service that supplies the Current User and Agent endpoints has been deprecated. An updated internal service is available, but the format of this data is slightly different. This service update is to notify you that when this internal change is switched in the next few weeks, the same general data fields are available but may be different than what is expected. This is not expected to be a breaking change.

Person data for LIVING changing due to privacy requirements

In the next few weeks, the behavior for storing and retrieving LIVING Person Conclusions is changing to due privacy requirements for the following FACTS and EVENTS:

  • FACTS: National Identification, Race, Tribe
  • EVENTS: Bar Mitzvah, Bat Mitzvah, Religious Affiliation

The service will continue to accept and store this data without issues, however for LIVING Persons, these Conclusions will be flagged as SENSITIVE and the endpoint will not return any of these Conclusions. These Conclusions will continue to be stored, but not available through the API or the FamilySearch website. No errors will be returned in the http response. This notification is to make sure that you are aware of the sensitive nature of this data and how your users may be expecting your application to function with the FamilySearch API.

Upcoming Changes

Person UPDATE Enhancement [IMPORTANT!]

NOTE: To accommodate the nature of this breaking change, the final release of this behavior change to Production has been deferred from Oct 1 to as early as Dec 1. This enhancement is available today by adding a Pending Modification Experiment (return.conclusion.ids) to the request. (Original notification was made in the 2024 Q2 Newsletter)

The response for a successful POST to the Person endpoint has been simplified so that the handling of this response will enable your application to obtain the Event Conclusions IDs without making additional requests.

  1. Depending on how many conclusions were written, the status code was a 201 or 204. Now, the only response code for a successful post will be a 200.
  2. For a single successful conclusion, the Conclusion ID was included in an X-Entity-Id header. Now, all Conclusion IDs will be returned in the response body no matter how many conclusions were written.