This same sort of introspection and auto-discovery was an original tenant of REST that's mostly ignored these days and I'm happy for that - I've never seen this sort of thing work well because it assuming you're able to translate data points into unambiguous identifiers. So the company object has a name object, I might assume that's the name of the company, but what if it's the registration number of the company - does it include legal suffixes? Maybe it's the name of the majority owner and this company object is related to the stock market. Let's take a more fun example, some sort of grocery service that lists "price" does price include tax? Is it in USD? Is the price in dollars or cents? Are all prices in the same currency? Is the price the cost to the end user or the cost to fulfill inventory on a unit basis? Does the price include discounts - if there is a "price" and "sale_percentage" column then has the sale percentage already been applied - how does that sale_percentage work, is .2 for sale_percentage mean there is a 20% or 80% discount - considering it was built by programmers it'd probably mean an 80% discount but that's not what a layman would assume.
Introspection is not valid in place of documentation.
That all comes down to how well-designed the API is. Not all APIs are created equal but in the hands of a skilled designer, this functionality is priceless. Not only that but you can also look at the actual values to tease apart any meanings that seem ambiguous (but, once again, in the hands of a good designer those won't exist in the first place).
I've seen a lot of "self-documenting" code in my time and it can be quite legible when starting in an organization that has good discipline... The issue is that there are always some weird edge cases and poorly named things that exist because "legacy" - in those cases a quick question should clear everything up, if you have access to someone in the know.
When it comes to APIs if you're eschewing documentation it's because (I hope) you are trying to minimize support costs and thus devs using the API won't have someone to ask questions of so those edge cases become mysterious and assumptions are made that may be wrong.
If you're designing an API that serves up items that may be on sale how would you name fields so that the price and possibly sale discount are unambiguous to read?
Introspection is not valid in place of documentation.