Finding the endpoint, DESCRIBING IT, and TESTING IT. What the generated type is built from, and WHY THAT MATTERS AT THE NEXT UPDATE.
This is the mechanical lesson of the module, and the two things worth taking from it are how to find the endpoint at all, and what the test you run is actually establishing.
FINDING IT IS THE FIRST OBSTACLE AND IT IS A DOCUMENTATION PROBLEM RATHER THAN A TOOL ONE. Fusion publishes REST APIs per product family, versioned in the path, and the resource you want is usually named after the business object rather than the screen you saw it on. Start from the API catalogue for the release your pod is running, not from a search result, because the shape changes between releases and an example from two releases ago will mislead you specifically.
DESCRIBING IT MEANS GIVING THE TOOL THE URL AND LETTING IT CALL ONCE TO SEE WHAT COMES BACK. That call is where the type comes from, which is the sentence to remember: the type is built from ONE RESPONSE, on ONE DAY, from ONE POD.
SO A FIELD THAT WAS EMPTY IN YOUR SAMPLE MAY NOT APPEAR IN THE TYPE AT ALL. Describe against a record with real data in every field you care about, or you will find fields missing from the picker that the service returns perfectly well — and conclude, wrongly, that Fusion does not provide them.
AND WHY IT MATTERS AT THE NEXT UPDATE IS THE WHOLE OF LESSON 8. Fusion is upgraded on Oracle's schedule rather than yours, fields are added, renamed and deprecated, and the type you generated does not move. Nothing re-checks it and nothing tells you, so record which endpoint and which release each connection was described against — that note is what turns a mystery into a check.
TESTING IT IN THE TOOL ESTABLISHES ONE THING: THAT THE CREDENTIAL AND THE URL WORK TOGETHER RIGHT NOW. It does not establish that a user will have the same access — Lesson 3 — and reading a successful test as "the connection works" is how a shared-account application gets built by accident.