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:

	LimitCurrent value
Keyword groups	5
Inclusion terms per group	400
Exclusion groups	3
Exclusion terms per group	20
Maximum term length	500 characters

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:

	PlanSearchable history
Free	90 days
Pro	365 days
Enterprise	Unlimited

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:

		PlanPreviewExport
Free	10/min · 60/hour	5/min · 20/hour
Pro	30/min · 400/hour	15/min · 120/hour
Enterprise	100/min · 2,000/hour	50/min · 600/hour

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

		ParameterTypeScope
`collected_at_start_date`	string	Preview and export
`collected_at_end_date`	string	Preview and export
`url_patterns`	string[]	Preview and export
`result_limit`	integer	Export
`per_day_limit`	integer	Export

⚠️ 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.