Export data

Export data only when a bounded external copy is necessary for analysis, evidence, or an approved downstream workflow.

Your agent creates exports through MCP or the CLI. The Console has no exports page.

Ask your agent

"Export the checkout error logs for the incident window as CSV, then tell me when the file is ready to download."

Job	MCP tool or action	CLI command
Export a bounded log set	export_logs	anectico export logs
Export logs, traces, metrics, errors or unified search	create_export_job	anectico export create
Export a frozen analytics result	create_analytics_export	anectico analytics exports create <result-id>
List jobs, read one, or wait for it	list_export_jobs, get_export_job	anectico export jobs list, anectico export jobs get <job-id>, anectico export jobs watch <job-id>
Download a finished file	get_export_download	anectico export jobs download <job-id> --file <new-file>, anectico export jobs download-url <job-id>
Cancel or retry a job	cancel_export_job, retry_export_job	anectico export jobs cancel <job-id> --yes, anectico export jobs retry <job-id>

Exports use export:write to create, export:read to list and poll, and export:download to download; the scopes of each rule are explained below. The MCP write tools run through execute_internal_action; every mutation previews first. Creates require stable idempotency keys. See MCP tools.

What your agent gets back

An export create returns a job id to poll. A job read returns its status, progress, retry state, expiry and the content-policy fields described below. A download returns the protected file. Nothing in a job read reveals the source query.

Open the proof

Export jobs have no proof page. An export file is for your own tools. To check the analytics result that an export was made from, open that result's link; see Result viewer and Proof pages.

One-off downloads and scheduled warehouse export

The exports on this page are one-off, bounded downloads of a result or a log set that you create, inspect and download. To send your product events and cohort memberships to your own data warehouse on a schedule, without anyone downloading anything, use warehouse export: it writes Parquet or gzip NDJSON files to an S3-compatible bucket you own. Warehouse export covers product events and audiences only; for technical telemetry, use the exports below.

Scheduled warehouse work uses one monthly automated-work unit per admitted export revision and run slot. Parts and retries reuse it; a waiting event window resumes in order after allowance returns, while refused audience snapshot slots are skipped. Inspect the plan state in warehouse run history. Manual run-now and one-off downloads remain under interactive operation budgets and consume no monthly automated-work unit. See scheduled work allowance.

Export a frozen analytics result

Ask your agent to export a frozen analytics result. You can export an event measurement, a funnel participant selection, a funnel correlation selection (an outcome group or the people behind a signal), a web analytics selection (the visitors of the totals, a row or a period), a revenue selection (the payers of a currency, a period or a value, or the top payers; the export carries people or accounts and no amounts), a survey results selection (the people behind a count; the export carries people and no answer text), a heatmap selection (the people behind the totals, a cell, an element, the other entry or a scroll depth) or a retention participant selection. Choose measurement (one row containing the complete frozen result) or participants (one row per contributor in the selected population), then JSON, CSV or Parquet. The preview shows the full selection count and source expiry; the confirmed call submits that exact request. The preview describes intent, not a reservation or a promise that the source will still be available. Current permissions and source checks apply.

For an event trend, a named series exports its own contributors, and all series export their union. Selecting an empty series previews and requests zero participant rows.

After an uncertain response, repeat the identical request with the same idempotency key: it returns the existing job instead of making a second one. List the jobs before you start a new request. The job list labels analytics measurements and participants separately, shows the full source selection count separately from file rows, and lets you inspect the frozen result, snapshot and selection references. A recovered job receipt does not prove that its file is ready. When source details are withheld, the job reports them as unavailable, never as an empty population. A download streams the protected file through the authenticated API. Use the CLI for large downloads.

Use create_analytics_export through MCP's execute_internal_action, or the CLI below, to export an existing analytics result. Select the explicit project and copy the exact result, snapshot and selection UUIDs from get_analytics_result. No query is rerun under those IDs.

anectico analytics exports create <result-id> \
  --snapshot-id <snapshot-id> --selection-id <selection-id> \
  --projection participants --format json --idempotency-key checkout-export-v1

The first call reads the frozen source and returns the complete current and proposed job definition and required permissions without writing, reserving the source or consuming quota. Repeat the identical command with --confirm-token <preview-token> to enqueue it. Source expiry, erasure and permission changes can still prevent later execution. Optional --columns selects projection columns; --options-json supplies format options, with compression supported for Parquet. Creation requires mcp:write, export:write, analytics:read, persons:read and any inherited source permissions. Use a project API key or native user session; external OAuth grants cannot commission this background work. The generic signal-export REST routes reject analytics sources.

Choose measurement for the complete typed result, including its evidence and coverage caveats, or participants for every contributor in the selected population, including explicitly unresolved identities. A participant page is never the exported population. JSON preserves the structured result; CSV and Parquet encode the measurement result as JSON text. All three formats include exact source references, full selection count, computation time and source expiry. Counts do not prove source completeness. The worker currently refuses selections above a provisional one-million-contributor limit; this is not a production-capacity guarantee.

Poll with anectico export jobs get <job-id> (export:read), then use anectico export jobs download <job-id> --file <new-file> (export:download) for the authenticated artifact. These CLI lifecycle calls and the REST export endpoints also require projects:read to verify the selected project, including when an API key is pinned to that project. MCP uses get_export_job and get_export_download through execute_read_action, with the same project_id and job_id. Queued, running and completed jobs remain subject to current source, identity, retention, erasure and export-policy checks. Neither the job nor its artifact extends the source's lifetime. Source checks that cross the expiry deadline also refuse access, including metadata reads. Unavailable sources cause refusal; they are never replaced with a fresh query. Temporary source capacity or availability failures use the job's bounded retry budget; a failed source check reports analytics_source_unavailable, not instructions to change a frozen query.

Keep the same idempotency key for identical retries. An existing job can be recovered without re-admitting its source, but this does not renew access. A changed source, format, projection or authenticated actor and session conflicts. When source access cannot be verified, job metadata marks analytics_details_withheld: true; hidden counts and progress mean unavailable information, not zero events or an empty selection. CLI watch and MCP status label this explicitly.

What technical telemetry files contain

Trace exports contain one summary row per trace, with the timing, counts, services and root-span fields you select. span_count counts the spans summarized by that row; the file does not include the full span array. Preview and creation refuse the spans column for both trace and unified-search exports, with a reason explaining that these exports contain summaries.

Metric exports contain aggregate series. Unified search combines trace-summary rows and log rows; include the signal column to distinguish them.

Job receipts and status expose data_shape through REST, MCP and the CLI:

Signal	data_shape	File contents
traces	trace_summaries	One summary row per trace
metrics	metric_aggregates	Aggregate series
search	trace_summaries_and_logs	Trace summaries and logs

Other export types leave this label empty and retain their own documented contracts. Inspect it with anectico export jobs get <job-id> or anectico export jobs watch <job-id>, or MCP get_export_job through execute_read_action. These labels describe the kind of rows, not proof that capture was complete or that a raw telemetry archive was produced.

Retention and ordinary telemetry exports

Logs, traces, metrics, errors and unified-search exports use your organization's current technical retention policy. When you omit the time range, a new job freezes the last 24 hours. An explicit range must fit the readable history.

The job keeps its original time window. Retrying, finishing or downloading it requires that source window to remain readable under the current technical policy. Shortening retention past the window, an erased project or ordinary aging can make a saved job unavailable before its file-expiry time. An increase in retention does not renew that job; create a new export for a currently readable range. Repeating the same creation key only retrieves the original job. It does not refresh its authority. Content policy and source permissions are checked separately on transfers.

Deleting telemetry or explicitly erasing content in a project also invalidates ordinary exports created earlier for that project. This includes deleting a person's errors. Organization-wide exports are invalidated by an erasure in any project. The whole saved file becomes unavailable, even if its filters would exclude the erased item. While an erasure is waiting for visibility verification or content removal, new exports in that scope are unavailable. After it finishes, create a new export from the remaining data; retrying the old job cannot renew its source access.

Recorded transcripts and tool arguments also have their own content-retention limit. An ordinary export containing these bytes expires no later than the oldest included content's source time plus the shorter of those two configured windows. The file's expiry reflects that limit. An older row can therefore prevent a file from finishing; choose a currently readable range for a new export. Metadata-only rows add no content deadline. The check happens before column selection, so hiding a content column does not extend the deadline. A content-retention configuration change invalidates existing jobs that held the content entitlement, even if the new window is longer.

Export a bounded log set

Ask your agent to export a bounded log set with export_logs (CLI: anectico export logs). Anectico freezes the project, submitted query, environment, person IDs, service, severity, absolute time window, and structured field filters in the durable job. Changing the format creates a distinct export intent; retrying an unchanged intent reuses its idempotency key.

Broad signal exports (create_export_job, CLI: anectico export create) cover logs, traces, metrics, errors and unified search. Choose the signal, columns, and format. A job is pending, running, retrying, completed, failed, canceled, or expired; active jobs can be canceled and failed jobs can be retried. Ending your agent's session does not cancel a job. Creation requires export:write plus the read scope of every signal the export's rows come from (logs:read for a logs export; a unified-search export carries trace and log rows, so it needs traces:read and logs:read as well as search:read). Listing and polling require export:read. Downloading the result separately requires the owner or admin only export:download scope.

Create an export from the CLI

To create CSV, JSON, or Parquet jobs from a terminal, use the CLI:

anectico export logs --idempotency-key incident-124-logs-v1 --body '{
  "format":"csv",
  "query":"payment timeout",
  "project_id":"11111111-1111-1111-1111-111111111111",
  "service_name":"checkout",
  "level":"error",
  "environment":"production",
  "distinct_ids":["customer-42"],
  "start_time":"2026-07-20T10:00:00Z",
  "end_time":"2026-07-20T11:00:00Z",
  "filters":{"attributes.region":"eu-west-1"},
  "columns":["timestamp","severity","message","service_name","trace_id","span_id","distinct_id","attributes"]
}'

The CLI sends the active profile's project on every export lifecycle request. Select it first with anectico projects use <project-id-or-slug> (or configure ANECTICO_PROJECT) when the credential itself is not project-scoped.

Choose CSV for spreadsheet analysis, JSON for structured processing, and Parquet for larger analytic workflows. Always set the narrowest useful project, time range, filters, and columns. Invalid formats, malformed project IDs, invalid or reversed timestamps, and missing internal signal routing are rejected before a job is enqueued.

Download permissions and access changes

An export is not a standing permission. Retrying a job and downloading its result both re-check, at the moment of the request, that you still hold the read scopes its rows required and that the project's current Sent outside Anectico decision permits the recorded content in the file. So revoking someone's access to a signal, or tightening that content-policy cell, also takes away exports already produced under the older decision. If the current project decision cannot be confirmed, the download is temporarily unavailable rather than using the historical verdict stored on the job. The next download attempt is refused, and a transfer already running is stopped too, which is worth stating exactly because the two credential types differ:

• An API key. While the file is moving, Anectico re-checks the key against its authoritative record every few seconds. Revoking it, freezing it, or removing one of the scopes its rows require stops the transfer within seconds. The client is left with a file shorter than the length it was promised — a failed download in every HTTP client, which is the intended outcome: once a response has begun it cannot be turned back into a refusal, and a truncated file is better than the rest of one.
• A signed-in session. Anectico checks the current sign-in session and organization role every five seconds during a transfer. Signing out, removal from the organization, or a role downgrade that removes download or source access stops the transfer on the next check. If current access cannot be verified, the transfer stops as well. A role upgrade requires a renewed sign-in token before it can grant additional access.

Downloading is additionally limited to whoever created the job, or to an organization owner or admin; another credential in the same project sees the same not-found response as for an unknown job.

Retry the same export intent

Every create requires a stable idempotency key. Repeating the same request with the same key returns the original job; reusing the key for different input fails instead of creating a second export. CLI and MCP callers must supply the key explicitly. Use 1–128 ASCII letters, digits, ., _, :, or -; Anectico rejects surrounding whitespace, control bytes, and Unicode lookalikes rather than normalizing them into an ambiguous durable key.

A job freezes an absolute time window. Give your agent absolute start and end times, or omit them to freeze the last 24 hours.

Recorded content and project policy

An export contains no more than you could read yourself. Whether you hold agents:content:read is recorded when the job is created, and the rows are assembled against that answer — so a trace, log or metric export created by a credential without the content scope carries the same metadata you would see through the corresponding API and none of the prompts, completions, tool arguments or retrieved documents, wherever they were recorded: span attributes, log attributes, or a metric exemplar's attributes. Each affected row in the file carries an anectico.content.withheld attribute naming exactly which keys were removed, so a missing body is never mistaken for a call that had none. That inclusion answer is taken at creation and used when the file is built. It describes what is physically in the finished file; it is not a permanent download grant. Revoking the scope later leaves the file unchanged but refuses retry and download until the caller again holds the recorded source scopes.

Your project's content policy decides the same question for everyone. Your permissions answer who is asking; the content policy answers whether recorded content may leave the project through a bulk export at all. The two are combined, and the stricter one wins: a project that does not permit model transcripts to be exported produces exports without them even for an organization owner holding every scope there is, and a permissive policy never hands content to a credential that could not read it anyway.

That answer is taken when the export runs, not when it is created, so tightening the policy also applies to jobs already queued. It is then asked again on retry and download: an older file that was built with content is held back while the current cell denies it, and becomes available unchanged if the cell later permits it. Changes take up to 30 seconds to apply everywhere. Read the policy with GET /api/v1/projects/{projectId}/content-policy and replace it with PUT on the same path; reading needs governance:read and changing needs governance:write.

Inspect withheld content

When a policy withholds content, the job says so. CLI anectico export jobs get <job-id> and anectico export jobs list, REST job reads, and MCP get_export_job / list_export_jobs return the same three disclosure fields. MCP includes them in both its text and its structured job rows (data.job or data.jobs[]):

• content_policy_reason — empty while the job has not run yet, then one of allowed (the policy permits everything an export can carry), policy (your project's policy does not permit it), no_policy (no single policy could govern this export — see below), resolver_error (the policy could not be read, so content was withheld rather than released on an unverified answer), or unclassified (the content could not be classified, so it was withheld). An empty value is not the same as allowed: a queued export has not been decided yet.
• content_policy_default_posture — true when the answer came from the standard posture rather than from a grid you set, which happens for a project whose policy has not been written yet. The content still travels; the flag is what tells you it travelled on a posture nobody chose, so a file produced in that window is never mistaken for one you had approved.
• content_policy_withheld_classes — which classes of content are absent from the file (model_transcript, tool_arguments). It describes the file rather than the single rule that triggered the refusal: an export withholds recorded content as one group, so denying either class removes both.

Those fields describe the decision used to build the stored file. A later download can still be refused under the current decision even when the job says content_policy_reason: allowed; that is the expected sign that the policy changed after generation, not a contradiction in the file's disclosure record.

Rows in the file are still self-describing, and they say WHICH of the two answers withheld the content, because the two are fixed by different things. A row whose content was removed because the requesting credential was not in the sensitive-content tier carries anectico.content.withheld; a row whose content was removed because your project's content policy refuses that class carries anectico.content.policy_withheld, and no credential changes that. Either field names exactly the keys that were removed. Where both apply to one key, the policy is what is reported.

A new project uses the standard content-policy posture until its policy is initialized (within 15 minutes). Exports built under that posture report content_policy_default_posture: true; this does not mean someone explicitly approved that policy.

An export that covers your whole organization rather than one project is the exception. A content policy belongs to a project, and an organization-wide export can carry rows from projects whose policies disagree, so there is no single grid to apply and nothing is assumed on their behalf: the export carries no recorded content and reports no_policy. Scope the export to a project to get its content.

Project and retention boundaries

The project scope is captured when the job is created and cannot be widened while it runs. Project-scoped credentials remain pinned to their own project; a conflicting project_id is rejected. Organization-level users must select one project in their organization. Anectico verifies that selection before creating, listing, reading, canceling, retrying, or downloading a job; customer export operations never fall back to an organization-wide result.

The authenticated plan entitlement is also captured when the job is created. A queued export therefore cannot bypass the retention window by asking the background worker for older timestamps, or by changing fields inside query. Anectico applies the organization's current published retention state when the worker executes the job; when that state is unavailable, it falls back to the captured plan entitlement. Exporting does not make expired source telemetry readable again.

File formats and completeness

Logs CSV and JSON files use the fixed fields timestamp, severity, message, service_name, trace_id, span_id, distinct_id, and attributes. Structured maps and arrays such as attributes remain structured in JSON and are encoded as deterministic JSON inside the CSV cell. String CSV cells that could be interpreted as spreadsheet formulas are emitted as text, while normal CSV quoting, newlines, and UTF-8 are preserved.

An export reads the complete result set instead of silently stopping after 1,000 rows per signal. The search export combines traces and logs; metrics use the explicit metrics signal so metric-specific filters cannot be silently broadened. CSV distinguishes an explicitly present null value (written as null) from a missing field (an empty cell). JSON preserves explicit null values. Large jobs are streamed through bounded temporary files, and jobs that exceed the service's row or file safety ceilings fail without publishing a partial download.

Monitor and download jobs

anectico export jobs list --limit 50
anectico export jobs list --limit 50 --cursor <next-cursor>
anectico export jobs get <job-id>
anectico export jobs download <job-id> --file ./export.json
anectico export jobs download-url <job-id>
anectico export jobs cancel <job-id> --yes
anectico export jobs retry <job-id>

Each command remains confined to the active project. A job ID from a sibling project produces the same not-found response as an unknown job and cannot be inspected, mutated, or downloaded. Use the exact lowercase hyphenated UUID returned when the job was created; alternate UUID spellings such as uppercase, compact, braced, or URN forms are not accepted.

Failed jobs expose a stable error_code and a safe, actionable error message. Clients can use query_failed, format_failed, or upload_failed for consistent handling without parsing message text; export_failed is the safe fallback for an unclassified failure. Provider responses, storage object keys, request IDs, and other internal diagnostics are not included in the job response; operators can find those details in structured service logs.

Download expiry and local-file safety

Completed results remain downloadable for 24 hours and then move to expired; Anectico deletes the object and refuses further downloads. The file is served by Anectico itself rather than by a storage link, so it can be authorized while it transfers and resumed with a byte range. Downloads are served as attachments for CSV, JSON, and Parquet with the deterministic filename anectico-export-<job-id>.<format>. anectico refuses any redirect from an authenticated request when it leaves that request's initial configured endpoint origin. For exports, this covers both the metadata request made by download or download-url and every redirect while fetching the content. download also accepts the returned address only when it has exactly the configured API origin, so the credential is sent only to that endpoint. It streams to a private temporary file and atomically publishes a new destination; it never overwrites an existing file or symlink. Treat an exported file as customer telemetry: store it in an approved location, restrict access, preserve only as long as needed, and delete local copies after use. Export does not extend the retention of the source data inside Anectico.

• Search logs, traces, and metrics
• Plans, limits, and retention

Approve the complete export intent

create_export_job and export_logs return the complete normalized query, window, columns, format options and proposed job before applying. They name every source and protected-content permission needed. Creation previews reserve no quota and store no job or file. The native anectico export create and anectico export logs commands use this same flow: first preview, then repeat identical arguments with --confirm-token <token> after approval. An omitted window is resolved once by the preview and frozen on confirmation. Keep the idempotency key to recover the original job on retry. Existing jobs return their original full intent.

Cancel and retry require export:read as well as export:write to preview the current job. Retry also checks its original source and content permissions. Both previews show complete lifecycle state and the fields changed; the unchanged source definition is explicitly withheld from that lifecycle read. Cancellation stops work and removes the partial result reference, while source data and downloaded copies remain. Retry clears failure and progress, keeps the original source, creation time and attempt count, and allows three further attempts. It restores no expired data.

Current account declaration export

export_account_business_inputs or accounts business export --type company --format ndjson reads versioned current declaration pages. It is separate from saved export jobs: no frozen workspace bundle, full backup, import file or restore proof is created. Explicit financial read grants and current group_properties READ and EXPORT allowances apply independently on every page; default EXPORT is denied. A denied, revoked or unavailable policy discards that page. Preserve effective selectors, each page's time and continuation and final successful completion with counts. A failed or cancelled stream has no successful completion.

Different pages can observe changes. No global snapshot or historical valuation is promised. Clear, account erasure and declaration-time retention invalidate sensitive server content and retry bindings; minimal outcome metadata does not permit reapply after redaction and expiry. Downloaded copies are outside later erasure. Shared declarations and receipts are excluded from a member archive. See the declaration export workflow.