AI Product Listings: Shopify and eBay Workflows

Turn approved product records into accurate listings

Selling the same stock through Shopify and eBay means maintaining different fields, listing formats and inventory states. Automation can prepare those records and publish an approved revision, but the product facts still need a reliable source.

Measure your current preparation and review time on a representative batch. Start with products whose specifications, condition and images are complete, then add exceptions deliberately. This guide covers the listing workflow; it does not promise a particular time saving or marketplace ranking.

System architecture: folder to published listing

The architecture follows a simple pipeline pattern. Product data goes in one end. Published listings come out the other. Everything in between is automated except for a human approval checkpoint.

Here's the flow:

1. A product folder (or spreadsheet row) contains raw data: photos, SKU number, condition, cost, category
2. An AI processing step generates titles, descriptions, specs, and SEO metadata
3. The output hits an approval queue where a human reviews and edits if needed
4. Approved listings publish simultaneously to Shopify via GraphQL and eBay via the Inventory API
5. Inventory counts sync from a single source of truth back to both platforms

The product folder approach works well for physical goods businesses. Each folder is named with the SKU and contains product photos, a simple text file with known specs (brand, model, condition, weight), and optionally a supplier invoice or spec sheet. When a new folder appears in your watched directory, the automation kicks off.

For businesses already working from spreadsheets, the trigger is a new row in your master inventory sheet — whether that's Google Sheets, Airtable, or a PostgreSQL database. The principle is the same: structured input triggers AI processing triggers publishing.

This is the same pattern behind most AI systems and automation projects. You define the input format, let AI handle the transformation, add human oversight at the right point, and push to downstream systems via APIs.

The key architectural decision is where your single source of truth lives. Every product should exist in exactly one place, with Shopify and eBay treated as publishing destinations rather than data stores. This prevents the inventory drift that kills multi-channel sellers — where you sell the last unit on eBay but Shopify still shows it in stock.

Generate copy from verified product facts

Supply the model with an approved record: SKU, manufacturer, model, dimensions, condition, included accessories, warranty and source references. Mark unknown fields explicitly. The model may suggest wording, but it must not fill missing specifications from guesswork.

Write readable titles containing the identifiers buyers need. Validate each platform’s current limits and category requirements rather than assuming keyword density is a ranking strategy.

Use photographs to support a condition review, not to infer hidden defects, electrical safety or undocumented compatibility. Compare extracted values with manufacturer documentation and the item itself. For used equipment, have a knowledgeable reviewer approve the condition statement and included components.

Keep generated text separate from verified attributes so an editor can change the description without silently changing the underlying product data.

Create and verify Shopify product records

Use a supported GraphQL Admin API version and the required app permissions. Pin the version in configuration and plan upgrades using Shopify’s API versioning guide.

This minimal mutation creates a draft product record; it does not configure every variant, inventory location or publication channel:

mutation CreateDraftProduct($product: ProductCreateInput!) {
  productCreate(product: $product) {
    product { id title status }
    userErrors { field message }
  }
}

Example variables:

{
  "product": {
    "title": "Verified product title",
    "status": "DRAFT"
  }
}

Consult the current productCreate reference for the selected version. Check returned user errors and save the product identifier before proceeding. Configure media, variants, inventory and publication through the appropriate supported operations, then read back the resulting record.

Keep access tokens on the server, request only needed scopes and make retries safe. A network timeout does not prove that the product was not created.

Validate eBay inventory and offer requirements

Use the eBay Inventory API documentation to map the SKU, inventory item, offer and publication steps for the target marketplace. Confirm account eligibility, category requirements and business policies before building the publish action.

Store the marketplace identifiers alongside your own SKU. Validate condition, required item specifics, price, quantity and fulfillment terms before submitting an offer. Read and retain API errors so an operator can correct the actual record.

Test in the supported sandbox and with a controlled production item before bulk publishing. Do not assume an API used by a previous listing tool is interchangeable with another, or that all legacy APIs have been removed.

Single source of truth for inventory

The fastest way to lose money in multi-channel e-commerce is selling an item on eBay that already sold on Shopify ten minutes ago. Overselling leads to cancellations, negative feedback, and platform penalties. Your automation needs a single inventory database that both platforms read from and write to.

Three options work well depending on your scale:

Google Sheets handles up to about 500 active SKUs before it gets unwieldy. A sheet with columns for SKU, quantity, Shopify product ID, eBay listing ID, price, and status gives you a visual dashboard and easy manual overrides. Your automation reads from and writes to this sheet via the Google Sheets API. The latency is higher than a database — roughly 1-2 seconds per read — but for sub-1000 SKU businesses, that's fine.

Airtable works for 500 to 5,000 SKUs and adds relational capabilities, views, and a better API. You can build filtered views showing "needs relisting," "low stock," or "price change needed" without writing queries. Airtable's webhook triggers can also kick off your automation when records change, which tightens the feedback loop. The Airtable API rate limit of 5 requests per second per base is the main constraint at scale.

PostgreSQL is the right choice above 5,000 SKUs or when you need sub-second sync times. A simple schema with products, listings, and inventory_events tables gives you full transactional safety — you'll never have a race condition where two platforms decrement the same stock simultaneously. This is the setup most AI revenue systems use because it supports real-time pricing adjustments and analytics alongside inventory management.

Whichever you pick, the rule is the same: quantities change in the source of truth first, then propagate to platforms. When an order comes in on Shopify, a webhook decrements your central inventory and pushes the updated count to eBay. When an eBay sale happens, the eBay notification decrements centrally and pushes to Shopify. Both platforms always reflect the central count, never each other's.

Workflow automation with n8n or Make

The orchestration layer connects all these pieces without custom code for every integration. n8n (self-hosted, open source) and Make (cloud-hosted, visual builder) are the two best options for e-commerce listing automation.

A typical workflow in n8n looks like this:

1. Trigger: Google Drive or Dropbox webhook fires when a new product folder appears
2. Extract: Read the folder contents — pull image files, parse any text/CSV files with product data
3. AI generate: Send verified product data and permitted image URLs to the evaluated model using your listing templates
4. Format: Split the AI output into Shopify-formatted and eBay-formatted payloads
5. Approval: Send a Slack message or email with the generated listing preview and approve/reject buttons
6. Publish: On approval, fire parallel HTTP nodes to Shopify GraphQL and eBay Inventory API
7. Record: Write the product IDs and listing IDs back to your source-of-truth database
8. Notify: Send a confirmation with live links to both listings

The approval step uses n8n's webhook-wait pattern. The workflow pauses at step 5 and resumes only when someone clicks the approve link. This keeps a human in the loop without requiring them to sit in front of a dashboard all day. They get a Slack notification with the AI-generated title and description, glance at it, hit approve, and move on. If you're interested in how similar approval workflows apply to sales processes, the patterns in AI-powered sales follow-up workflows translate directly.

Make offers the same capabilities with a drag-and-drop interface that non-technical team members can modify. The tradeoff is cost: Make charges per operation, and a high-volume listing workflow can burn through operations quickly. n8n's self-hosted option has no per-operation cost, but you're responsible for hosting and maintenance.

For either platform, build error handling into every API call. Shopify rate limits at 2 requests per second for the REST API (GraphQL uses a cost-based throttle). eBay limits vary by API and developer tier. Your workflow should retry with exponential backoff rather than failing the entire batch when one call gets throttled.

Review facts and publish a specific revision

Show the proposed listing beside the source data and photographs. Highlight missing specifications, uncertain extraction and changes from the last approved record. Let the reviewer correct facts before approving.

Record who approved which revision. Publish that revision to each destination and show separate platform outcomes. A successful Shopify operation does not imply that eBay accepted its offer.

Keep manual review for condition, compatibility, safety and other claims that require domain knowledge. Evaluate any narrower automatic path with real error data and a rollback process rather than a fixed number of examples.

Scale from measured throughput and platform limits

Use a durable job queue when publishing needs to survive retries, interruptions and rate limits. Give each job a stable identity and track preparation, approval, submission and confirmation separately.

Measure model processing, staff review and each platform’s response time. Respect the current rate limits and returned throttle information; do not assume a fixed number of products per second from an old tutorial. See Shopify API limits and the limits for your eBay application.

Use bounded concurrency and backoff. Reserve capacity for orders and stock updates so a large import does not delay inventory changes. Add more services only when measured load or operational ownership justifies the complexity.

Avoid competing product and landing pages

Let the product page own searches for that item when it already answers the buyer’s question. Improve its verified specifications, condition, images, availability and purchase information before creating another page for the same query.

Create a separate buying guide or comparison only when it solves a different problem, such as choosing between model families. Link it to the relevant products and make its purpose distinct. Do not generate a second near-identical page for every SKU simply to target a keyword variation.

When an item becomes unavailable, keep useful product information and relevant alternatives where appropriate. Decide redirects from the actual replacement relationship, not from a desire to send every discontinued URL to a category page.

Measure cost per approved listing

Record the time spent preparing source data, checking generated fields, resolving exceptions and publishing a listing. Compare that with the same process before automation. Measure approved listings, rather than drafts generated.

Include model input and output, image processing, retries, hosting, platform subscriptions and staff review. Verify current API terms and usage limits with each provider. A faster draft may still require substantial review when products have incomplete specifications or variable condition.

For a pilot, choose a representative batch that includes straightforward products and difficult exceptions. Reject unsupported specifications and compare the total effort required to publish accurate listings on each platform.

Questions before a multi-channel listing pilot

Which model should we use?

Test currently supported models on your product categories. Compare verified field accuracy, readable copy, review time, latency and cost per approved listing.

Can AI infer missing specifications?

Unknown specifications should stay unknown until verified. A plausible dimension or compatibility claim can cause a return or a safety problem.

How do platform fees affect pricing?

Use the current fee schedule for the actual marketplace, category, account and payment setup. Include shipping, returns and taxes where applicable in your margin calculation.

What happens when publication partially fails?

Retain successful destination identifiers, show the failed operation and retry only the unresolved work after reconciliation. Avoid creating duplicate listings.

Can this support another marketplace?

Evaluate its current API access, required fields, permissions and publication process. Reuse the verified source record, but test the new adapter separately.

For the data and publishing integration, see Luminous custom software services.