https://exordelabs.com/developer-docs/data-export

The Exorde Data Export API has received a major performance and scalability upgrade, with especially large improvements for historical searches.

Customers can now submit large batches of exports without managing their own scheduler: jobs are queued automatically, up to 100 exports per customer, and the platform runs up to 8 exports in parallel. We have also expanded search limits, introduced collection-time filtering, and added more control over the size and distribution of exported datasets.

⚡ Major performance upgrade

Search and export execution has been substantially optimized across both recent and historical data.

The API now routes queries more efficiently between active and historical datasets, avoids unnecessary historical scans, and processes large exports through a more scalable execution pipeline. This particularly improves queries covering older data, which previously carried substantially higher startup and processing costs.

Improvements include:

• Faster preview counts and sample retrieval

• Faster startup for large exports

• More efficient historical-data searches

• Better handling of complex keyword and phrase queries

• Improved streaming for large JSONL and CSV files

• Higher parallel processing capacity

• Automatic retry handling for temporary processing or network failures

Performance still depends on the date range, filters, search mode, and number of matching rows, but the system can now sustain significantly larger workloads.

🗂️ Automatic export queueing

Export requests no longer need to be carefully submitted one at a time.

Customers can submit multiple exports in succession, and the API automatically places accepted jobs into a queue. Each job moves through the normal lifecycle:

pending → running → completed

The platform now supports:

• Up to 100 queued exports per customer

• Up to 8 exports running in parallel

• Automatic FIFO-style job promotion as capacity becomes available

• Fair per-customer scheduling

• Automatic slot recovery if a worker is interrupted

• Automatic retry handling for temporary failures

A pending response means the job was accepted and is waiting for execution; no resubmission is required. Continue polling the regular status endpoint until the job becomes running, completed, failed, or rejected.

GET /api/v1/export/{job_id}

Clients may also check capacity before submitting:

GET /api/v1/queue-capacity

When the queue is saturated, the API returns HTTP 503. Wait with exponential backoff rather than immediately resubmitting the same request.

🕒 Filter by collection time

New parameters:

• collected_at_start_date · string · optional

• collected_at_end_date · string · optional

You can now distinguish between:

• created_at — when the content was originally published

• collected_at — when Exorde collected the content

The existing start_date and end_date parameters continue to define the primary created_at range. The new parameters apply an additional collection-time filter.

{ "keyword_groups": [ { "terms": ["bitcoin", "ethereum"], "operator": "OR" } ], "start_date": "2026-07-09T12:00:00Z", "end_date": "2026-07-10T12:00:00Z", "collected_at_start_date": "2026-07-10T10:00:00Z", "collected_at_end_date": "2026-07-10T12:00:00Z" }

This returns content created during the specified 24-hour period and collected during the specified final two hours.

Key behavior:

• Either collection-time bound may be used independently

• Explicit start_date and end_date are required when using a collection-time filter

• The collection interval does not need to fit inside the creation interval

• Lower bounds are inclusive and upper bounds are exclusive

• ISO 8601 timezone offsets are accepted and normalized to UTC

• Available on both /api/v1/preview and /api/v1/export

📈 Larger keyword searches

The maximum number of inclusion terms has increased from 20 to 400 terms per keyword group.

{ "keyword_groups": [ { "terms": [ "brand one", "brand two", "product name", "alternative spelling" ], "operator": "OR" } ] }

Current keyword limits:

This makes it practical to search large entity lists, brand catalogs, aliases, multilingual terms, or monitoring dictionaries in a single request.

📅 Larger date windows

Standard preview and export requests can now cover up to 45 days in one query.

Exports using per_day_limit can cover up to 90 days, subject to the history available under the customer’s plan.

Plan history limits remain:

The date-span limit controls the width of one request. The plan history limit controls how far back its start_date may go.

📊 Balanced daily exports

Parameter: per_day_limit · integer · optional · export only

per_day_limit limits how many rows can be returned for each UTC created_at day. It is useful when building a balanced dataset across several days or weeks without allowing one high-volume day to dominate the export.

{ "keyword_groups": [ { "terms": ["climate", "energy"], "operator": "OR" } ], "start_date": "2026-06-01T00:00:00Z", "end_date": "2026-07-01T00:00:00Z", "per_day_limit": 5000, "output_format": "csv" }

• Range: 1–100,000 rows per UTC day

• Maximum span: 90 days

• Day boundaries are based on created_at

• Can be combined with result_limit

• Available on /api/v1/export

For example, per_day_limit: 5 across 30 days allows up to 150 rows. Adding result_limit: 50 caps the complete export at 50 rows.

🎯 Control export size

Parameter: result_limit · integer · optional · export only

Use result_limit to cap the total number of exported rows without changing the preview count.

{ "keyword_groups": [ { "terms": ["artificial intelligence"], "operator": "OR" } ], "start_date": "2026-07-01T00:00:00Z", "end_date": "2026-07-10T00:00:00Z", "result_limit": 100000 }

Accepted range: 1–200,000,000 rows.

When both controls are present:

• per_day_limit limits rows within each UTC day

• result_limit caps the complete export

This provides more predictable file sizes and quota usage for large searches.

🔗 Search by URL pattern

Parameter: url_patterns · string[] · optional · max 20

Search for posts whose URL contains one of the supplied patterns. Matching is case-insensitive, and multiple values use OR logic.

{ "url_patterns": [ "reddit.com/r/france", "youtube.com/channel/", "example.com/news/" ], "start_date": "2026-07-01T00:00:00Z", "end_date": "2026-07-10T00:00:00Z" }

url_patterns is a selective filter, so keyword_groups is optional when URL patterns are supplied.

💬 Exact phrase matching

Wrap a multi-word term in double quotes to require the words in the same order with whole-word boundaries.

{ "keyword_groups": [ { "terms": [ "\"climate change\"", "\"machine learning\"", "\"interest rates\"" ], "operator": "OR" } ] }

Exact phrases can be combined with normal terms and wildcard searches in the same request.

Use quoted phrases when word order matters and separate occurrences of the same words would create noisy matches.

⚡ Higher rate limits

Preview and export requests now have separate plan-based limits:

Requests are weighted by their created_at span in seven-day units:

• 1–7 days: 1 unit

• 8–14 days: 2 units

• 15–21 days: 3 units

• 22–28 days: 4 units

• 29–35 days: 5 units

When the API returns HTTP 429, always use the Retry-After header before retrying.

🔧 Improved reliability

Duplicate-export protection

Identical export requests submitted by the same API key within five minutes are detected automatically.

Instead of creating duplicate work, the API returns HTTP 409 with the existing job ID. Clients should poll that job rather than submit the same request again.

Stricter validation

Unknown or misspelled request parameters now return HTTP 422 instead of being silently ignored. Unsupported profile_filters fields are also rejected.

This makes integration mistakes easier to detect before a large export begins.

Consistent date boundaries

Date intervals now consistently follow:

start <= timestamp < end

The starting timestamp is included and the ending timestamp is excluded. This allows adjacent time windows to be combined without duplicating rows at their shared boundary.

📋 New parameters

⚠️ Compatibility note

All new filters and export controls are optional, so existing valid requests continue to work unchanged.

The main integration-sensitive improvement is stricter request validation: unknown properties and unsupported profile fields now produce HTTP 422 rather than being ignored. Check existing payloads for obsolete or misspelled

https://exordelabs.com/developer-docs/data-export

fields before migrating high-volume workloads.