/api/app-api/sip/platform/v2/file/upload/sync. The difference between this interface and the regular upload interface /api/app-api/sip/platform/v2/file/upload is:
- Regular Upload Interface: Returns immediately after uploading the file, requires subsequent querying of processing results through the
/file/fetchinterface - Synchronous Upload Interface: Waits for processing to complete after uploading the file, directly returns complete processing results without additional queries
01 Upload Single File Synchronously
Upload file usingmultipart/form-data format:
02 Upload Multiple Files Synchronously
You can upload multiple files in one request. The system will wait for all files to be processed before returning:03 Upload via URL Synchronously
The synchronous upload interface also supports uploading via file URLs:04 Parameter Description
The parameters of the synchronous upload interface are exactly the same as the regular upload interface:Required Parameters
workspace_id: Workspace ID. You can refer to the Get Workspace ID documentation.
Optional Parameters
Can be added in URL query parameters as needed:category: File category (e.g., invoice)batch_number: Batch number, automatically generated by the system if not providedauto_verify_vat: Whether to enable invoice verification, default falsesplit_flag: Whether to perform file splitting, default false (see File Splitting section)crop_flag: Whether to perform multi-image cropping, default false (see Multi-image Cropping section)target_process: Target processing type, optionalclassifyorextract.
Docflow will perform the complete process of parsing->classification->extraction by default. Whentarget_processisclassify, the process ends after classification
Request Body Parameters
Supports two methods:- File Upload: Use
multipart/form-dataformat, field name isfile(can be repeated multiple times) - URL Upload: Use
application/jsonformat, containsurlsarray (up to 10 URLs)
05 Response Format
The response format returned by the synchronous upload interface is the same as the/file/fetch interface, containing complete processing results:
result.files[]: File list, each file contains complete processing resultsresult.files[].data.fields[]: Extracted field listresult.files[].data.items[]: Table data listresult.files[].data.tables[]: All table data listresult.files[].data.stamps[]: Stamp informationresult.files[].data.handwritings[]: Handwriting informationresult.files[].recognition_status: Recognition status (1 indicates success)result.files[].duration_ms: Processing time (milliseconds)
06 Use Cases
Scenarios Suitable for Synchronous Upload
- Scenarios that require immediate access to processing results
- Single file or small number of files processing
- File processing time is short (usually seconds to tens of seconds)
- Simplify code logic, avoid polling queries
Scenarios Not Suitable for Synchronous Upload
- Batch processing of large numbers of files
- File processing time is long (exceeding 1 minute)
- Scenarios requiring asynchronous processing
- Unstable network or scenarios requiring resumable uploads
For scenarios not suitable for synchronous upload, it is recommended to use the regular upload interface
/file/upload with the /file/fetch query interface to implement an asynchronous processing workflow.07 Notes
- Timeout Settings: The synchronous upload interface needs to wait for processing to complete. It is recommended to set a longer timeout (at least 300 seconds)
- Processing Time: Processing time depends on file size, number of pages, and complexity. Large files may require longer processing time
- Error Handling: If processing fails, the response will contain error information.
recognition_statusof 2 indicates failure - Batch Processing: When uploading multiple files at once, it will wait for all files to be processed, which may result in longer total processing time
- Network Stability: Since a long connection needs to be maintained, ensure network connection stability

