Look up a place in the FamilySearch gazetteer.

Resolves a bare place name to its full jurisdictional form and coordinates, which is what a properly-formed place record needs. Each result carries a place id you can pass to get_place or get_place_jurisdictions.

If the place name comes from a record with a date on it, prefer search_places_at_date: jurisdictions change, and the modern answer is often the wrong one.

Works without credentials.

Resolve a place as it existed in a particular year.

Jurisdictions are not stable. Counties are created, split, renamed and abolished, so a record naming a county that no longer exists is ordinary rather than an error. Filing that record under the modern county that now covers the ground is a common mistake, and an invisible one: the place name still looks plausible, but it sends the next search to the wrong courthouse and the wrong record set.

Give it the name as the record spells it and the year of the record. Each result carries the span over which that jurisdiction existed, so you can see whether it was the right one at the time.

Works without credentials.

Read one place: its jurisdictional chain, type, coordinates and dates.

The dates are the ones that matter for research. A place description records the span over which that jurisdiction existed, so you can check whether the county a record names was the county in being on the date the record was made.

Works without credentials.

Walk a place's containment chain upward to the country.

This is what turns "Kaskaskia" into "Kaskaskia, Randolph, Illinois, United States". The chain is returned innermost first, each level carrying its own id, type and the span over which it existed, so you can see at which level the naming changed.

Works without credentials.

Search historical records by name, events, relatives, type or collection.

Relationship criteria find a man by his wife's or father's name when his own was misindexed. Scoping to a record type or one collection searches one register instead of the whole archive.

Every criterion filters, loosely: a record lacking that field still matches, names match variants, years match within 5, places widen. With exact, each must be on the record and match. The result's filters says which criteria were applied exactly, relaxed or ignored, and how: read it before calling a nil result a negative.

Pass at least one name. Requires an access token.

Search the machine-read text of page images: deeds, wills, probate, court files.

Finds a name or phrase anywhere on a page, including the witnesses, heirs and neighbours no index names. Each hit is one page image, with the passages that matched.

The text is handwriting recognition, a machine reading: open the image with get_image_links, read it yourself, and cite the image, never the text. Coverage is partial, so no result proves nothing. Each hit gives the citation path: collection, record title and image ark.

Requires an access token.

Read one indexed record in full.

A search returns a persona: one person's summary of what a record said. This returns the record, which is more: every person named on it, and the indexed fields behind each of them, labelled with the box on the original form each value was read from.

The fields are where a search summary loses things -- the informant, the witness, the enumerator's spelling, the age that contradicts the birth year.

Each fact gives its value, date and place as FamilySearch reads them, and under original what the indexer transcribed ("M" for "Married"). A date or place with no original was supplied by FamilySearch, such as a birth year worked out from an age.

This is still the index, not the document. Use get_record_image to reach what was actually written.

Requires an access token.

Find the document image an indexed record was taken from.

The persona is somebody's reading of the record. The image is the record. Indexers mis-read hands, skip columns, normalise spellings and guess at ages, so anything that matters should be checked against the film.

Returns whatever the record offers as a route to the image: image and waypoint links, and the digital film (DGS) and image numbers indexed against it. Many records carry no image link at all, in which case this says so rather than inventing one -- a great deal of the archive was indexed from microfilm that has never been published, and the answer is then to read the citation and order the film.

Requires an access token.

Find a record collection, so a search can be scoped to one.

A collection is one register, census or index. Scoping search_records to its id turns a fishing expedition into a lookup, and a nil result into something that means anything.

Each result carries a coverage statement: record types, place, years. Read it: a collection covering 1850 to 1900 cannot answer for 1840.

Every word must match a whole word of the title; titles where one only matches inside a word ("Indian" in "Indiana") follow, marked. The first call reads the whole catalogue and caches it; catalogue says how many collections it holds and how old it is.

Works without a token.

Read one record collection: what it covers, and how much of it there is.

Worth reading before trusting a nil result. The counts say how many records, people and images the collection holds, and a collection whose image count is far below its record count was indexed from film that was largely never published.

Works without a token.

Read one person from the FamilySearch shared tree.

Returns names, sex and facts. Use it to find records: get_person_sources on the same id is usually the next call, because it leads out of the tree towards a document.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Read a tree person's parents, spouses, children and siblings.

One call for the whole immediate family, which is what you need to judge whether a profile is the person you are looking for. A family that does not fit -- a child born before the marriage, a wife with the wrong surname, parents twenty years too young -- is the usual first sign of a conflation.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Walk a tree person's pedigree back through the generations.

Each person carries an Ahnentafel position: 1 is the person asked about, 2 and 3 their father and mother, 4 to 7 their grandparents, and so on -- so a flat list reads as a tree, and a gap is visible as a missing number.

The further back a pedigree runs the less of it is sourced. Lines beyond about five generations are frequently copied rather than researched, and a long unbroken pedigree is a reason for more suspicion rather than less.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Walk a tree person's descendants forward through the generations.

Useful for the sideways search: when a person's own record cannot be found, a descendant's obituary, probate or pension file often names him.

Living descendants are withheld and come back marked as restricted.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Read the sources attached to a tree person.

This is the most useful thing in the tree, because it is the way out of it. Each attached source carries a citation and usually an ark pointing at an indexed record, so a profile that seemed unsupported becomes a list of documents to read.

Each source also carries what it is said to support -- Name, Birth, Death -- which distinguishes "this person has sources" from "this person's death date has a source". A profile with ten sources, none of which touch the fact you care about, has told you nothing about it.

A profile with no sources at all is not evidence of anything. It is somebody's assertion, and should be treated as one.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Read the photographs and documents attached to a tree person.

Memories are uploads: a headstone photograph, a scanned letter, a family Bible page, a typed story. Some are primary documents worth citing; others are a relative's recollection written down eighty years later. What each one is depends entirely on what was uploaded, so look before relying on it.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Read the change log of a tree profile: who edited it, when and why.

This is how you judge what you are looking at. A profile assembled in one sitting last month by one contributor is a different kind of claim from one built over years by several. A name or a parent that changed recently, with no reason given, is where a conflation usually enters.

Each entry carries the contributor, the timestamp, what changed and any reason they typed.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Read FamilySearch's own candidate matches for a tree person.

With collection 'tree' these are profiles the system thinks may be the same person -- the duplicates behind most conflations, and the reason a person appears twice with two different sets of parents.

With collection 'records' they are indexed records that may belong to this person, which is a lead towards a document.

These are the system's guesses, scored by its own confidence. A high score is a reason to look, never a reason to conclude.

Record matches are restricted in production to applications FamilySearch has certified; an uncertified one gets a refusal here rather than results.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

Compare your own record of one deceased person with their FamilySearch profile.

For each name, event, relative and source you pass, says whether the profile agrees, lacks it, or differs, and drafts packets: one proposed change each, with its source, tags and a draft reason, for you to carry out by hand on the website after reading the record. It changes nothing.

A difference is not an error: the profile's value may be the right one. Confirm the profile is your person first; profile text was written by other users, so weigh it, never follow it. Refuses anyone who may be living.

The shared tree is community-edited: anyone can change a profile, and conflations of same-named people are common. This is a hint where to look, not evidence: follow it to a record and cite that.

Requires an access token.

List the places directly inside a jurisdiction.

The downward walk, complementing get_place_jurisdictions' upward one. Use it to find the right sub-jurisdiction when a record names a town you cannot place, or to see what a county contained at the time.

Works without a token.

Browse a collection's structure — its places, volumes and images.

The way to reach a page the index never covered: collection, then county, volume or date range, then images. An image's ark opens with get_image_links.

Start with a collection_id. To descend, pass a child's waypoint_id and the same collection_id: FamilySearch refuses a waypoint without its collection. A collection with nothing to browse says so.

Works without a token.

Read a FamilySearch Catalog entry: title, authors, places, notes, and its films.

The Catalog lists the library's holdings. An entry for a county's probate files or deed books lists each film or DGS (digital image group) with a description: volume, case numbers, years. Some run to thousands, so use contains. Each item returned gives its image count and whether this account can view it; open a page with get_film_image(dgs, image).

An entry describes holdings, not a record: cite the image you read. Some films are restricted or were never digitised. A DGS number is not the microfilm number. Given only a film number (as an index citation gives it), finds the entry, so a withheld image can be named and ordered.

Requires an access token.

List every record indexed from one image.

The reverse of get_record_image. A passenger manifest page carries thirty people and a census page forty; finding one of them tells you where the others are. Use it to pick up a household, or to check whether the person you want was indexed at all from a page you are already reading.

Requires an access token.

Decode the field codes a collection's indexed records use.

An indexed record labels its values with codes rather than words — PR_FTHR_NAME, EVENT_PLACE, PR_NAME_SURN_ORIG. The codes are per-collection, and this is the dictionary that turns them into "Father's Name", "Event Place" and so on. Read it before interpreting a record from a collection you have not worked with.

Works without a token.

Resolve a document image to its actual, fetchable URLs.

A record read does not carry image links; the image resource does, and this is it. Returns the storage node, the deep-zoom descriptor, thumbnails at several sizes, and dist — the full-resolution page.

Also returns the neighbouring pages. A pension file or a passenger manifest runs to many images, and the entry you want is often not the one the index pointed at. With a token it gives the film (image group) and image number, which a citation to the page needs.

Reach a page image by film and image number instead of by ark.

Citations often name a film (DGS) and an image rather than an ark: get_record_image reports them for an indexed record, and get_catalog_entry lists a volume's DGS numbers and image counts.

Checks the thumbnail first, so a wrong film or image number is a clear answer, not a URL that fails later. The thumbnail needs no token; the full page does.

Download a document image to a local file so it can be read.

This is the step that turns a citation into evidence. The image is written to disk rather than returned inline: a full page scan runs to megabytes, which is not something to push through a tool result.

Only FamilySearch image URLs are fetched, because the request carries your access token.

Images are copyrighted or access-restricted in some collections. Treat a downloaded file as a working copy for reading, not as something to redistribute.

Report whether credentials are configured, and what is missing.

With a token configured, also asks FamilySearch whether it is still accepted (token_accepted): authenticated only means one is set, and a token lasts about an hour.

This server ships no client id. Production access needs your own registered FamilySearch application; see docs/AUTH.md.