Cloud Run → Cloud Data → export destination
The run creates the data. Cloud Data stores the records and export state. A file export, database connection, Google Sheets integration, cloud storage destination, or OpenAPI workflow then delivers the records downstream.
When data is ready to deliver
A run being marked Completed does not mean that every destination has received the data. Octoparse finishes the stages in this order:- The cloud executor runs the task and produces records.
- Records are uploaded and stored as Cloud Data.
- Octoparse updates the run statistics and export state.
- The configured destination reads the available records and reports success or failure.
Choose an export method
Configure automatic export
1
Validate the task output
Run a representative Cloud Extraction and check fields, pagination, record count, duplicate rows, and missing values in Cloud Run Details.
2
Choose the destination
Open the task’s export or automation settings and select a file, database, Google Sheets, cloud storage, or API workflow.
3
Connect the destination
Authorize the account or enter the database, storage, or API settings. Give the connected account write access to the target.
4
Define export behavior
Set the file format and name, table and field mapping, target sheet, folder or bucket, and whether repeated exports append, replace, or create a new file.
5
Test one run, then automate
Send a small result first. Confirm the destination and the Octoparse run log, then enable the schedule or recurring export.
Export options
Files
Cloud data can be exported as CSV, Excel, JSON, HTML, or XML. Use CSV for broad compatibility, Excel for manual review, and JSON for application or API processing. Decide how repeated files should behave before enabling a schedule: keep a timestamped history, replace the previous file, or append where the destination supports it. If the target is a folder on your own computer, use the local auto-export workflow. A cloud-only workflow should deliver the file to cloud storage or retrieve it through OpenAPI instead of depending on a device being online.Databases
Octoparse supports automatic export to MySQL, SQL Server, PostgreSQL, and Oracle. Prepare the destination table first, then verify the host, port, database, credentials, network rules, column types, primary-key behavior, and encoding. Map every task field to a destination column and run a test insert before enabling recurring export. Automatic database export uses new or non-exported Cloud Data. If a run produces no new records, a successful export may contain nothing to insert. Treat that as an empty result, not as a connection failure. If you add, remove, or reorder fields in an OTD or Python task, clear the task’s historical Cloud Data and run the task again before exporting. Existing records may still use the previous field mapping. Python templates should use a predefined, stable field set; dynamically adding fields can result in only the first record’s field structure being exported.Google Sheets
Authorize the Google account, choose the spreadsheet and sheet, and test with a small result. Automatic Google Sheets export sends non-exported records and expands the sheet as new data arrives. Confirm that the connected account can edit the target and that the sheet has enough rows and columns for the task output.Cloud storage
Octoparse can export files to Google Drive, Dropbox, and Amazon S3. Google Drive and Dropbox use an authorized account and a folder; Amazon S3 uses an access key, secret key, service area, and an existing bucket. Choose the format and file naming rule, then define what happens when a file with the same name already exists. Cloud storage export is available on Professional and Enterprise plans.OpenAPI
Use OpenAPI when the destination is a custom application or when your team needs its own orchestration. A typical incremental workflow is:- Start or monitor the Cloud Extraction.
- Wait until Cloud Data is available for the run.
- Request non-exported data, or read a designated batch by offset.
- Write the records to the downstream system.
- Mark the records as exported only after the downstream write succeeds.
Dependencies to verify
Automatic export depends on more than the destination connection:- Cloud execution: the task must run in Cloud Extraction and produce records.
- Cloud Data state: records must finish uploading and become available for export.
- Destination access: credentials, folder or table permissions, and database network rules must remain valid.
- Export settings: field mapping, file naming, overwrite behavior, and export intervals must match the workflow.
- Capacity and timing: scheduled runs need enough cloud capacity, and an export must finish before the next one starts.
- Downstream idempotency: use non-exported records, a cursor, a primary key, or another deduplication rule for recurring exports.
Diagnose export failures
Cloud Run Details and subtask logs explain how the data was scraped. Destination or integration logs explain what happened after the records became Cloud Data. Check both when a run is successful but the downstream system is not updated.
Recommended operating pattern
Use Cloud Extraction for unattended runs, validate the first result, and deliver a small sample before enabling a recurring schedule. Keep the task output stable after the destination is configured. Monitor the first few deliveries, then use run history and destination logs to verify record counts, latency, and failures. For high-volume workflows, prefer a database, cloud storage, or OpenAPI pipeline over a spreadsheet.Related pages
Monitor cloud runs
Check run status, data volume, subtasks, logs, and screenshots.
Schedule cloud runs
Run a task automatically on a recurring schedule.
Export formats
Choose a file format for downstream systems.
Octoparse OpenAPI
Build a custom data export workflow.