Question: Best approach for adding phone verification workflow tools (multi-provider support)?

[navi-]

Question

I'm looking to add phone verification capabilities to the workflow builder that can support multiple verification providers (Plivo, Twilio Verify, Vonage, etc.). This would allow Dify app developers to verify their end-users/customers within AI workflows.

Use Case

Enable workflow builders to:

• Send OTP codes to customers during a workflow
• Verify customer-entered codes before proceeding
• Support both SMS and voice channels for OTP delivery
• Choose their preferred verification provider

Example workflow:

User Input (phone) → Send OTP → Wait for Code → Verify Code → Continue/Reject

Proposed Approaches

Option A: Extensible Verify Tool Category

Create a verify tool category with provider implementations (similar to how model providers work):

api/core/tools/builtin_tool/providers/verify/
├── __init__.py
├── verify_base.py              # Base class for verify providers
├── plivo/
│   ├── plivo_verify.yaml
│   ├── plivo_verify.py
│   └── tools/
│       ├── send_otp.yaml
│       ├── send_otp.py
│       ├── verify_otp.yaml
│       └── verify_otp.py
├── twilio/
│   ├── twilio_verify.yaml
│   └── tools/...
└── vonage/
    ├── vonage_verify.yaml
    └── tools/...

This allows:

• Common interface for all verify providers
• Easy addition of new providers
• Users choose provider via credentials configuration

Option B: Plugin per Provider

Create separate plugins for each verification provider:

plugins/plivo_verify/
├── manifest.yaml
└── tools/...

plugins/twilio_verify/
├── manifest.yaml
└── tools/...

Option C: Custom Workflow Node

Create a dedicated verification node type with provider selection:

api/core/workflow/nodes/phone_verify/
├── phone_verify_node.py
├── entities.py
└── providers/
    ├── plivo.py
    ├── twilio.py
    └── vonage.py

Questions

1. Which approach is recommended for extensible third-party verification services?

2. State management: OTP verification requires storing a session ID between "send" and "verify" steps. What's the recommended way to handle this in workflows?

3. Builtin vs Plugin: For verification provider integrations, is the preference to keep these as external plugins or include as builtin tools with a common interface?

4. Any existing patterns for multi-step verification flows in workflows I should reference?

Would appreciate guidance before implementing. Thanks!

[dosubot[bot]]

Hi @navi-! I'm Dosu and I’m helping the dify team.

Recommended approach:
Dify maintainers currently prefer third-party verification integrations as external plugins, not built-in tools. This plugin-first pattern is used for model providers and is recommended for phone verification as well. Each provider (Plivo, Twilio, Vonage, etc.) should be implemented as a separate plugin with a common interface, credential schema, and validation logic. This makes it easy to add new providers and keeps the core codebase maintainable and secure [source].

Provider selection & credential management:
Plugins can define credential schemas in their manifest and support credential selection via the workflow UI. Recent changes allow workflow-level credential overrides, so users can choose provider/API keys per workflow or node, using dropdown selectors for available credentials [source].

State management for OTP:
Use the workflow node execution model: persist session IDs, OTP tokens, or verification status in the node’s process_data field. This state is available between steps (e.g., Send OTP → Wait for Code → Verify Code). For dynamic runtime data (like tokens from external systems), use the new passthrough parameter, which flows from the web UI through the workflow to plugins [source]. Dify’s workflow engine and GraphStateManager handle node/edge states and execution order, supporting multi-step, stateful flows [source].

Existing patterns to reference:

• Model provider factory and base class for extensible, plugin-based integrations [source].
• Datasource provider base class for credential validation and abstraction [source].
• Workflow node execution/process_data for multi-step state management [source].

Summary:
Go with the plugin-per-provider approach (Option B), using a shared interface and credential schema. Persist OTP/session state in workflow node process_data, and use the passthrough parameter for dynamic data. Reference Dify’s provider factory and workflow node execution patterns for implementation. This aligns with Dify’s architecture and current best practices for extensibility and maintainability.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[dosubot[bot]]

The recommended approach is to implement each verification provider (Plivo, Twilio, Vonage, etc.) as a separate plugin with a shared interface and credential schema. This plugin-per-provider model is Dify's current best practice for third-party integrations, making it easy to add new providers and keeping the core codebase maintainable and secure. Plugins can define credential schemas in their manifest and support credential selection via the workflow UI, with recent enhancements allowing workflow-level credential overrides and dropdown selectors for available credentials [source].

For OTP/session state management, persist session IDs, OTP tokens, or verification status in the workflow node's process_data field. This state is available between steps (e.g., Send OTP → Wait for Code → Verify Code). For dynamic runtime data (like tokens from external systems), use the passthrough parameter, which flows from the web UI through the workflow to plugins [source]. Dify’s workflow engine and GraphRuntimeState handle node/edge states and execution order, supporting multi-step, stateful flows [source].

For reference patterns, look at the model provider factory and base class for extensible, plugin-based integrations, the datasource provider base class for credential validation and abstraction, and the HumanInputNode for multi-step, stateful workflow nodes that pause and resume execution based on user input [source].

This architecture aligns with Dify’s extensibility and maintainability goals and is the recommended path for phone verification workflows with multi-provider support.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}