# The API reference shows the fields of each response, and what an enumeration's numbers mean - Date: 2026-10-26 - Type: New - Surface: Developer portal and CLI - What you need to do: Nothing. - Address: https://developers.rivr.io/changelog/2026-10-26-reference-response-fields-and-enum-names The reference now lists the fields of every successful response that has a JSON body, in a table of name, type and description from the spec, on each operation's page, in `/reference//.md`, in `/llms-full.txt` and in the MCP tool `get_page`. It goes down into objects and lists, two levels below the first, as `orderLines[].amountInclVat`. For an enumeration the table names the values: an order's `status` is `1 = Created, 2 = Pending, 4 = Completed, 8 = Refunded, 32 = Cancelled`, read from the spec's `x-enumNames`. A long enumeration, such as `PaymentMethod` with 22 values or `TransferStatus` with 65, shows its first 12 values, says how many more there are, and links the schema in the spec that has all of them. Until now only a call's parameters and body were listed, so a reader of `getOrderStatus` or `getOrder` could not see what the numbers in `status` meant. The same fix lets an object field have rows of its own, in a request body too (such as `device` in `startCardPayment`), and the spec's generated line `Possible values: …` is no longer repeated after the values. One example was wrong: the 200 example of `getOrderStatus` showed `"status": 200`, which is an HTTP status, where the spec says an order status, and the same fault was in the 200 examples of `getOrder` in both surfaces, the 201 example of `createOrder` and the three onboarding-link responses. An example now always takes a value from the field's own list, the first one that isn't 0 or None, so an order's status shows `1`, Created, and for example a payment method `1`, Card. The status of an onboarding link shows the placeholder `string`, since the spec lists no values for it. The API's answers and the spec in `/openapi/api-public.json` are unchanged.