iPaper Integration

iPaper's own case data (cited from Danish DIY retailer 10-4) reports a 72.5% increase in webshop time after catalog visits, 87.0% more pages viewed via digital catalogs, and a 5.1% higher basket value for catalog visitors — figures that depend on the underlying product data being accurate, since price, stock, and image mismatches directly break the shopping experience inside the flipbook.

1. Hotspots and product pop-ups only work when the feed's Product ID/SKU matches the ID embedded in the PDF or template — a live feed keeps that match current as your catalog changes.
2. Horizon-style feed-based catalogs are generated directly from the feed, so incomplete or malformed data limits what layouts and product cards iPaper can build automatically.
3. Price and stock fields that change often (promotions, sell-outs) are best served by a feed rather than a one-time static file, since iPaper treats feeds and static files as different data-freshness models.
4. A single, correctly structured feed can serve both the Enrichment Automation hotspot engine and Shop Checkout/Shop Export features, avoiding duplicate manual data entry.

iPaper's Enrichment Automation is the mechanic that actually connects your feed to the catalog page. When a PDF is processed, iPaper extracts all text, hyperlinks, metadata, and the on-page position of every word. It then looks for Product IDs embedded in the PDF — as visible text, hidden text, a dedicated layer, or an Acrobat comment — and matches each one against the Product ID/SKU field in your data file or feed. Where a match is found, iPaper automatically creates the enrichment (a shop link, external link, pop-up frame, image gallery, or Product View card) and places it at that word's location.

Two matching approaches are supported: cross-referencing PDF-embedded IDs against your feed, or (for JavaScript integration) using a regular expression to extract IDs directly from the PDF text, for example matching a 6–10 digit numeric pattern, when no separate ID layer exists. iPaper documents that Product IDs can contain spaces if necessary but must never include line breaks and must not overlap with other text on the page, since either will break the match.

iPaper's Enrichment Automation accepts four data source types: .xml, .csv, .json, and a Google Merchant feed. Each of these can be supplied either as a static data file (a one-time snapshot, appropriate when product information won't change during the catalog's active period) or as a dynamic feed (a live URL, used when prices, stock, or other fields change during the flipbook's lifetime).

1. Data must be flat, not nested — iPaper's own guidance states that a flat data structure is what allows Enrichment Automation to read the file correctly.
2. By default, automation looks for header/column names starting at row 1 of the first worksheet, unless a different row or sheet is explicitly configured.
3. Header/column names must stay consistent between updates — a previously working automation can fail if a header name changes.
4. Feed URLs must use a verified branded domain, HTTPS, and RFC 2396/RFC 1738-compliant URL encoding.
5. All feed content should use valid Unicode characters.

iPaper only strictly requires one field to make matching work — a unique, persistent Product ID/SKU — but a richer feed unlocks more enrichment types (Product View cards, image galleries, shop pop-ups). If you supply data via the Google Merchant feed option, iPaper expects the standard Google Merchant Center attribute names shown below; for custom CSV/XML/JSON feeds, iPaper accepts your own column names as long as they stay consistent across updates.

iPaper also recommends keeping the same Product ID for the same product across all countries and languages, so a single automation setup can be reused across catalog localizations.

iPaper does not publish a dedicated Feedance app or one-click partner integration — it ingests product data through Enrichment Automation's generic file/feed upload, which accepts an uploaded static file or a live feed URL. Feedance's role is to make sure the data reaching that upload step already matches what Enrichment Automation expects, so the setup on iPaper's side goes smoothly.

1. In Feedance, map your source product data (PIM, ecommerce platform, or spreadsheet) to a flat, non-nested structure — no nested arrays or sub-objects, per iPaper's own flat-data requirement.
2. Choose an output format iPaper accepts: CSV, XML, JSON, or a Google Merchant Center-compatible feed if you want to reuse standard field names like id, title, and price.
3. Make sure every product row carries the same unique Product ID/SKU you use (or plan to embed) in the PDF, and keep that ID stable across languages and country versions.
4. Publish the feed from Feedance as a stable HTTPS URL with RFC-compliant encoding, then paste that URL into iPaper's Enrichment Automation data source setup as a feed (rather than a static file) if your prices or stock change during the catalog's lifetime.
5. Run a first automation pass on a test PDF or Horizon layout to confirm the header names and Product ID column are being read correctly before rolling out to a full catalog.

iPaper supports two update cadences for Enrichment Automation data sources:

1. On request — the feed is generated fresh each time a visitor loads the catalog URL. This keeps fast-changing data like price and stock as current as possible, but iPaper notes it can affect page load times.
2. On schedule — the feed is regenerated at set intervals, for example twice daily. This trades a small amount of freshness for faster catalog load speed.

iPaper's own guidance is to pick whichever cadence matches how often the underlying data actually changes: use a live feed with regular updates for promotional pricing and stock-sensitive campaigns, and a static one-time file for catalogs whose product data is fixed for the whole campaign period.

These are documented failure points from iPaper's own troubleshooting guide for Enrichment Automation, most of which trace back to the feed rather than the PDF:

1. "Custom Link Import produced no links" — the main failure notification when Enrichment Automation cannot create any enrichments from a processing run.
2. Mismatched Product IDs — if the ID in the PDF doesn't correspond exactly to an ID in the feed, that product simply won't get an enrichment.
3. Inconsistent header names — a feed that previously worked can start failing if a column header is renamed between updates; iPaper explicitly recommends checking header names first when a working automation suddenly fails.
4. Header row or worksheet in the wrong place — by default automation looks for headers on row 1 of the first worksheet only; data placed elsewhere needs to be called out in the automation settings.
5. Nested data structures — a feed with nested fields instead of a flat structure can prevent the automation from reading it correctly.
6. Non-selectable PDF text — if the underlying PDF is a scanned image rather than native text, the automation cannot find IDs to match against the feed at all, regardless of feed quality.
7. Hidden ID-layer name mismatch — when Product IDs live on a hidden PDF layer, the layer name must match exactly what's defined in the automation setup.
8. Unsupported PDF version — iPaper supports PDF 1.7 and below, with version 1.5 recommended for best compatibility.

General best practices — not sourced from an iPaper-specific document — for keeping an iPaper-bound feed healthy:

1. Keep your Product ID/SKU identical across your feed, your PDF tagging, and any other channel (webshop, marketplaces) so a single ID change doesn't have to be reconciled across systems.
2. Separate fast-changing fields (price, stock) from static fields (name, description, images) in your update logic, and refresh the fast-changing ones on a shorter interval within your feed pipeline.
3. Validate your feed against a flat-structure and encoding checklist before every publish — nested objects and non-Unicode characters are common causes of silent import failures.
4. Version or timestamp your feed exports so you can quickly tell whether an enrichment failure is due to stale data or a genuine mismatch.
5. Keep a small test catalog or PDF wired to your feed so header-name or structure changes get caught before they hit a live, customer-facing catalog.

Which file formats does iPaper accept for product data?
XML, CSV, JSON, and Google Merchant feed, supplied either as a one-time static file or as a live, regularly updated feed.

Does my feed have to use Google Merchant Center field names?
Only if you choose iPaper's "Google Merchant feed" format option. For custom CSV, XML, or JSON feeds, iPaper reads whatever column/header names you use, as long as they stay consistent across updates.

What's the one field iPaper absolutely needs?
A unique Product ID/SKU that also appears in the PDF (as visible text, hidden text, a layer, or a comment), since that ID is what Enrichment Automation uses to match feed rows to catalog pages.

Can iPaper read nested JSON or XML?
No — iPaper's documentation explicitly asks for a flat, non-nested data structure so Enrichment Automation can parse it.

Should I use a static file or a live feed?
Use a static file when your product data won't change for the life of the catalog; use a live feed when prices or stock change during that period.

My automation used to work and now produces no links — what changed?
iPaper's troubleshooting guide points first at header-name consistency and Product ID matching, then at the PDF itself (scanned/non-selectable text, wrong hidden-layer name, or an unsupported PDF version above 1.7).