REST API Integration

​

Integration Prerequisites

• You have ParseX console access and enter the target Workspace through the officially authorized entry; if you do not have access, contact the service provider or administrator first — do not generate or guess console URLs.
• You have validated and saved a Parse or Extract configuration with real samples and obtained its config_id.
• You have prepared compliant input file URLs; when Extract reuses parse results, you also need a valid parsed_file_biz_id.
• You have planned for the server side to securely store the biz_id returned by REST and perform async result queries once the production Base URL and official authentication method are released.

​

Finalized Business Paths

Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

​

Use Saved Configurations

- `file_url`: an accessible URL of the file to process.
- `file_name` or the file type information required by the protocol.
- `config_id`: ID of the saved Parse configuration.

For complete parameters and response fields, see the [Document Parsing API](/en/model-studio/parse/parse-submit).

- Use `file_url` when processing image-text files directly.
- Use `parsed_file_biz_id` when reusing parse results; do not pass `request_id` or identifiers inferred from the console UI. The corresponding ParseResult must be completed, of a reusable image-text type, and within the 30-day retention period.
- Use the ID of a saved Extract configuration as `config_id`.

`config_id` and inline `processing` are mutually exclusive processing definitions; when using a saved configuration, do not also pass inline parameters. For field definitions and examples of both request types, see the [Information Extraction API](/en/model-studio/parse/extract-submit).

​

Call Flow

1. Wait for the official Base URL release The production Base URL has not been publicly confirmed. Before the official production endpoint is released, do not treat the {BASE_URL} placeholder as a real address, and do not substitute it with staging or internal addresses.
2. Submit a task Once the official endpoint is available, call the corresponding submit endpoint, passing the file source, a capability-matching config_id, and the per-run parameters allowed by the protocol. Per-run parameters should not change the processing definition of the saved configuration.
3. Save request and task identifiers Save request_id and data.biz_id from the response. request_id identifies this API request, and biz_id is used to query the async business task later.
4. Query task status Call the corresponding result endpoint with the original biz_id. Keep polling while data.status is processing; stop when it is success or failed.
5. Handle results or errors On success, read the official Parse or Extract result; on failure, save the error code, request_id, biz_id, and config_id, and troubleshoot with the public error codes.

​

Status and Tracking

​

Retries and Duplicate Submissions

• The client should save its own business correlation key, submission time, and the request_id and biz_id received in the response.
• If a submit request times out without a response, the public protocol cannot automatically confirm whether the task was created; fall back to a manual or business-side reconciliation process and accept that duplicate submissions cannot be automatically ruled out.
• Use a capped backoff strategy for result queries; do not poll at high frequency.
• Only automatically retry errors explicitly marked as retryable; parameter, format, or configuration conflicts should be fixed first.

​

Related References

• API Overview: Learn about authentication, Base URL placeholder conventions, public business paths, and the async call flow.
• Error Codes: Decide how to handle errors based on HTTP status and error codes.
• Tasks and Usage: Learn about public REST task statuses and the console's "Task Records" and usage pages.