I would never feel comfortable `fetch`-ing the URI provided by the API without validation. That sounds like a security issue waiting to happen.
The validation would be intrinsic in the client side concatenation of the server address with the relative URI.
If all you stored was the ID, all you would need to change is the logic in your API client which accepts the ID and constructs the URL for it.
For example, if the entity ID changes from being an integer, to being a GUID, you'd still have to write code to update your schema (presumably, from an int column to a GUID/string column).
For example, the article includes URLs like "/people/123". The security of having a leading slash in these depends on API base URL.
"https://api.hotstartup.com/v1" – safe
"https://api.hotstartup.com" – unsafe with ".evil.com/people/123"
I wouldn't really call this particular scenario a security issue, but allowing such things is a bad habit that will eventually bite. It's like not HTML-encoding values like usernames that you "know" are safe (but you know are not HTML-encoded).
If I visit an HTML page with a link to “.evil.com/people/123” and click on it, the user agent won’t append “.evil.com” to the hostname. You’d instead get something like “https://api.hotstartup.com/.evil.com/people/123” which would be safe (if not broken).