Skip to main content
Once you have created an export job, you can use the APIs on this page to track its progress, inspect individual runs, and stop it if needed. This page also covers how LangSmith handles failures automatically, and what to do when an export fails after exhausting retries. This page covers:
For self-hosted and EU region deploymentsUpdate the LangSmith URL appropriately for self-hosted installations or organizations in the EU region in the requests below. For the EU region, use eu.api.smith.langchain.com.

​
Monitor export status

To monitor the status of an export job, use the following cURL command: 
curl --request GET \
  --url 'https://api.smith.langchain.com/api/v1/bulk-exports/{export_id}' \
  --header 'Content-Type: application/json' \
  --header 'X-API-Key: YOUR_API_KEY' \
  --header 'X-Tenant-Id: YOUR_WORKSPACE_ID'
Replace {export_id} with the ID of the export you want to monitor. This command retrieves the current status of the specified export job.

​
List runs for an export

An export is typically broken up into multiple runs which correspond to a specific date partition to export. To list all runs associated with a specific export, use the following cURL command: 
curl --request GET \
  --url 'https://api.smith.langchain.com/api/v1/bulk-exports/{export_id}/runs' \
  --header 'Content-Type: application/json' \
  --header 'X-API-Key: YOUR_API_KEY' \
  --header 'X-Tenant-Id: YOUR_WORKSPACE_ID'
This command fetches all runs related to the specified export, providing details such as run ID, status, creation time, rows exported, etc.

​
List all exports

To retrieve a list of all export jobs, use the following cURL command: 
curl --request GET \
  --url 'https://api.smith.langchain.com/api/v1/bulk-exports' \
  --header 'Content-Type: application/json' \
  --header 'X-API-Key: YOUR_API_KEY' \
  --header 'X-Tenant-Id: YOUR_WORKSPACE_ID'
This command returns a list of all export jobs along with their current statuses and creation timestamps.

​
Stop an export

To stop an existing export, use the following cURL command: 
curl --request PATCH \
  --url 'https://api.smith.langchain.com/api/v1/bulk-exports/{export_id}' \
  --header 'Content-Type: application/json' \
  --header 'X-API-Key: YOUR_API_KEY' \
  --header 'X-Tenant-Id: YOUR_WORKSPACE_ID' \
  --data '{
    "status": "Cancelled"
}'
Replace {export_id} with the ID of the export you wish to cancel. Note that a job cannot be restarted once it has been cancelled, you will need to create a new export job instead.

​
Failure modes and retry policy

LangSmith bulk exports handle transient failures and infrastructure issues automatically to ensure resilience. Each bulk export is divided into multiple runs, where each run processes data for a specific date partition (typically organized by day). Runs are processed independently, which enables:
  • Parallel processing of different time periods.
  • Independent retry logic for each run.
  • Resumption from specific checkpoints if interrupted.
Each run (date range) in your export has its own failure handling and retry budget. If a run fails after exhausting all retries, the entire export is marked as FAILED.

​
Automatic retry behavior

Export jobs automatically retry transient failures with the following behavior:
  • Maximum retry attempts: 20 retries per run (subject to change).
  • Retry delay: 30 seconds between attempts (fixed, no exponential backoff).
  • Run timeout: 4 hours maximum per run.
  • Overall workflow timeout: 72 hours for the entire export.

​
Failure scenarios

Failure typeCauseAutomatic retry?Action required
Infrastructure interruptionDeployments, server restarts, worker crashesYes, automatically requeued with remaining retries.None, jobs resume automatically.
Run timeoutSingle run exceeds 4-hour limitYes, retried up to 20 times (subject to change).If persistent, narrow date range, add filters, or limit the exported fields.
Workflow timeoutEntire export exceeds 72 hoursNoReduce export scope (date range, filters) or break into smaller exports.
Storage/destination errorsInvalid credentials, missing bucket, permission issuesNoFix destination configuration and create new export.
Destination deletedBucket removed during exportNoRecreate destination and restart export.
Terminal processing errorsData serialization issues, resource exhaustionYes, retried up to 20 times (subject to change).Check run error details; may require investigation.
Any single run failure (after all retries are exhausted) causes the entire export to fail.

​
Export status lifecycle

Exports can have the following statuses:
StatusDescription
CREATEDExport has been created but not yet started processing.
RUNNINGExport is actively processing runs.
COMPLETEDAll runs successfully exported.
FAILEDOne or more runs failed after exhausting retries.
CANCELLEDExport was manually cancelled by user.
TIMEDOUTExport exceeded the 48-hour workflow timeout.
Individual runs can have the same possible statuses: CREATED, RUNNING, COMPLETED, FAILED, CANCELLED, or TIMEDOUT.

​
Concurrency and rate limits

To ensure system stability, exports are subject to the following limits:
  • Maximum concurrent runs per export: 45
  • Maximum concurrent exports per workspace: 15
If you have multiple exports running, new run jobs will queue until capacity becomes available.

​
Progress tracking and resumability

The export system maintains detailed progress metadata for each run:
  • Latest cursor position in the data stream.
  • Number of rows exported.
  • List of Parquet files written.
This progress tracking enables:
  • Graceful resumption: If a run is interrupted (e.g., by a deployment), it resumes from the last checkpoint rather than starting over.
  • Progress monitoring: Track how much data has been exported through the API.
  • Efficient retries: Failed runs don’t re-export data that was already successfully written.

​
Troubleshooting failed exports

If your export fails, follow these steps:
  1. Check the export status: Use the GET /api/v1/bulk-exports/{export_id} endpoint to retrieve the export details and status.
  2. Review run errors: You can monitor your runs using the List Runs API. Each run includes an errors field with detailed error messages keyed by retry attempt (e.g., retry_0, retry_1).
  3. Verify destination access: Ensure your destination bucket still exists and credentials are valid.
  4. Check run size: If you see timeout errors, your date partitions may contain too much data. It may be helpful to limit the exported fields.
  5. Review system limits: Ensure you’re not hitting concurrency limits (5 runs per export, 3 exports per workspace).
For storage-related errors, you can test your destination configuration using the AWS CLI or gsutil before retrying the export.
Edit this page on GitHub or file an issue.
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.