July 10th, 2026
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 · optionalcollected_at_end_date· string · optional
You can now distinguish between:
created_at— when the content was originally publishedcollected_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_dateandend_dateare required when using a collection-time filterThe 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/previewand/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_atCan be combined with
result_limitAvailable 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_limitlimits rows within each UTC dayresult_limitcaps 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.
March 24th, 2026
March 24, 2026
This release adds powerful new search capabilities — boolean logic between keyword groups, wildcard & exclusion matching, proximity search, and filtering by user profile metadata and location. All features work with both /api/v1/preview and /api/v1/export.
🆕 New Features
Boolean logic across keyword groups
Parameter: group_operator · string · optional · default: "AND"
You can now combine keyword groups with AND or OR logic. Set group_operator: "OR" to match posts hitting any group instead of requiring all groups.
Example: Match (ukraine AND war) OR crimea by creating two groups with group_operator: "OR":
{ "keyword_groups": [ {"terms": ["ukraine", "war"], "operator": "AND"}, {"terms": ["crimea"], "operator": "OR"} ], "group_operator": "OR" } All other filters (dates, domains, languages) apply to both branches.
Wildcard & prefix matching
Syntax: append * to any term
Terms ending with * trigger substring matching, regardless of full_string_scan. The * is stripped and the remaining stem is searched as a substring.
regulat*→ matches regulation, regulatory, regulate, etc.sustainab*→ matches sustainable, sustainability, etc.Minimum stem length: 1 character
Works in both
keyword_groupsandexclude_keyword_groups
{ "keyword_groups": [ {"terms": ["regulat*", "legislat*"], "operator": "OR"} ] } Exclusion keyword groups
Parameter: exclude_keyword_groups · object[] · optional · max 3 groups, 20 terms each
Filter out noise by excluding posts that match specific terms — applied after inclusion matching. Same structure as keyword_groups.
{ "keyword_groups": [ {"terms": ["crypto*"], "operator": "OR"} ], "exclude_keyword_groups": [ {"terms": ["sponsored", "ad", "promo*"], "operator": "OR"} ] } In our tests, exclusion alone cut irrelevant results by over 99% on noisy queries.
Proximity search (NEAR/N)
Parameter: proximity_groups · object[] · optional · max 3 groups
Find posts where two terms appear within N words of each other (bidirectional, case-insensitive). Distance range: 1–10 words.
{ "keyword_groups": [ {"terms": ["inflation", "rate"], "operator": "OR"} ], "proximity_groups": [ {"term_a": "inflation", "term_b": "rate", "distance": 5} ] } This query found 20,000+ posts that exact phrase matching returned zero on, because the words were close but not adjacent.
⚠️ Requires keyword_groups — the API returns 400 without it.
Location filtering
Parameter: locations · string[] · optional · max 20 items, 500 chars each
Filter by user-declared profile location. Case-insensitive substring matching with OR logic.
{ "locations": ["Poland", "Warszawa", "Warsaw"] } ~25% of posts carry location data (primarily x.com)
Empty strings and whitespace are automatically trimmed/ignored
Profile & user metadata filtering
Parameter: profile_filters · object · optional · max 5 fields, 10 values per field
Filter on Twitter/X author profile attributes from the summary JSON column. Currently populated for x.com data only.
{ "keyword_groups": [ {"terms": ["bitcoin"], "operator": "OR"} ], "profile_filters": { "user_blue_verified": ["true"], "user_description": ["journalist", "reporter"] }, "domains": ["x.com"] } Multiple fields are AND-combined; multiple values within a field are OR-combined. Unknown field names are silently ignored.
🔧 Improved
Username matching
Parameter: case_sensitive_usernames · boolean · optional · default: false
Username matching is now case-insensitive by default (e.g. @RuchNarodowy and @ruchnarodowy both match). Set case_sensitive_usernames: true to enforce exact-case matching (legacy behavior).
Exact phrase matching with full_string_scan
Parameter: full_string_scan · boolean · default: false
Now documented with clearer guidance: when enabled, you get true substring/phrase matching — useful for character-level precision (e.g. distinguishing "17 year-old" from "17-year-old"). Without it, fast mode uses token-based index acceleration (Bloom filters), which handles 99% of use cases.
📋 New Parameters Summary
⚠️ No Breaking Changes
All new parameters are optional with sensible defaults. Existing queries continue to work unchanged.
📖 Full docs: exordelabs.com/developer-docs/data-export