Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

API Integration Guide: Post-Publication API Endpoint Structure, Authentication Methods, and Request/Response Format Description

After delivery, partners frequently need to integrate Dify applications into the customer’s existing systems, making the API guide a must-cover training topic.

Public sources for this topic are also relatively comprehensive. The official documentation itself includes “API-Based Development” and integration instructions for multiple application types. Community articles also provide practical examples of calling Workflows via API, connecting LINE Bots, and integrating with external systems. Therefore, this can be developed as a standard module in partner delivery training.

1. API Training Focus Confirmed by Public Sources

1. The Dify API Is Not a Single Interface but Multiple Capability Entry Points

Public sources show different types of interfaces including chat, Workflow, knowledge base, and external knowledge base. This means training must first establish interface categorization.

2. Authentication and Endpoint Distinction Are Common Pitfalls

Many public cases involving the Workflow API emphasize issues with base URL, API key, application type, and variable name consistency. Therefore, training must clarify “which key corresponds to which interface.”

3. The Goal of API Training Is to Get Applications Actually Connected to Business Systems

Public practices already show examples of connecting Dify to LINE, external workflows, knowledge bases, and third-party systems. Therefore, API training should not just cover curl commands but should address real integration paths.

2. Content That Needs to Be Covered

  • What endpoints are available after application publication
  • What API Key is used for authentication
  • Common request body fields
  • Response structure and error handling

3. Training Focus

  • Distinguish between chat, Workflow, and dataset interfaces
  • Distinguish between platform management interfaces and application invocation interfaces
  • Clarify differences between streaming and non-streaming responses

4. Implementation Recommendations

Training materials should ideally include:

  • curl examples
  • Postman examples
  • Frontend invocation examples
  • Backend service invocation examples

5. Conclusion

The goal of API training is not for customers to memorize interfaces but to help them understand how to actually integrate Dify applications into their business systems after going live.

Public Source References

note.com

  • From “using” generative AI to “building” it: Dify x LINE Bot x RAG student workshop at Iwate University | https://note.com/protoout/n/nbea08ffeab79

zenn.dev / Official Documentation / Other Public Pages

  • API-Based Development - Dify Docs | https://docs.dify.ai/versions/legacy/ja/user-guide/application-publishing/developing-with-apis
  • External Knowledge Base API (Japanese Legacy) | https://legacy-docs.dify.ai/ja-jp/guides/knowledge-base/external-knowledge-api-documentation
  • Building a PDF Processing Workflow Application with Dify and Gradio | https://zenn.dev/tregu0458/articles/fbd86a6f3b4869
  • [Dify Introduction] Building a chatbot with custom information in Dify | https://zenn.dev/solvio/articles/9b0b34e3c3a847

Confirmed Information from Public Sources

  • The Dify API can be divided into at least chat, Workflow, and knowledge base invocation categories
  • Base URL, application type, API key, and input variable consistency are common integration pitfalls
  • API training should target “integration into business systems” rather than just demonstrating curl calls