Why does the same API key return 403 on some paths?

Under the /mp/ prefix sits a different kind of thing: datasets built by named third-party vendors, distributed through the same API surface but licensed separately. Knowing that changes how you plan around them.

What is in the namespace

The published specification lists three vendor namespaces:

• /mp/investverte/... — ESG scores for companies, sectors and countries, with a listing endpoint for each level and a detail endpoint keyed by symbol.
• /mp/praams/... — equity and bond analytics, structured reports, bank balance sheets and income statements keyed by either ticker or ISIN, and the vendor's own screeners for equities and bonds.
• /mp/unicornbay/... — US options contracts and end-of-day chains, the list of optionable underlyings, S&P Global index lists and components, and tick data.

The most useful thing here is a failure

One API token that returned every news item, sentiment series, indicator value and screener result quoted in this course returned 403 Forbidden on /mp/investverte/esg/AAPL, on a TradingHours market list, and on the options underlyings list. A different token, on the same paths, returns 200 and data. That is the whole point, and it is why the sentence names a token rather than the API.

Read that status code carefully. Not 401, which would mean the token is invalid. Not 404, which would mean the path does not exist. 403 means the path exists, the token is real, and this dataset is not included.

Two operational consequences fall straight out.

Entitlement is per dataset, not per key. "Does my key work?" is not a question with one answer. Code that discovers capability at startup should probe each namespace it depends on and degrade explicitly, rather than assuming that a successful /eod call implies anything at all about /mp/anything.

The error body is not always JSON. One of those 403s returned a full HTML error page; another returned the bare string Access denied. A client that pipes every response into a JSON parser will raise a parse error where it should have reported an entitlement problem — and you will spend an afternoon debugging the wrong layer. Branch on the status code before you touch the body.

Three more things to hold about vendor data

Different coverage. Vendor sets are built for the vendor's purpose, not as an extension of the core catalogue. Options coverage concentrates on the larger US names; bond analytics typically cover active, non-expired issues. What /eod covers tells you nothing about what any /mp/ dataset covers, and the only reliable answer is the vendor's own listing endpoint.

Different shapes and different costs. Marketplace responses do not all follow the bare-array convention of the core endpoints — some arrive wrapped in an envelope with success, item, errors and message fields, so error handling has to branch on the payload as well as the status. And each marketplace request is documented as consuming 10 API calls against your quota rather than 1. The quota arithmetic from the API Foundations course still applies; the multiplier does not.

Different provenance, and therefore different questions. An ESG score or a risk rating is a vendor's opinion, expressed as a number, on a scale that vendor defined. That is the same scepticism Unit 2 applied to sentiment, and it applies to every scored dataset regardless of who publishes it. Before you use one, answer three questions: what universe does it cover, when is it refreshed, and who defined the scale?

This lesson describes what the namespace contains and how access to it behaves. It is not a statement about what any dataset is worth, and nothing here recommends any vendor, dataset or product.

Try it now

1. We do not render marketplace data, so here are status codes and raw bodies, measured on 28 September 2026 on two /mp/ paths with two tokens: the public demo token, and the academy's own key, which is entitled to both. Read each row and say what a client that parsed every body as JSON would have reported for it, and what the one probe per namespace your startup check needs would look like. Whatever comes back, you have learned something you would otherwise learn in production.

2. Pick one marketplace dataset your project might use and answer the three provenance questions in writing before you write any code against it.
3. Work out what a daily refresh of that dataset costs at 10 API calls per request across your symbol universe. Compare it to your daily allowance. Do this before the integration, not after.