Extend OTP code control via HTTPCodeGenerator and preotpcodesend Action hook
š¬Self-hostedāļøāš„APIsšŖµLogināFeature RequestšActions
Hey, thinking of putting together a PR to extend OTP code control and I wanted to sanity check the direction before diving in.
Some context: #8581 closed with only Twilio Verify support, the webhook provider item was explicitly crossed out. There's still no way to do things like variable TTLs per user/context, custom code formats per request (4-digit PIN, digits-only for voice, etc.), or plug in a non-Twilio SMS provider that owns generation+verification.
This affects both SMS and email OTP, email actually has even less flexibility right now, the verifier is hardcoded to nil so there's no external hook possible for email regardless of config.
Quickly exploring the codebase, two possible additions jump to mind:
1. An HTTPCodeGenerator that implements the existing CodeGenerator interface (same one Twilio Verify uses). You configure send/verify URLs on both the SMS and email providers and Zitadel POSTs to your service. Mirrors the Twilio implementation almost exactly just over HTTP instead of the Twilio SDK, and brings full SMS/email parity since email has no equivalent today.
2. A preotpcodesend Actions V2 function that fires before generation for both SMS and email. The response schema could support: override_ttl, override_length, override_digits_only for lightweight param tweaks, code to return the actual code value directly (Zitadel stores and verifies it as normal, you just control the value), or external_generator_id to delegate fully to the HTTP provider. This covers the full range of use cases from "just change the TTL" to "we own the entire code lifecycle" without needing a stateful external service for the simpler cases.
Both fully backwards compatible, closes the descoped item from #8581 properly for both channels.
Does this seem like the right approach and something you would welcome or am I missing something?
Some context: #8581 closed with only Twilio Verify support, the webhook provider item was explicitly crossed out. There's still no way to do things like variable TTLs per user/context, custom code formats per request (4-digit PIN, digits-only for voice, etc.), or plug in a non-Twilio SMS provider that owns generation+verification.
This affects both SMS and email OTP, email actually has even less flexibility right now, the verifier is hardcoded to nil so there's no external hook possible for email regardless of config.
Quickly exploring the codebase, two possible additions jump to mind:
1. An HTTPCodeGenerator that implements the existing CodeGenerator interface (same one Twilio Verify uses). You configure send/verify URLs on both the SMS and email providers and Zitadel POSTs to your service. Mirrors the Twilio implementation almost exactly just over HTTP instead of the Twilio SDK, and brings full SMS/email parity since email has no equivalent today.
2. A preotpcodesend Actions V2 function that fires before generation for both SMS and email. The response schema could support: override_ttl, override_length, override_digits_only for lightweight param tweaks, code to return the actual code value directly (Zitadel stores and verifies it as normal, you just control the value), or external_generator_id to delegate fully to the HTTP provider. This covers the full range of use cases from "just change the TTL" to "we own the entire code lifecycle" without needing a stateful external service for the simpler cases.
Both fully backwards compatible, closes the descoped item from #8581 properly for both channels.
Does this seem like the right approach and something you would welcome or am I missing something?
