Certification Overview

Certification Process Overview

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

Apps can be certified for commericial distribution or for limited use. Limited use apps require a technical review but do not need a business and marketing review and they cannot be placed in the App Gallery. Limited use apps are for personal use.

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

  • Read. There are many options available to certify for reading FamilySearch data. Your app must be certified with at least one read option before you certify to write.
  • Write. Your app can certify 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 App Certification Process

The app certification process consists of the following steps:

  1. Apply for read certification using the “Apply for Certification” 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 app with FamilySearch to monitor your app certification progress.

  4. Develop your app to read data. During development you can view the sandbox data through the FamilySearch web client at http://sandbox.familySearch.org. Sign in with the sandbox user ID and password you received when you registered as a FamilySearch partner.

  5. Your app will be evaluated as described below under App Certification Evaluation. After your app is accepted, you will receive a production app key and you can add your app to the App Gallery.

  6. Your app will be listed as certified in appropriate locations, and emails will be sent to family history center directors and family history consultants.

  7. Note: After your app is certified to read, you may then proceed to certify for writing if your app will be writing data to FamilySearch.

  8. To certify for writing to FamilySearch, when your app is near completion send an email to devsupport@FamilySearch.org to apply for Write Certification. You will receive instructions on how to apply for write certification, and how to modify your app 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 http://beta.FamilySearch.org. You will need to modify your app to authenticate for access to the beta database instead of the sandbox database. See Authentication.

Required Agreements! Your app will not be cerfitied until you have received the approved and signed copies of your Certified Web Services Agreement, your App Key Request, and your Use Agreement.

Recertification Requirement! When an app is changed to alter the way it adds, modifies, or deletes FamilyTree information, those changes must be recertified 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. An app that uses undocumented APIs will not be listed in the App Gallery, will not enjoy the benefits of being certified, and the app key issued for that app will be disabled. The continued use of undocumented APIs will jeopardize any business relationship with FamilySearch.

App Certification Evaluation

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

Product Review for Read Apps

Read certification for apps 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 application 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 Certification Checklist.

Product Review for Tree Write Apps

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.

Certification Compliance Enforcement Measures

App providers and their app(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 with certification requirements that were effective at the time of their certification or new requirements that have been effective according to the postings in the Change Log of the FamilySearch.org/developers website. When the partner adds new functionality or changes the functionality of features that write data, they must re-certify this feature.

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 certified.
  2. A new release of a previously certified feature is no longer in compliance
  3. New certification requirements have not be implemented and the effective date is past for the new changes
  4. Sufficient evidence has been presented to FamilySearch concern the app providers inappropriate business practices concerning:
    • Availability and effectiveness of support
    • Billings and collection policies
    • Not following “FamilySearch Logo and Trademark Usage Guidelines”
    • Failure to adhere to the “FamilySearch API License Agreement” (See Note 1 below)
    • Failure to comply with a “Data Quality Agreement” (when this becomes available)
  5. Availability of working app
    • Desktop or mobile app
      • Download or installation process not working
      • Unrepaired broken desktop/mobile app
    • Web app
      • ubscription 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 certification 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 application the non-compliance and timing is validate, FamilySearch will make initial contact by phone or email to comfirm that partner understands the non-compliance andwill quickly (5-7 days) remedy the situation. If the application is not quickly fixed the Enforcement Escalation will begin.

Enforcement Escalation Steps

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 “Enforcement Escalation Steps”
230 days laterNotice put in the App Galley Product Detail page and sent to the App Provider “Application 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 - Lack of Communications

Lack of communication from the partner indicates that the relationship is weakening. Normally the issue on non-compliance can be resolved without starting the Enforcement Escalation Steps.

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 partner applications that consume FamilySearch data. Data management must be a collaborative effort between FamilySearch and FamilySearch partners, 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 apps should employ the following minimum data quality practices.

  • Apps that capture data through form entries should guide the user on the intent, length, and acceptable format of entered information.
  • Apps should identify inappropriate values and give the user the opportunity to re-enter appropriate information.
  • Apps 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.
  • Apps should provide methods for users to report data inaccuracies and information abuse to FamilySearch.

Data Security Practices

All apps must employ the following data security practices.

  • Apps 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 does the following:
      - Imports a reasonable number of generations (initial pulls). 
      - Checks for needed temple ordinance work. 
      - Updates person information at the user's request (not scheduled). 
      - Does not make additional user requests after the user is gone. 
      - Allows all requests to finish that are initiated by users while they are online.
  • Apps can save genealogical information of deceased individuals retrieved by FamilySearch authenticated users.
  • Apps can save but cannot publicly share genealogical information of living ancestors retrieved by FamilySearch authenticated users.
    • Apps that save data of living or deceased ancestors must provide a way to refresh this data with current information from FamilySearch by user request or user approved automatic updates for linked and saved persons.
    • Living ancestors can only be seen, modified, and managed by the authenticated user in their own private space.
  • Apps 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.
  • Apps 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).
  • Apps 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.