Idempotency in REST APIs: Client-side keys or server-side generation?

I'm designing a new set of REST APIs where idempotency is going to be critical for certain write operations, especially those involving financial transactions or resource provisioning. I'm torn between two main approaches for managing idempotency keys. One option is to require clients to generate and send a unique idempotency key with each request. This gives clients direct control but means they're responsible for uniqueness and retry logic. The alternative is for the server to generate and return an idempotency key upon initial request, which clients then use for subsequent retries. This offloads uniqueness to the server but adds an extra round trip. What are the community's thoughts on the practical trade-offs here, particularly regarding client library complexity, API discoverability, and potential for misuse or errors in either approach?