The FRED endpoint fred/release/related_tags returns the related FRED tags for one or more FRED tags within a release. If you want to reproduce a tag set rather than accept a finished chart, the key thing to internalize is that the response describes tags reached indirectly through series, not tags attached to the release object itself.
This guide walks through what each parameter does, where users commonly misread the output, and how to write a query you can re-run and hand to someone else.
What the endpoint actually returns
FRED tags are attributes assigned to series. For this request, related FRED tags are the tags assigned to series that satisfy three conditions at once: they match all tags named in the tag_names parameter, they match no tags named in the exclude_tag_names parameter, and they sit inside the release set by the release_id parameter.
That is why the documentation describes the path as indirect. Indirectly through series, it is possible to get the tags for a release. The release itself does not directly own tags; the tags live on series, and the release is a filter applied to those series.
The endpoint can return either XML or JSON, controlled by the file_type parameter set to xml or json. The default value of file_type is xml, so a script that omits it and expects JSON will break.
Parameters in order of impact
| Parameter | Role | Notes from the documentation |
|---|---|---|
| api_key | Authentication | 32 character alpha-numeric lowercase string, required. The documented example key 'abcdefghijklmnopqrstuvwxyz123456' is for demonstration purposes only. |
| release_id | Scopes results to one release | Core filter; without it the result is not release-specific. |
| tag_names | Positive filter | A semicolon delimited list of tag names that series match all of. |
| exclude_tag_names | Negative filter | A semicolon delimited list of tag names that series match none of. |
| tag_group_id | Narrowing filter | String, optional, no filtering by tag group by default. |
| file_type | Response format | A key or file extension that indicates the type of file to send; default is xml. |
Two further parameters appear in the parameter list: a search term (optionally filter results by tag group or search) and a real-time start date given as a YYYY-MM-DD formatted string, optional, default: today's date.
A worked example you can re-run
The documentation supplies two illustrative filter sets. Find the related tags for series having both tags 'defense' and 'investment'. And find the related tags for series having neither tag 'monthly' nor tag 'financial'.
Read those two sentences as instructions to build a query, not as output to copy. The first example corresponds to tag_names=defense;investment: the semicolon joins tag names, and every listed tag must be present on the series. The second corresponds to exclude_tag_names=monthly;financial: every listed tag must be absent.
When both parameters are used together, the two conditions stack. Suppose (Hypothetical) you set tag_names=defense;investment and exclude_tag_names=monthly;financial. The candidate series set becomes those series in your chosen release that carry both 'defense' and 'investment' and carry neither 'monthly' nor 'financial'. The returned tags are whatever attributes remain attached to that surviving set.
That hypothetical illustrates a reusable rule rather than a specific result: the output tag list is a property of the filtered series set, so changing release_id, or adding one excluded tag, can change the entire list. There is no fixed answer to memorize.
Reproducibility checklist
- Record release_id explicitly; it is the scope of the whole request.
- Write tag_names and exclude_tag_names in their semicolon-delimited form, and keep the order documented even though the semantics are set-based.
- Set file_type=json if you are parsing programmatically; otherwise you receive xml by default.
- Record whether a search term or tag group filter was applied, since silence about them means no filtering by tag group by default.
- Record the real-time period setting; the date defaults to today's date, which makes an undocumented run hard to reproduce later.
- Never paste the demonstration key into a production script; it is shown for demonstration purposes only.
Where the direction of the relationship matters
The documentation points to the related request fred/release/tags. These are not interchangeable. One direction operates through series; the other is a distinct endpoint with its own behavior. If your notes treat them as synonyms, you are one endpoint name away from a result you cannot defend.
A practical consequence: when a tag appears in a related_tags response, the honest description is that it is assigned to at least one series meeting your three-part condition. It is not a statement that the release itself is tagged that way.
Common misreadings
First, treating the response as a complete taxonomy. It is a filtered set, not a hierarchy, and it shifts with the release filter. Second, forgetting that tag_names means all, not any: listing two tags narrows the series set rather than widening it. Third, assuming JSON is the default. The default value of file_type is xml.
Fourth, forgetting the exclusion side. A memorable result can come entirely from what you removed; if exclude_tag_names is not written down, the reader cannot tell whether they removed something that mattered.
What the source does not say
The documentation does not specify a maximum number of tag names per request, a response ordering, or a pagination scheme for this endpoint. It does not state result counts, rate-limit values, or error codes. It does not define how the search term matching behaves on partial strings, and it gives no examples of returned payloads, so response field names cannot be taken from this page alone.
It also does not tell us whether removing a tag from tag_names ever widens the released tag list in a predictable direction; that depends on underlying series, which this source does not characterize. Any quantitative example built on this page — including the hypothetical combination above — is an illustration of the filter logic, not measured output. What the source does establish is the three-part condition, the semicolon delimiter, the all/none semantics, and the xml default.