The related_tags request returns the related FRED tags for one or more FRED tags that match a series search (c01). FRED tags are attributes assigned to series (c03). The useful thing to understand is the intermediate series set: related tags are defined against series that match all tags in tag_names, no tags in exclude_tag_names, and the search words in series_search_text (c04).
Get that series set right, and the related-tag list that follows is mechanical. Get it wrong, and the returned tags describe a population you did not intend.
The definition in order
The source states the rule as one sentence: for this request, related FRED tags are the tags assigned to series that match all tags in tag_names, no tags in exclude_tag_names, and the search words set by series_search_text (c04). Read it as a three-stage filter applied before any tags are collected.
Stage one is inclusion. tag_names is a semicolon delimited list of tag names that series match all of (c13). Stage two is exclusion, exclude_tag_names is a semicolon delimited list of tag names that series match none of (c15). Stage three is the free-text constraint set by series_search_text.
The two list rules are not the same shape. Inclusion requires all listed tags to be matched (conjunctive); exclusion requires none of the listed tags to be matched. That difference matters when you build your own replication.
Worked parameter shapes from the source
The source gives two illustrative calls. One finds the related tags for series having both tags '30-year' and 'frb' (c14). The other finds the related tags for series having neither tag 'discontinued' nor tag 'monthly' (c16). Both illustrate list behavior; neither is a result set.
| Parameter | Documented role | Source |
|---|---|---|
| api_key | 32 character alpha-numeric lowercase string, required | c09 |
| tag_names | Semicolon delimited list; series match all of them | c13 |
| exclude_tag_names | Semicolon delimited list; series match none of them | c15 |
| tag_group_id | Optional string; no filtering by tag group by default | c17 |
| file_type | xml or json; default is xml | c06, c07 |
The api_key parameter is documented as a 32-character alpha-numeric lowercase string and is required (c09). The source shows a demonstration key, 'abcdefghijklmnopqrstuvwxyz123456', and notes it is for demonstration purposes only (c08), so treat it as a placeholder rather than something to reuse.
Filtering the tag list itself
Results can optionally be filtered by tag group or tag search (c02). tag_group_id is an optional string parameter, with no filtering by tag group by default (c17). When supplied, its accepted values are 'freq', 'gen', 'geo', 'geot', 'rls', 'seas', and 'src' (c18).
That enumeration is the closed part of the request. If you keep your own mapping of tag names to groups, compare it against these values rather than assuming additional group codes exist.
Output format and the date field
The request returns either XML or JSON by setting file_type to xml or json (c06), and the default value of file_type is xml (c07). A client that parses JSON must set file_type explicitly, since the default does not produce it.
file_type is described as a key or file extension that indicates the type of file to send (c10). The source also documents a date parameter as a YYYY-MM-DD formatted string, optional, with a default of today's date (c12), and points to Real-Time Periods for more information (c11).
Hypothetical: if today's date is 2025-03-14 and you omit the date parameter, the effective value is 2025-03-14. That is an illustration of the default rule, not a retrieved result.
What the source does not say
- The source does not state how related tags are ranked or ordered in the response.
- It does not state whether a series can appear in the set without matching series_search_text when that parameter is omitted.
- It does not state response field names, pagination, or rate limits for this request.
- It does not characterize related_tags as the inverse of any other endpoint.
- It does not state what happens when tag_names is empty or contains an unknown tag.
What it does say about the sibling request is limited: see the related request fred/series/search/tags (c05). The source points to a separate related request, fred/series/search/tags (c05), and stops there.
Related tag matching versus tag search
Because c05 is only a pointer, the safer method is to keep the two requests separate in your notes. Treat fred/series/search/related_tags as the request defined by c01 and c04, and treat fred/series/search/tags as a request the source names but does not define here. Any comparison beyond that is your own inference, not a documented equivalence.
For recomputation, log the three inputs that determine the series set: tag_names, exclude_tag_names, and series_search_text. If a reported related-tag list cannot be traced to those three values, the inputs were not recorded, or the list came from a different request.