How the documentation is organised: the hierarchy of sources

Why this matters. Nobody memorises the whole endpoint list — it is approaching ninety paths and it grows — and anyone who tries will be wrong within a release. What survives is knowing which source answers which kind of question. Foundation: How do professionals sanity-check data?

Page locations rot. That is not a hypothetical: this corpus once carried hundreds of links to our own site, and the overwhelming majority of them pointed at the bare homepage rather than at any page that answered the question in front of them. Learning where a page sits today is learning something with a short shelf life.

What does not rot is the hierarchy.

Four sources, four different questions

• The OpenAPI specification answers what shape a call has. It is the structural list of paths and parameters, and it is authoritative about how something is called. It is not authoritative about what exists: it runs behind the product, and several live endpoints have never had an entry in it. That distinction has its own section below, because getting it backwards is how a client gets told something false.
• The API documentation on the site answers what it returns and how to ask. Parameters, response shapes, worked examples. This is the page a person reads.
• The knowledge base and the academy articles answer why it matters and how it is meant to be used. A parameter list will never tell you that a client should not be polling this endpoint every second.
• The generated reference in this Academy answers which market question an endpoint is for, and which public lesson goes deeper. It is built from the two files that already hold that truth, so it cannot drift from them.

Ask the wrong source and you get a confident answer to a question you did not have.

When two sources disagree

The specification runs behind the product. There are things documented on the site with no entry in the spec at all: SEC filings, congressional trades, crypto fundamentals, delisted companies, ASX corporate actions, the supported crypto and forex lists.

So the rule is: when the spec and the site disagree, the site wins, and the gap itself is worth knowing. A client told "that endpoint does not exist" on the strength of a spec search has been told something false.

One source is a claim, two are a fact

The habit worth carrying out of this lesson: if only one place says it, it is a claim. Verify anything you are about to put in front of a client against a second source, and if the second source does not exist, say that instead of implying certainty.

That is not bureaucracy. It is the difference between an answer that survives being checked and one that does not.

What is not in scope here

How the company itself works — services, ownership, internal processes — lives in the internal knowledge base, not in product documentation. It is a real shelf and it is not this course's subject. Knowing which of the two you are in is itself part of the routing skill.

Try it now

1. Take a question you were asked recently. Name which of the four sources should have answered it, then check whether that is where you actually looked.
2. Now prove the rule about which source wins, rather than believing it. Call /insider-transactions and read the filers below: most of Microsoft's 2026 rows are members of Congress rather than company officers, and the site documents a separate /congressional-trades path for them. Search the specification for that one and find nothing — it answers all the same.

3. Say what follows. A client told "that endpoint does not exist" on the strength of a spec search has been told something false. When the spec and the site disagree, the site wins, and the gap itself is worth knowing.
4. Then check the fourth source against the first three. The generated reference at /academy/reference lists every endpoint beside the market question it answers and the public lesson that teaches the idea, built from the endpoint index and the market-product map so it cannot drift from them. Look up the path from step 2 there and see whether it agrees.
5. Carry the habit out: if only one place says it, it is a claim. Verify anything you are about to put in front of a client against a second source, and if the second source does not exist, say that instead of implying certainty.