The server would be telling the client the rate-limiting values active/effective for to it. As such, the client doesn't actually need to know what "its partition" is. As far as the client is concerned, "its partition" is the whole of the rate-limiting domain.

The partitioning strategy, and partition chosen using it, would never — should never — be relevant to any automated logic inside the client. (The only way in which it could be would be if you were trying to make a client that aims to defeat the server's rate-limiting logic by using multiple accounts or IP addresses to jump between partitions, and that's... not okay.)

The point of sending the partitioning info to the client, is that it enables a human developing a client, or operating a tool that embeds a client, to debug why rate-limiting is happening when by their understanding it shouldn't be — especially when they have multiple clients across multiple threads / machines each making multiple concurrent requests to the API. These HTTP-429-response heisenbugs get much easier to reason about when the server is sending the client enough information for the developer to be able to see which of the requests they sent got rate-limiting-bucketed together, and which didn't.