> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Listings Processed With Errors, Alibris > Rows Alibris rejected during inbound processing, surface so the merchant fixes them before the next upload. How to read it, why it matters, and how to act... **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Marketplace](/nerve-centre/connectors#connectors-by-type) > Rows Alibris rejected during inbound processing, surface so the merchant fixes them before the next upload. ## At a glance > Count of listing rows Alibris rejected during inbound processing in the last 7 days. Each row is a listing edit (new listing, price change, condition update, stock adjust) that didn't propagate to Alibris and remains stuck on whatever state Alibris had previously. Fix once, all marketplace symptoms downstream typically clear. | | | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `COUNT(rows IN inbound_ack_files WHERE status='REJECTED')` over trailing 7 days. Each rejected row carries an `error_code` and `error_message` (see [Top Upload Error Types](/nerve-centre/kpi-cards/alibris/top-upload-error-types) for the cluster view). | | **API endpoint + report** | Alibris Inbound ack files (`/inbox/acks` directory via Pure-FTPd). Vortex IQ parses ack files at the inbound feed cadence (4 to 24h depending on configuration). | | **ISBN vs account scope** | **Per-row.** Each rejected upload row is one count. The same listing rejected on three consecutive uploads counts three times in the 7-day window. | | **Listing-quality impact** | **Direct precursor.** Today's processing errors become tomorrow's [Suspended Listings](/nerve-centre/kpi-cards/alibris/suspended-pending-listings) as Alibris's review queue catches up. Acting on this card prevents downstream suspension cascade. | | **Fees / commission** | Not applicable (this is a feed-pipeline metric, not a money figure). | | **Refunds / cancellations** | Not applicable directly. Indirect: rejected stock-update rows can leave Alibris listings showing in-stock when actually sold-out elsewhere, triggering stockout-cancellations. | | **Currency** | Not applicable. | | **Common error codes** | (1) `INVALID_ISBN` (\~28% of rejections), malformed or non-existent ISBN. (2) `CONDITION_NOTE_TOO_SHORT` (\~20%), under Alibris's 25-character minimum. (3) `MISSING_REQUIRED_FIELD` (\~17%), category, binding, or weight missing. (4) `DUPLICATE_LISTING` (\~12%), same ISBN+condition already listed. (5) `IMAGE_URL_UNREACHABLE` (\~10%), 404 or timeout on image fetch. (6) `OTHER` (\~13%). | | **Multi-marketplace overlap** | Per-marketplace. Different marketplaces have different validation rules (Alibris: 25-char condition minimum; AbeBooks: 40-char minimum), so the same data row can pass on one marketplace and fail on another. | | **Time window** | `7D` (trailing 7 days, the typical fix-cycle window). | | **Alert trigger** | `>0`, every rejected row is an unresolved data issue. | | **Roles** | owner, operations. | ## Calculation Calculated automatically from your Alibris data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example A US bookseller, 32,100 active Alibris listings, daily outbound feed cycle. Snapshot 01 May 26, trailing 7 days 24 Apr 26 to 01 May 26. | Error code cluster | Rows rejected (7d) | Estimated 30D revenue impact if unresolved | | ---------------------------------------------------- | ------------------ | ------------------------------------------ | | INVALID\_ISBN (10-digit format) | 38 | -\$520 | | CONDITION\_NOTE\_TOO\_SHORT (\<25 chars) | 24 | -\$280 | | MISSING\_REQUIRED\_FIELD (binding) | 18 | -\$210 | | DUPLICATE\_LISTING | 14 | -\$160 | | IMAGE\_URL\_UNREACHABLE | 11 | -\$130 | | OTHER | 12 | -\$140 | | **Total Listings Processed With Errors (this card)** | **117** | **-\$1,440** | Card reads **117**. Alert is firing (threshold `>0`). Six things to notice that are specific to Alibris and the book trade: 1. **The INVALID\_ISBN cluster (38 rows, 33% of impact) is almost always upstream data.** All 38 had ISBN-10 format from a 1990s metadata provider; Alibris's API requires ISBN-13. A one-off conversion script (`isbn10_to_isbn13(value)`) applied at upload-time clears this category permanently. Most modern inventory tools include the conversion; legacy custom feeds often don't. 2. **CONDITION\_NOTE\_TOO\_SHORT (24 rows) reflects a different threshold from AbeBooks.** Alibris requires 25 characters minimum; AbeBooks requires 40. A bookseller writing 30-character notes passes Alibris but fails AbeBooks; writing 50-character notes passes both. Standardise on 50+ characters as a single house style. 3. **MISSING\_REQUIRED\_FIELD (binding) reveals a subtle data gap.** Alibris requires a `binding` field (Hardcover / Paperback / Audio / etc.) on every listing; some legacy inventory imports only had it for hardback (assumed paperback default). The fix is upstream: ensure `binding` is populated for all rows, not just the non-default ones. 4. **DUPLICATE\_LISTING (14 rows) suggests an intake-process issue.** Same ISBN + same condition can't be listed twice on Alibris; a duplicate signals a buy-back-from-customer or warehouse-find that wasn't reconciled with existing stock. The fix is at the inventory level (merge stock counts) before re-uploading. 5. **IMAGE\_URL\_UNREACHABLE often clusters around expired CDN signatures.** If your inventory tool generates pre-signed S3 URLs with 7-day expiry but listings are uploaded daily, listings older than 7 days may have stale URLs by the time Alibris fetches. Use unsigned public URLs or extend the signature window. 6. **117 errors over 7 days is roughly normal for a 32,100-listing catalogue (\~0.36% rejection rate).** Below 0.5% is healthy; 0.5% to 1% is degraded; above 1% indicates a systematic feed problem. The bookseller here is fine but should fix the INVALID\_ISBN cluster proactively because it's permanently rejecting good data. ## Sibling cards merchants should reference together Processing errors are the leading indicator. Pair with these to act: | Card | Why pair it with Listings Processed With Errors | | ---------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | [Top Upload Error Types](/nerve-centre/kpi-cards/alibris/top-upload-error-types) | The cause-attribution view; clusters error\_codes for batch fixing. | | [Suspended Listings](/nerve-centre/kpi-cards/alibris/suspended-pending-listings) | The downstream consequence. Today's processing errors become tomorrow's suspensions. | | [Failed Batches (7d)](/nerve-centre/kpi-cards/alibris/failed-batches) | The batch-level view. A single failed batch can produce dozens of processing errors. | | [Last Successful Upload](/nerve-centre/kpi-cards/alibris/last-successful-upload) | If recent uploads succeeded but processing errors are climbing, the cause is data quality not feed connectivity. | | [Revenue at Risk (live)](/nerve-centre/kpi-cards/alibris/revenue-at-risk) | The financial weighting; converts the count into \$/day at risk. | | [ISBN Coverage](/nerve-centre/kpi-cards/alibris/isbn-coverage) | Prevention. Stronger ISBN coverage reduces INVALID\_ISBN rejections. | | [AbeBooks Listings Processed With Errors](/nerve-centre/kpi-cards/abebooks/listings-processed-with-errors) | Sibling marketplace mirror. Cross-correlation surfaces shared root causes. | ## Reconciling against the vendor's own dashboard **Where to look in the Alibris seller dashboard:** Two views matter: 1. [**Sellers → Inventory → Upload History**](https://www.alibris.com/sellers/upload-history). Per-batch detail with rejection reasons and row counts. 2. [**Sellers → Inventory → Manage**](https://www.alibris.com/sellers/inventory). Spot-check a specific listing the alert flagged; if Alibris shows the OLD state, the rejection is confirmed. **Why our number may legitimately differ from Alibris's UI:** | Reason | Direction | Why | | ------------------------------ | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Refresh cadence** | Theirs immediate; ours every 4 to 24h | Alibris's UI shows rejection reasons in real time; our card recomputes at the inbound feed cadence. A rejection 30 minutes ago appears in Alibris UI before this card. | | **Ack file format edge cases** | Either | Some legacy Alibris ack file formats encode "warning" alongside "rejected"; the card counts only true rejections. The Alibris UI sometimes shows warnings as errors. | | **Re-upload deduplication** | Ours can show ghost errors | If a row was rejected, fixed, and re-uploaded successfully in the trailing 7 days, our count may still show the original rejection until it ages out of the 7-day window. | | **Outbox-empty edge case** | Card silent during quiet period | If no outbound files were uploaded in 7 days, no inbound acks land, no rejections to count. The card shows zero, which is correct. | **Cross-connector reconciliation:** | Card | Expected relationship | What causes legitimate divergence | | ------------------------------------------------------------------------------------------------------ | ---------------------------------- | ----------------------------------------------------------------------------------------------- | | [`abebooks.ab_processed_with_errors`](/nerve-centre/kpi-cards/abebooks/listings-processed-with-errors) | Often correlates within 24 to 48h. | Different validation rules per marketplace mean the same data row passes one and fails another. | | [`amazon.amzn_processed_with_errors`](/nerve-centre/amazon/amzn_processed_with_errors) | Amazon stricter, more errors. | Amazon enforces GTIN, tax-class, and category-restriction rules absent on Alibris. | ***
Marketplace-peer documentation cross-reference Inbound processing errors exist on every marketplace's feed pipeline. Each marketplace's validation rules differ. * [`abebooks.ab_processed_with_errors`](/nerve-centre/kpi-cards/abebooks/listings-processed-with-errors) * [`amazon.amzn_processed_with_errors`](/nerve-centre/amazon/amzn_processed_with_errors)
## Known limitations / merchant FAQs **The card jumped from 8 to 117 errors in one week. What just happened?** Three causes account for nearly every overnight spike: (1) **A bulk inventory upload from a new data source** with format issues. (2) **An Alibris validation rule update** (Alibris occasionally tightens rules; legacy data fails on the new threshold). (3) **A staff-initiated CSV import** with column-shift error. **ISBN match quality, can it cause cascading errors?** Yes. INVALID\_ISBN errors can be the visible symptom of an upstream data problem (wrong ISBN against right physical book). Once corrected, the listing-data process improvement reduces errors AND returns AND seller-reputation hits across all three marketplaces. **How much real revenue is this costing me right now?** Per the worked example, \~\$1,440/month on Alibris alone for 117 errors. Multiply by 2 to 3x for cross-marketplace impact. The fix-cost is engineering hours; the recovery is full and recurring. **Multi-marketplace, can a single fix close errors across all marketplaces?** For data-quality root causes (ISBN, condition note length, missing fields), yes. Marketplace-specific rules (Alibris's 25-char vs AbeBooks's 40-char condition note) require per-marketplace tuning, but if you standardise on the strictest threshold (50+ chars), all marketplaces pass. **Listing-quality / Buy Box impact, what's the timing?** Errors surface here within 4 to 24h of upload; if not fixed, downstream suspensions appear within 48 to 96h; downstream search-rank impact appears within 7 to 14 days. The card is the earliest leading indicator. **Inventory-sync lag, can it inflate this card?** Indirectly. Stale image URLs, duplicate listings caused by stockout-not-decremented, and similar lag-driven issues produce errors. Real-time inventory sync reduces error count by 20 to 40% in observed cases. **Rare books vs commodity books, which generates more errors?** Commodity books generate more errors by volume (more rows uploaded daily). Rare books generate more error PER LISTING because they often have older bibliographic data, ISBN ambiguity, and more complex condition descriptions. Both need attention; rare-book errors are higher-value to fix. **Why don't I just batch-fix everything at once?** You can, and should. The "fix once" rule: identify the dominant error\_code via [Top Upload Error Types](/nerve-centre/kpi-cards/alibris/top-upload-error-types), apply the fix to all matching rows in one update, re-upload in a single batch. Don't fix listings one-at-a-time; the engineering cost ratio is 50:1 for batch vs row-by-row. **When does the card update vs my action?** Card recomputes at the inbound feed cadence (4 to 24h). After re-uploading fixed rows, the card may take one full cycle to update. Don't expect immediate clearing. **What's a healthy rate for a busy bookseller?** Below 0.5% rejection rate (errors / total rows uploaded in the same period) is healthy. 0.5% to 1% is degraded; above 1% indicates a systematic feed problem worth dedicated engineering time. *** ### Tracked live in Vortex IQ Nerve Centre *Listings Processed With Errors* is one of hundreds of KPI pulses Vortex IQ tracks across Alibris and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.