Compatibility Review Process

FamilySearch will review the software you have created to determine if it is compatible with FamilySearch technology and its core mission. This review is required in order to obtain a Beta or Production API key. Only a legal, registered business or non-profit organization will be eligible for verification and listing in the Solutions gallery.

You must complete the preliminary steps outlined in the Getting Started in order to proceed with this compatible review process.

Solutions should be "Compatible" for commericial distribution.

There are two main types of compatibility you should be aware of:

  • Read. There are many options available to become Verified Compatible for reading FamilySearch data. However, your solution must be verified with at least one read option before Verified Compatible to write.
  • Write. Your app can Verified Compatible to add people, update people, write sources, write memories, or write discussions.

In addition some apps will be certified for special functions such as LDS ordinance work or bulk record handling.

The Business Approval Process

The business qualification process consists of the following steps:

  1. Apply for read compatibility using the “Apply for Compatiblity” button within the “My App” section of the developers “Logged in” experience. You will receive an email with instructions on how to proceed.
  2. Complete, sign, and return the Compatible Product Affiliate Agreement, Security Accessment, and the Production App Key Request and Use Agreement.
  3. Register your solution with FamilySearch to monitor your solution compatiblity verification progress.
  4. Your solution will be evaluated as described below under Solution Compatibility Evaluation. After your solution is accepted, you will receive a production app key and you can add your solution to the Solutions Gallery.

Note: After your solution is compatible to read, you may then proceed to apply for Write compatible, if you solution will be writing data to FamilySearch.

  1. To apply for Write compatiblity, when your app is near completion send an email to [email protected]. You will receive instructions on how to apply for write compatiblity, and how to modify your solution for new features in the FamilySearch App Gallery. If you and FamilySearch mutually agree on the need for beta testing before going public your app will be given access to our beta test data. During beta testing, your app users will access the beta database by signing in to the Beta environment. You will need to modify your solution to authenticate for access to the beta database instead of the integration database. See Authentication.

Required Agreements! Your solution will not be Verifed Compatible until you have received from FamilySearch the approved and signed copies of your Compatible Products Agreement, and your Use Agreement.

Reverification Requirement! When a solution is changed to alter the way it adds, modifies, or deletes Family Tree information, those changes must be Verified Compatible before releasing the changes to the public.

Warning Concerning Undocumented APIs! An undocumented API is an API that is not documented on the FamilySearch developer website. There is no support for undocumented APIs and there is no guarantee of the behavior or longevity of undocumented APIs. The use of undocumented APIs may create a poor user experience and affect your product stability. A solution that uses undocumented APIs will not be listed in the App Gallery, will not enjoy the benefits of being verified compatible, and the app key issued for that app will be disabled. The continued use of undocumented APIs will jeopardize any business relationship with FamilySearch.

Solution Alignment Guidelines

In addition to the technical compatibility requirements needed for accessing the FamilySearch API as set forth in the compatibility check list for each set of features, the solution will be reviewed for its alignment with the core mission of FamilySearch and the capabilities of FamilySearch APIs.

Solutions most likely to be approved include those that:2. Facilitation and contribution to FamilySearch Family Tree in the form of persons, vitals, records, and memories while following Source-Centric Open Edit (SCOE) principles.

  1. Assistance with the research process.
  2. Analysis and graphical representations not available from FamilySearch.
  3. Applications that engage the user in the research or ancestor discovery process.

Solutions least likely to be approved include those that provide:2. Appear to only read FamilySearch content without creating meaningful value to the FamilySearch website or its contributors (so, be sure to clearly explain the benefits of your solution!).

  1. Put an unusual load on FamilySearch’s ability to service FamilySearch and other third-party solutions.
  2. Duplicate capabilities already available from FamilySearch.

_Please Note:_As of June 27, 2017, FamilySearch is suspending the certification and approval of new applications that provide functionality for scanning, capturing or reporting (or any combination of the three) of ordinance information, including those that are or may be available to take to the temple. As we evaluate the impact of these types of applications on the FamilySearch systems and the end-user experience; this suspension will remain in effect until further notice. Solutions that request limited read-access privileges may be considered based upon need and functionality.

Solution Compatiblity Evaluation

Each app submitted for certification will be evaluated on the following criteria.

Product Review for Read Solutions

Read compatiblity for solutions includes the following product review:

  • Reviewing screen shots of the product, a recorded demonstration of the product, or a working URL beta site.
  • A product review board examination of general usability of the product for its intended audience. Required features for a given solution or utility will be checked to see if these are in compliance. This is usually done by a demo and a live interview.

Important! A review is performed separately to certify each type of read operation your app performs. See the Read Compatiblity Checklist.

Product Review for Tree Write Solutions

Tree Write certification for apps includes an extended product review, a technical review, and a security review. Sometimes the business, product, and technical review can be done in one meeting. The security review is always a separate activity scheduled and performed by the security team.

Extended Product Review

As with a read only app, the product review board examines the general usability of the product for its intended audience. The required features for a given application or utility are checked to see if these are in compliance. The app is also evaluated for adherence to Source Centric Open Edit (SCOE) standards. This usually requires a demo followed by a live interview.

Technical Review

Technical reviews are used to determine what programmatic calls are being made to get various responses presented through the user interface. Various use cases are often tested to make sure the logic is in place to accommodate most possibilities. Sometimes the product review and the technical review are done in the same meeting. Applications for write certification usually take multiple meetings to see everything and go through all of the use cases that can be encountered when interfacing with a large collaborative family tree.

Security Review

A security check of web, desktop, and mobile applications is done by FamilySearch software security personnel. These are done by request, and the partner does not attend or participate in any way except to provide the app URL if it is a web app, the installable software if it is a desktop app, or a mobile device with the software already installed if it is a mobile app. The reviewed items are covered in the authentication requirements for web, desktop, and mobile.

Compatibility Compliance

Solution providers and their solutions(s) that have write access to production data through an issued App Key will be checked from time to time to see if they are in compliance 1.)Compatibility requirements that were effective at the time of their compatiblity verification or 2.) new requirements that have been effective according to the postings in the Change Log of the FamilySearch.org/developers website. When the solution provider adds new functionality or changes the functionality of features that write data, they must re-verify this feature.

FamilySearch Compatible Logo Use Requirements

The “FamilySearch Compatible” logo must be displayed within the web, desktop, or mobile solution. This logo can be used with sign-on screen for desktop and mobile solutions using “password flow” method for authentication. It can also be used for promotional purposes on websites and other marketing material to promote the status of the solution. In all cases, the use of the “FamilySearch Compatible” designation should include a rollover message or link to the FamilySearch Compatible disclosure statement. Printed material displaying using the “FamilySearch Compatible” designation or logo must have an asterisk to reference the full disclosure at the bottom of the page.

FamilySearch Compatible Disclosure

“FamilySearch Compatible” designation and logo is used to identify software solutions that FamilySearch International (“FamilySearch”) believes to be generally compatible with FamilySearch.org or one or more of FamilySearch’s APIs (application programming interfaces). FamilySearch, however, takes no responsibility and is in no way liable for any such solution. Accordingly, FamilySearch in no way warrants that any solution associated with this designation or logo will function as intended, is free from harmful or undesirable aspects, or is free from errors.

Non-Compliance Situations

If the app or app provider is found to be out of compliances, measures will be taken to motivate the app providers to bring the app back in to compliance. This includes the following situations:

  1. Using a feature that has never been Verified Compatible.
  2. Issuing a new release of a previously compatible feature that is no longer in compliance.
  3. New Verified Compatible requirements have not be implemented within an expected timeframe.
  4. 4. Solution provider fails to meet contractual requirements regardomg:
    • Availability and effectiveness of support
    • Billings and collection policies
    • FamilySearch Logo and Trademark Usage Guidelines”
    • FamilySearch API License Agreement” (See Note 1 below)
    • Data Quality Agreement (when this becomes available)
  5. Availability of working solution
    • Desktop or mobile solution
      • Download or installation process not working
      • Unrepaired broken desktop/mobile solution
    • Web solution
      • Subscription process not working
      • Frequent downtime or unacceptable performance

Determining Non-Compliance

In addition to periodical compliance auditing of existing certification requirements, FamilySearch will check compliance on those applications that are affected by new compatibility requirements according to the effective date posted in the Change Log. FamilySearch will also respond to any reports of non-compliance by employees, partners, or customers. If after reviewing the desktop, mobile, or web solution the non-compliance and timing is validate, FamilySearch will make initial contact by phone or email to comfirm that partner understands the non-compliance will be resolved quickly (5-7 days). If non-compliance is not resolved within this timeframe, the Compliance Motivation Steps may begin as follows:

Compliance Motivation Steps

StepTimingAction
0Inital ContactInformal notification and request by phone or email to quickly (5-7 days) remedy (See Note 2 below)
110 days laterNon-compliance notification letter sent with “Compliance Motivation Steps”
230 days laterNotice put in the Product Detail page and sent to the Sp;itopm Provider “Solution is no longer compatible with FamilySearch”
330 days laterApp is pulled from the App gallery and notice sent to the App Provider
430 days laterApp Key is turned off until sufficient evidence is provided concerning how the non-compliance has been rectified
5TBDApp Key is turned on after correction is validated

Note 1 - Termination Section 6 of FamilySearch API License Agreement

FamilySearch reserves the right to terminate this Agreement or suspend or discontinue Your access to the API, or any portion or feature thereof, for any or no reason and at a time with or without notice to You and without liability to You. Upon the early termination of this Agreement, Your App Key shall be revoked, and all licenses granted hereunder shall terminate.

Note 2 - Prompt Resolution

Typically, non-compliance issues can be resolved quickly without triggering the “Compliance Motivation Steps”. Please respond promptly to any communication you receive from FamilySearch.

Data Management

The volume, accuracy, security, and interoperability of the data in the FamilySearch Family Tree is extremely important to customers of FamilySearch and FamilySearch partners. The responsibility for data management is shared and should follow established best practices.

Shared Responsibility

The main attraction to FamilySearch is the value of its Family Tree and historical records to customers. Inaccurate, inappropriate, and damaging data can degrade the usefulness of the FamilySearch website and solutionis that consume FamilySearch data. Data management must be a collaborative effort between FamilySearch and FamilySearch solution providers, assisting users in how they complete, submit and report abuses of information. Everyone benefits from working together to manage the data in FamilySearch.

Data Quality Practices

All solutions should employ the following minimum data quality practices.

  • Solutions that capture data through form entries should guide the user on the intent, length, and acceptable format of entered information.
  • Solution should identify inappropriate values and give the user the opportunity to re-enter appropriate information.
  • Solution should follow industry best practices for security related to both software and data. For example, consider owasp.org for web app security to prevent attacks, code injections, and other vulnerabilities.
  • Solutions should provide methods for users to report data inaccuracies and information abuse to FamilySearch.

Data Security Practices

All solutions must employ the following data security practices.

  • Solutions can only show living and ordinance information to the FamilySearch authenticated user who requested the information.

  • Deceased non-ordinance information can be shared with any FamilySearch authenticated user.

  • Local browser cached data from FamilySearch must be cleared at the end of the browser session. Likewise, requesting browser history or using the browser back button cannot reveal FamilySearch data that was previously accessed.

  • Long Running Task Completion is allowed with the following limits.

    • Periodic checking for person updates is not a single long running request.

    • The FamilySearch session must be expired after the user is gone except when the user starts a single long running request. A single long running request may do the following:

      • Import a reasonable number of generations (initial pulls).
      • Check for needed temple ordinance work.
      • Update person information at the user's request (not scheduled).
      • Allow all requests to finish that are initiated by users while they are online.
  • Solutions can save genealogical information of deceased individuals retrieved by FamilySearch authenticated users.

  • Solutionscan save but cannot publicly share genealogical information of living ancestors retrieved by FamilySearch authenticated users.

    • Living ancestors can only be seen, modified, and managed by the authenticated user in their own private space.
  • Solutions can save FamilySearch person ID numbers of persons needing ordinance work, but not the ordinance data. Persons needing ordinance work cannot be shared with users who have not already reserved the person. In order for a different user to view a saved person ID needing ordinance work, the user must have the permission to view LDS information.

  • Solutions can cache boolean metadata indicating which ordinances are needed. The app cannot display this metadata to the user until the "View LDS Information" permission is verified for that user session (once per new session).

  • Solutions cannot store any LDS Ordinance dates or places as a "Presence Event" to show that the individual was present in a specific location on a specific date.