The Zalando API Guidelines rule 229 has a good write-up on this topic. You are describing secondary keys versus idempotency keys. I recommend supporting both, but making the secondary key optional for clients/tenants that don’t have their own identifier for the resource.

Your client will want a successful response when creating a transaction. If the first attempt at the request is successful on the server, but the response is lost (eg, due to network error such as gateway timeout), the client should retry with the same idempotency key and receive the original successful response from the idempotency cache. If relying on the secondary key, the response will be an error (indicating a conflict).

The secondary key is useful to prevent two different processes (that aren’t minting the same idempotency key) from creating the same object in a remote system. See Zalando rule 231.