Principle:Langgenius Dify Deployment and API Access

Knowledge Sources	Dify API Access Dify
Domains	API Management Application Deployment
Last Updated	2026-02-08 00:00 GMT

Overview

Application deployment strategies for AI services encompass API-first access patterns and embeddable widget distribution, enabling consumers to integrate LLM applications into their own products and workflows.

Description

Once an application has been configured and tested, it must be deployed to make it accessible to end users. Dify provides two primary deployment channels, each serving different integration scenarios:

1. API Access

The API channel exposes the application as a RESTful service that external clients can invoke programmatically. Key aspects include:

• API Enable/Disable Toggle -- The application's API access can be toggled on or off independently of the web app. When disabled, all API requests are rejected.
• API Key Management -- Each application can have multiple API keys. Keys are created, listed, and revoked through dedicated endpoints. Each key provides bearer-token authentication for API requests.
• Rate Limiting -- Configurable request limits per minute (RPM) and per hour (RPH) protect the application from abuse and control cost exposure. Default limits are 60 RPM and 3600 RPH.
• Endpoint Structure -- The API follows a consistent pattern: /v1/chat-messages for chat apps, /v1/completion-messages for completion apps, /v1/workflows/run for workflow apps.

2. Embeddable Chat Widget

For web-based integration, Dify provides a JavaScript embed script (embed.js) that creates a floating chat bubble on any webpage. The widget:

• Is loaded as an Immediately Invoked Function Expression (IIFE) that bootstraps itself
• Configures the chatbot name, user identity, default inputs, and visual appearance
• Supports draggable positioning for the floating button
• Communicates with the Dify backend through the same API layer
• Can be customized through a window.difyChatbotConfig object

3. Web App (Site) Access

A built-in hosted web application provides a shareable URL where end users can interact with the application directly. The site access token can be regenerated for security, and the site can be configured independently of the API.

Usage

Deploy an application when:

• The application has been tested and is ready for external consumption
• Integrating the AI application into a third-party product via REST API
• Embedding a conversational AI widget into an existing website
• Sharing a standalone web app URL with end users

Theoretical Basis

The deployment model follows an API Gateway pattern where a single application definition is exposed through multiple access channels, each with its own authentication and rate-limiting policies.

FUNCTION deploy_application(app, channels):
    FOR EACH channel IN channels:
        SWITCH channel:
            CASE api:
                TOGGLE_API(app.id, enabled=true)
                key = CREATE_API_KEY(app.id)
                SET_RATE_LIMITS(app.id, rpm=60, rph=3600)
                RETURN { endpoint: "/v1/...", api_key: key }
            CASE embed:
                token = GET_SITE_TOKEN(app.id)
                script = GENERATE_EMBED_SCRIPT(token, config)
                RETURN { script_tag: script }
            CASE webapp:
                TOGGLE_SITE(app.id, enabled=true)
                url = GENERATE_SITE_URL(app.id)
                RETURN { url: url }

Key design considerations:

• Independent channel control -- API and site access can be enabled/disabled independently, allowing staged rollouts.
• Key rotation -- API keys can be created and deleted without downtime. Multiple active keys support rotation workflows.
• Defense in depth -- Rate limiting, API key authentication, and the enable/disable toggle form three layers of access control.

Related Pages

Implemented By

• Implementation:Langgenius_Dify_UpdateAppApiStatus

Uses Heuristic

• Heuristic:Langgenius_Dify_Token_Refresh_Loop_Prevention