Already have an e-commerce site? Get free traffic via pasal.biz ingestion

Who this is for

Catalog ingestion is for sellers who:

• Already run an online store on WooCommerce, Shopify, Magento, OpenCart, Daraz, or a custom site.
• Want exposure to pasal.biz shoppers without doing manual data entry.
• Don't want to change anything about how they take payments or handle delivery — that stays on your existing site.
• Want catalog updates to flow automatically when stock or prices change.

How it works (in plain words)

1. You give pasal.biz a public URL to your product feed.
2. pasal.biz fetches the feed, parses your products, and lists them on your pasal.biz shop profile.
3. Shoppers find your products in pasal.biz — through search, neighborhood browse, or category pages.
4. When a shopper taps "Buy" or "View on site," they're forwarded to the product page on your original website.
5. You take the order, the payment, and arrange the delivery on your own site, exactly as you always have.
6. pasal.biz does not insert itself into payment, fulfillment, or returns. pasal.biz does not take a commission on the traffic. The full sale is yours.

Supported feed formats

1. CSV v1 (the simplest)

A plain CSV file hosted at a public URL. Required columns:

Only name, sku, and link are strictly required — a row missing any of those three is skipped and reported in the dashboard. Everything else is optional and the row still gets listed; you just won't have that field on the pasal.biz product page.

Example: example-csv-feed.v1.csv. Save your CSV, host it at a public URL (Dropbox public link, Google Drive shared link, your own server), and submit the URL in the seller dashboard.

Format expectations

The parser is intentionally forgiving — your existing exporter probably already produces a file we can read. Concretely:

• Column order doesn't matter. Columns are matched by header name, not position. You can ship them in any order.
• Encoding: UTF-8. A leading byte-order mark (BOM) is stripped automatically. Other encodings will likely garble Devanagari and accented characters.
• Line endings: LF, CRLF, or a mix. Either works.
• Delimiter: comma by default. Semicolon and tab are supported when set in the seller dashboard.
• Quoting: standard RFC 4180. Wrap any field containing a comma, newline, or quote in double quotes; escape internal quotes by doubling them ("").
• Whitespace around headers and cell values is trimmed.
• Blank lines anywhere in the file are skipped — including the optional trailing newline.
• Extra columns we don't recognize are ignored, not an error. Feel free to leave your Shopify export's full column set in place.

Price formats accepted

All of these parse to the same value, 1,299 NPR:

• 1299
• 1,299 (thousands separator)
• Rs. 1,299 or NPR 1299 (currency text is ignored)
• 1299.00 (trailing decimals)
• 1.299,00 (european decimal — comma as decimal separator)

0 is accepted and stored as zero. An empty price cell is treated as "no price set," not as zero, and the product is listed without a visible price.

Image URLs

• Each URL must be https:// and publicly reachable from the internet (we re-host the image after fetching it, so the source URL is only read once per change).
• Up to 3 images per product. Extra entries past the third are dropped silently.
• Separate multiple URLs with a single pipe |. Empty or whitespace-only entries between pipes are skipped.

What happens to bad rows

Each row is validated independently. A bad row never aborts the run; it's logged with a row number and a specific reason (row_invalid for missing required fields, parse_failed/schema for things like a malformed link), and the rest of the catalog still ingests. You can review the per-row diagnostics in the seller dashboard after the next sync.

2. WooCommerce (Store API)

If your store runs on WooCommerce, point pasal.biz at your storefront origin (e.g. https://your-shop.com) and we ingest natively via the public Store API:

GET ${origin}/wp-json/wc/store/v1/products?per_page=100&page=N

The Store API requires no auth, returns the same products your storefront renders, and is enabled by default on every modern Woo install. No plugin to install, no API key to ship to us. If the Store API is disabled on your site, see option 4 (WordPress) as a degraded fallback.

3. Shopify

Every Shopify storefront exposes a public /products.json endpoint. Submit your storefront URL (e.g. https://your-shop.myshopify.com) and pasal.biz paginates through:

GET ${origin}/products.json?limit=250&page=N

No auth, no plugin. Variants are flattened — each variant becomes its own ingested product, grouped under the parent so the "More variants" affordance still works in the app. Caveat: /products.json doesn't include a currency code, so pasal.biz assumes NPR (configurable per shop). If your Shopify storefront is password-protected, ingestion can't reach it; remove the password or share with us privately.

4. WordPress (wp/v2/product)

For WordPress sites with a product custom post type but no WooCommerce Store API (or an older Woo install where the Store API is disabled), pasal.biz can fall back to the generic WP REST endpoint:

GET ${origin}/wp-json/wp/v2/product?per_page=100&page=N&_embed

We read title, description, link, and the embedded featured image. This endpoint does not expose price or stock, so listings appear as "contact for price" — fine for showroom-style shops, less useful for direct buy-now flows. If you can enable the Woo Store API, prefer option 2.

5. Google Merchant Center (GMC) feed

If you already maintain a Google Merchant Center feed for Google Shopping, point pasal.biz at the same feed URL. We parse the standard GMC fields (title, link, image_link, price, availability, condition, brand, google_product_category).

Lowest-effort option for sellers already advertising on Google Shopping — no new export to set up.

6. Generic JSON endpoint

Got a custom Next.js, Django, or hand-rolled backend? Send us a small recipe describing your JSON shape and pasal.biz drives the rest:

{
  "itemsPath": "products",
  "pagination": {
    "style": "page",
    "pageParam": "page",
    "limitParam": "per_page",
    "limitValue": 100
  },
  "fields": {
    "id": "id",
    "name": "title",
    "url": "slug",
    "price": "priceCents",
    "photos": "images[].url",
    "categories": "categories[].name"
  }
}

Required fields: id, name, url. Everything else is optional. The path mini-language supports dotted paths (a.b.c) and single-step array fan-out (images[].url); anything more complex should be a dedicated adapter. Pagination supports page, offset, cursor, and none styles.

7. Sitemap + schema.org/Product (no feed at all)

Your shop has no feed, no API, no JSON — just product pages? If you publish a sitemap.xml (most platforms do, automatically), pasal.biz can crawl it and extract products directly from each page's structured data. Most modern e-commerce themes emit schema.org/Product JSON-LD blocks for Google Shopping by default; pasal.biz reads those, with an OpenGraph fallback for sites that don't.

Per-run safety caps keep things gentle: up to 200 pages per run and 50 nested sitemaps. Larger catalogs ingest across multiple runs. PasalBot identifies itself with a real User-Agent, fetches /robots.txt for every host, honours Disallow rules per RFC 9309 (longest-match wins), and respects Crawl-delay — see /bot for the public crawl policy and /robots-policy for how to block PasalBot if you don't want to be listed.

This is the slowest option (one HTTP request per product page, throttled per host), but it works for sites with zero ingestion setup. If your site has a real feed, prefer it.

What if none of the seven fits?

Email [email protected] with:

• Your platform (Magento, OpenCart, PrestaShop, Sana, custom, etc.).
• A sample of your existing product data — even one or two products in any format.
• Roughly how many products you have and how often the catalog changes.

In practice the seven adapters above cover almost every shop we've seen — between native WooCommerce / Shopify support and the sitemap+JSON-LD fallback, "my platform isn't supported" is genuinely rare. If yours is one of the rare ones, the CSV v1 path is usually the fastest workaround while we look at a native adapter.

Once your feed is connected

• pasal.biz re-fetches the feed on a schedule (usually every few hours) and updates your listings.
• You can trigger an immediate re-ingest from the seller dashboard after a big catalog change.
• Out-of-stock items disappear from pasal.biz when they disappear from your feed.
• Errors (broken images, malformed prices, missing SKUs) are flagged in the dashboard, row by row.

What stays on your site

• Your checkout flow.
• Your payment gateway (eSewa, Khalti, FonePay, IME Pay, bank, or whatever you already use).
• Your delivery operation.
• Your return policy.
• Your customer data — pasal.biz does not collect or share the buyer's details with anyone else.

pasal.biz is, for ingested catalogs, a discovery layer. Not a marketplace that gets between you and your customer.

What about traffic — what do I actually get?

Honest answer: pasal.biz forwards interested shoppers to your product link, free, and you keep 100% of everything they pay you on your existing site. We do not guarantee any specific volume of traffic. The shops that get the most forwarded traffic tend to be the ones with:

• Clear product titles and full descriptions in the feed.
• Multiple decent images per product.
• Accurate categories.
• Current stock and prices (frequent feed updates).

Common questions