Changelog

Consent verification now checks who is speaking, not only what they said. A create whose consent_recording reads the phrase correctly but in a different voice from your sample is refused with 422 consent_speaker_mismatch and no voice is created.

This closes the gap the flow was always meant to close: the person consenting has to be the person being cloned, so permission relayed by somebody else - an account holder reading the phrase on a speaker’s behalf - does not pass.

consent_speaker_mismatch is not a new code, and clients that already branch on it need no change. What is new is that it fires. If you tested your integration by reading the phrase yourself against someone else’s sample, that path now returns a 422; put the challenge in front of the speaker instead. Re-reading the same phrase does not help, which is why this is a distinct code from consent_phrase_mismatch. See Consent.