CSV Row Rescue: accepted rows and rejection ledger avatar

CSV Row Rescue: accepted rows and rejection ledger

Pricing

$100.00 / 1,000 completed csv inspections

Go to Apify Store
CSV Row Rescue: accepted rows and rejection ledger

CSV Row Rescue: accepted rows and rejection ledger

Inspect one pasted CSV without guessing repairs. Get literal accepted values, a rejected-record ledger, and a reconciled receipt. Experimental; no confidential data.

Pricing

$100.00 / 1,000 completed csv inspections

Rating

0.0

(0)

Developer

Picknotes

Picknotes

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

4 days ago

Last modified

Categories

Share

CSV Row Rescue

Inspect one pasted CSV and download a ZIP containing accepted rows, rejected records, and a receipt that reconciles every data record. Experimental first release. No AI, repair, inferred types, or silent row skipping.

What it does

Give it exactly two input strings: csv and delimiter. Choose comma, semicolon, or tab explicitly. The small prefilled example is synthetic.

On complete inspection, BUNDLE.zip contains exactly:

  • accepted.csv: literal accepted values, all fields quoted; the header is retained even when no rows are accepted.
  • accepted.jsonl: positional string values, record indexes, physical-line coordinates and source-record hashes.
  • rejected.jsonl: wrong-width or blank data records, including their original record text, parsed values, location and reason.
  • receipt.json: input/output hashes, limits, counts and reconciliation.

“Complete” means all data records were accounted for. A complete inspection can reject some or every data record, and a header-only file is complete with zero data records. Require status == complete and rejected == 0 if you need all records to be structurally valid; also require accepted > 0 if you need nonempty data.

Malformed quoting, invalid headers or a hard limit cause a diagnostic-only failure. Final counts are unknown. There is no accepted-prefix download, no data ZIP, and no completion dataset row for that failure. DIAGNOSTIC.json is the only inspection artifact; OUTPUT summarizes it. Operational storage failures may leave no diagnostic or a partially written/unverified ZIP. Only a matching completion dataset receipt qualifies a verified ZIP as the completed deliverable.

Limits and literal-value safety

  • One UTF-8 CSV string, up to 1 MiB (1,048,576 bytes), excluding one optional leading UTF-8 BOM
  • At most 10,000 data records, plus the header
  • Up to 8 MiB across the four core artifacts, including the receipt; ZIP overhead is capped at 4 KiB more
  • Stored platform INPUT is rejected above 2 MiB when the platform supplies its size; canonical reserialized JSON is also capped at 2 MiB
  • LF or CRLF record boundaries; bare CR outside quoted fields and ambiguous quotes fail closed
  • Unique, nonblank, literal header names; no trimming, deduplication, type conversion or repair
  • Fixed 512 MiB run memory, 45-second asynchronous work deadline and 60-second application watchdog, starting after Python imports. Startup/shutdown and platform storage billing are outside that application deadline. Set the separate platform run timeout to 60 seconds; the application watchdog does not set it for you.

Formula-like values remain literal. Opening accepted.csv in spreadsheet software may execute formulas, even though every field is quoted. Prefer the JSONL artifacts for automated use. Formula detection is a warning heuristic, not a security guarantee.

The Actor receives JSON already decoded by Apify's SDK. Request hashes in the receipt describe the Actor's canonical UTF-8 JSON reserialization, not original HTTP bytes. Original duplicate JSON keys, original JSON escape spelling and original file encoding cannot be checked at this boundary. CSV hashes describe the supplied string's UTF-8 representation. Keep the original source if you need independent source-fidelity verification. Hashes show consistency, not authenticity.

Where to get results

Open the run in Apify Console. In Storage → Key-value store, open OUTPUT and download BUNDLE.zip, or inspect DIAGNOSTIC.json on a file failure. The Dataset contains exactly one completion receipt on confirmed completion; its completionId and bundleSha256 must match OUTPUT and the downloaded ZIP. The run links open Console rather than creating public or signed file links. Authorized API clients can read these same named records through their normal credentials.

OUTPUT.status intentionally remains bundle_verified_completion_pending: it is written and read back before the sole dataset append. A matching dataset completion receipt is authoritative for completion publication, even if a run reaches its spending cap or terminates before acknowledging that append. Inspect the platform's billing details separately. Dataset and key-value storage are separate writes; cloud atomicity and exactly-once billing are not promised.

Storage and privacy

Input and output are processed and stored on Apify using the caller's run/storage settings. Storage IDs can grant read access. This Actor does not make storage private, publish it, create signed download links, or change your access restrictions. For this first release, use synthetic or non-confidential data only. Do not paste secrets, credentials, personal records or confidential business files. Keep storage IDs and exported links out of public messages. Default unnamed run storage may expire after 7 days; retention and subsequent storage access follow your Apify plan and settings. See Apify storage.

Price and completion behavior

US$0.10 per completed inspection, with platform usage during the run included. Check the live Store pricing before starting; the pricing shown there controls. Complete includes rejected/all-rejected data and header-only inputs. The completion event is apify-default-dataset-item: one event per inspection, with no start/custom fee or per-CSV-row event.

A parsing failure has no completion row. An operationally failed or aborted run can still have a committed completion row and its charge, so inspect the dataset and run billing before starting another run. Accessing retained storage after the run may incur separate platform usage, and retention is plan-dependent. See Apify pricing and pay-per-event documentation.

A low remaining completion budget produces no ZIP or completion append. Files and a manifest are saved and read back before the completion event is attempted. A lost append acknowledgment can still mean the dataset row and charge committed. The Actor never retries that append, never deletes a committed result to hide uncertainty, and refuses reused/nonempty run storage. Do not resurrect, migrate/replay, or restart a run as a retry; inspect saved evidence first. A separate new run is a separate inspection and may be charged again.

When a free tool is enough

Python's csv module, DuckDB, spreadsheets, and n8n's CSV tools are free alternatives (hosting or other service costs may apply). They may be sufficient if you only need to load a well-formed file or already maintain your own rejection accounting. This narrow offer packages literal-value outputs, a rejected-record ledger and verifiable complete accounting on Apify. Buyer adoption and willingness to pay have not been validated. It does not promise uniqueness, profitability, production readiness, or business-data correctness.

No URL fetching, file-upload workflow, batch inputs, encoding guessing, AI, dedupe, destination integration or repair is included. Local deterministic, fuzz and resource tests are evidence, not an SLA.