The Responses API provides an OpenAI-compatible interface, enabling you to directly invoke Bailing applications (agents and workflows) using existing OpenAI SDKs. It supports both synchronous and asynchronous invocation modes.
Applicability
- Region restriction: Available only for the China Mainland version (Beijing region)
- Application types: Supports agent applications and workflow applications
- API Key: Requires a valid DashScope API Key that has been obtained and configured
- Application ID: Requires a Bailing application already created with its Application ID retrieved
Prerequisites
Before using the Responses API, ensure the following conditions are met:
- API Key: A DashScope API Key has been obtained
- Application ID: An agent or workflow application has been created on the Bailing platform, and its Application ID has been retrieved
- SDK version: OpenAI Python SDK >= 1.0.0
- Python version: Python >= 3.7
Quick Start
Invocation Modes
Synchronous Invocation
Synchronous invocation is suitable for scenarios requiring immediate responses. The API maintains the connection until the task completes and returns the result.
Use cases:
- Real-time conversational interactions
- Simple query tasks
- Operations with predictable response times
- Request blocks until full response is received
- Supports streaming output
- Suitable for short-duration tasks (recommended < 30 seconds)
Asynchronous Invocation
Asynchronous invocation is suitable for time-consuming tasks. The API immediately returns a task ID, and the final result is retrieved via polling.
Use cases:
- Generating long documents or reports
- Multi-step tool calls
- Batch data processing
- Complex tasks potentially exceeding timeout limits
- Returns immediately without blocking
- Status queried using task ID
- Supports cancellation of in-progress tasks
- Does not support streaming output
Synchronous Invocation Usage
Synchronous invocation is ideal for real-time interactive scenarios where results must be obtained immediately. The API maintains the connection until the task completes.
Workflow Overview
- Initialize the client and configure the Application ID
- Construct input content (text, image, or file)
- Initiate synchronous request
- Process response result
Sending Text Messages
input: Can be a simple string; the SDK automatically converts it to standard format
Sending Multi-turn Conversations
input: Array of messages containing complete conversation history- Currently requires passing full conversation history with each request; context management via
pre_response_idwill be supported in future releases
Sending Images
Prerequisites:
- Agent applications: Must use Qwen-VL series models, select "Custom Processing" for file handling method, and republish the application
- Workflow applications: Must use Qwen-VL series models, set model input parameter variable to
imageListin the model node, and republish the application
Sending Files (Agent Applications Only)
Prerequisites:
- Supported only for agent applications
- File handling method in the application must be set to "Full-text Reference" or "Chunk Retrieval"
Enabling Streaming Output
Prerequisites:
- Workflow applications: Must enable the "Streaming Output" toggle in the end node or workflow output node, then republish the application
stream=True: Enables streaming output, returning events in Server-Sent Events (SSE) format- Primary event types:
response.output_text.delta(text delta),response.completed(response completion)
Asynchronous Invocation Usage
Asynchronous invocation is suitable for time-consuming tasks (e.g., report generation, multi-step tool calls), avoiding request timeouts through a "submit first, retrieve later" approach.
Workflow Overview
- Create asynchronous task (
background=True) to obtain task ID - Poll task status
- Retrieve result upon task completion
- (Optional) Cancel or delete task
Creating Asynchronous Tasks
background=True: Enables asynchronous mode; API immediately returns task ID- Streaming output (
stream=true) is not currently supported for asynchronous tasks
Querying Task Status
queued: Task created and waiting in queue for schedulingrunning: Task is currently executingcompleted: Task completed successfully; result available inoutputfieldfailed: Task execution failed; error details available inoutputfieldcancelled: Task was cancelled by user
Cancelling Tasks
- Only tasks in
queuedorrunningstate can be cancelled - Tasks already in terminal states (
completed,failed,cancelled) cannot be cancelled
Deleting Task Records
- Only tasks in terminal states (
completed,failed,cancelled) can be deleted - This operation is irreversible
API Reference
Request Format
Creating Responses (Synchronous/Asynchronous)
Endpoint: POST /responses
Request Parameters:
| Parameter | Type | Required | Default | Description |
|---|---|---|---|---|
| input | string | array | Yes | - | Input content; supports string or message array |
| background | boolean | No | false | Whether to use asynchronous mode |
| stream | boolean | No | false | Whether to enable streaming output (synchronous mode only) |
| conversation_id | string | No | - | Conversation ID (not supported yet) |
| pre_response_id | string | No | - | Previous response ID (not supported yet) |
Response Format
Synchronous Response
Asynchronous Response (Task Creation)
Task Management APIs (Asynchronous Mode)
Querying Task Status
Endpoint: GET /responses/{task_id}
Cancelling Tasks
Endpoint: POST /responses/{task_id}/cancel
queued or running state can be cancelled
Deleting Task Records
Endpoint: DELETE /responses/{task_id}
completed, failed, cancelled) can be deleted
Task Status Reference
| Status | Description | Supported Actions |
|---|---|---|
| queued | Task created and awaiting execution | Query, Cancel |
| running | Task currently executing | Query, Cancel |
| completed | Task completed successfully | Query, Delete |
| failed | Task execution failed | Query, Delete |
| cancelled | Task cancelled by user | Query, Delete |