2018 - July Newsletter
Please be aware that several deprecated API resources will be turned off beginning in September. See the Upcoming September Changes below.
June Changes in Review
Transition from familysearch.org to api.familysearch.org
API requests to
familysearch.org began redirecting to
api.familysearch.org. Please be advised that this redirect is temporary and will be turned off in September.
GEDCOM X POST for Person Matches Resource
A new feature was released on the Person Matches Resource providing more accurate match results. This feature provides the ability to describe the person, parents, spouses, and children with a GEDCOM X document. The GEDCOM X document is to be sent through the POST method to the Person Matches Resource.
Deprecation of GET for Person Matches Resource
Please note that with the release of this improved match capability comes the deprecation of the GET method on the Person Matches Resource. It is strongly advised to migrate to the new POST method as quickly as possible. The GET method will continue to be supported for the near term, but watch for a future announcement regarding the retirement of the GET method.
Upcoming September Changes
Warning The following are changes that if ignored, could potentially break your integration.
Turning off deprecated API resources
Beginning September 18 the following API resources may be turned off, resulting in a
404 status code response.
API calls to
familysearch.org will no longer redirect to
api.familysearch.org. Please make sure your integrations are updated to point directly to
api.familysearch.org or your code will no longer function.
|API Resource Documentation||Resource Path||Link Rel||Migrate To|
Family Tree Collection Resource
|Person with Relationships||
|Relationships to Parents||
|Relationships to Spouses||
|Relationships to Children||
|Person Source References||
|Person Discussion References||
|Person Memory References||
API Integration Tips
Handling of API Responses
As your integration with the FamilySearch API processes responses, please make sure that it is prepared to handle the various HTTP status codes that may be returned by the API. In particular, a few status codes to focus on are the
401 status codes.
429 status code represents a rate-limited response. This means that your application has used up its allocated processing time and needs to wait a given interval of time before trying again. The throttled response should contain special headers indicating how many seconds to wait before you try again. Please make sure your integration does not immediately attempt a retry without waiting the appropriate time. Please see the Throttling guide for more information.
401 status code represents a request containing a missing or invalid access token. Please be aware that an access token will expire after it has been inactive for a certain period, or when it has reached its max lifespan. When you receive a
401 status code, your integration will need to reestablish a new valid access token. For more information see the Access Token Resource documentation.
The API returns
Warning headers intended to report on integration best practices, provide additional error troubleshooting information, and inform of deprecations. It may be useful to you as a developer to develop a way to log or display these warning messages in a way that doesn't interfere with your end customer experience but in a place that you as a developer will see them.