The fred/category/children request returns the child categories that sit directly under a specified parent category. This guide turns the parameter documentation into a repeatable checklist: what to send, which units and formats are required, what the defaults do to your output, and how to confirm a response is what you intended before you build on it.
Everything below is limited to what the source page states. Where a value must be supplied but is not published on that page, this guide flags it as unknown rather than guessing.
What the endpoint does
The request's stated purpose is to get the child categories for a specified parent category. That is the only behavior the source describes. The page does not describe pagination, ordering, or how deep the hierarchy is traversed, so treat any assumption about those as unverified.
Two operational points matter before you write any code. First, the response format is selectable: the request can return either XML or JSON, set through the file_type parameter to xml or json. Second, the default value of file_type is xml. If you omit the parameter and expect JSON, you will get XML.
Parameter checklist
Use this as a pre-flight list. Each row maps a documented parameter to what the page says about it and what the source does not establish.
| Parameter | Documented rule | What is not stated |
|---|---|---|
| API key | Required. Described as a 32 character alpha-numeric lowercase string. | How to obtain a key; the page gives only a demonstration value. |
| Parent category | Identifies the parent whose children you want. | The accepted value range or type is not spelled out on the page. |
| file_type | Selects XML or JSON; default is xml. | Whether other values are rejected or ignored. |
| File extension | A key or file extension indicates the type of file to send. | Which extensions are valid beyond the two formats named. |
| Date field | Optional YYYY-MM-DD formatted string; default is today's date. | Which request parameters this date governs. |
The API key rule is a strict format: 32 characters, alphanumeric, lowercase. That is a countable constraint, so you can validate it before sending anything. A key that is uppercase, contains punctuation, or is longer or shorter than 32 characters fails the stated format on its face.
The source explicitly labels the sample key abcdefghijklmnopqrstuvwxyz123456 as demonstration only. Do not ship it in a client, a notebook you share, or a repository. Treat it as a placeholder that shows the shape of a valid key, not as a working credential.
Worked example: auditing a request
The source does not publish an example response, so the following is a Hypothetical walkthrough of the checks only — no response content is claimed.
- Step 1 — Key format. Count characters. Hypothetical: a 32-character lowercase alphanumeric key passes; a 31-character key fails.
- Step 2 — Format intent. If you want JSON, you must set file_type to json. Default output is xml, so an omitted parameter is a silent format change, not an error.
- Step 3 — Date handling. If the date field is omitted, the request uses today's date. If supplied, it must match YYYY-MM-DD. A value like 2024-13-01 is Hypothetical and would violate the month range even though the string shape matches.
- Step 4 — Parse check. Parse the response body with the parser that matches the format you requested. Hypothetical: attempting a JSON parse on default XML output fails at the first character.
A short calculation helps size the validation step: of the two named formats, one is the default. So a request that omits file_type has exactly one possible documented output format, XML — a share of 50% of the named options, but 100% of the default path. Both figures are Calculation results from the two format values, not statements about frequency of use.
Real-time period context
The page points to a separate Real-Time Periods reference for more information, but does not explain on this page how that concept applies to a category/children call. If your workflow depends on the meaning of the date string, follow that pointer and keep the definition separate from this endpoint's mechanics.
Status: what kind of information this is
This is a reference specification for an API endpoint, not an announcement of a new capability, a deprecation notice, an approval, or a rollout timeline. The page lists no publication date. Do not describe it as a recent change or as newly available; those are inferences the page does not support.
One distinction to keep clear: the page describes required and optional parameters, but required-ness is a contract statement, not evidence that the endpoint is currently live or stable. Availability and uptime are outside what this source establishes.
What the source does not say
- It does not publish an example request URL or an example response body.
- It does not state how many child categories a parent can have, or whether results are paginated or ordered.
- It does not list the valid parent category values or their type.
- It does not state error codes or behaviors for an invalid key or unknown category.
- It does not explain how the optional date field affects this specific endpoint.
- It does not state rate limits, licensing, or terms for use of the demonstration key.
- It does not give a version number for the endpoint.
Because of these gaps, a reader cannot reconstruct a full request from this page alone. The page defines several parameters but omits the exact parameter name for the parent category, which is the core input. That omission is material: any code that supplies a parent must take the name from another reference, not from this page.
A practical verification loop
Build a small loop you can rerun whenever a request looks wrong. Each check should produce a pass or fail you can log.
- Confirm the key matches the stated format: exactly 32 characters, lowercase, alphanumeric.
- Confirm file_type is explicit in the request, even when you want the default XML — explicitness removes ambiguity later.
- Confirm any date string matches YYYY-MM-DD, or is intentionally omitted to use today's date.
- Confirm the response parser matches the format you requested.
- Record which values came from the specification and which came from another reference, so future readers know what this source does and does not cover.
The reusable value here is the separation of documented facts from assumptions. Format defaults, key length, and date shape are specified; ordering, pagination, the parent parameter's exact name, and error handling are not. Keeping that line visible keeps your reproduction honest.