Yea, that is correct.
It does feel a bit round-trippy, but its the separation of concerns: cookie validation is a public/frontend concern (it involves CSRF, session cookies, and browser security semantics), while session management by ID is an administrative concern.
The admin API deliberately doesn't parse or trust raw session cookies; that logic lives on the public side.
If your use case is purely server-side, note that calling
/sessions/whoami
server-side by forwarding the cookie header is perfectly valid and doesn't require a browser, it just needs network access to the public port.