Supplier & API Partnerships with Indie Smoke

Why Indie Smoke is building supplier integrations

An ecommerce catalogue can attract buyers only when the information behind it is current. Product availability, identifiers, pack quantities, prices, images, fulfilment regions and dispatch status change over time. Manual copying creates delays and inconsistencies. A structured supplier connection makes it possible to update customer-facing information from a defined source and to handle a larger assortment without pretending that stale data is live.

Indie Smoke has invested in a searchable WooCommerce catalogue, detailed product information, brand and category content, internal product discovery and machine-readable structured data. The next commercial layer is a network of partners able to supply products and operational events with predictable quality. The objective is not to add the largest possible number of listings. It is to add eligible products that can be described accurately, ordered within an agreed market and fulfilled according to a measurable service level.

For a supplier, the value is an additional sales channel without reproducing every customer-acquisition and content task internally. For Indie Smoke, the value is a broader or more dependable offer without claiming ownership of inventory that belongs to a partner. For customers, the value is clearer discovery and fewer orders affected by outdated stock. The partnership must benefit all three groups to remain sustainable.

Priority partner profiles

Minimum commercial and operational requirements

A partner must be a verifiable business and must have the authority to offer the proposed goods. It should identify the legal entity that contracts, invoices and fulfils. It should also explain the countries it can serve, the facilities or third parties involved, the currencies accepted, tax treatment, minimum order rules and any categories that require special handling.

Product eligibility is reviewed before integration. Indie Smoke will not assume that every item in a feed can be lawfully displayed or delivered to every customer. The partner should provide the information needed to apply geography, age, brand, shipping and category restrictions. Where a licence, registration, label or warning is required, responsibility for supplying and maintaining that information must be clear.

Operational reliability matters as much as price. The partner should define stock-update frequency, order acceptance time, normal dispatch window, tracking availability, cancellation process, return responsibility and escalation contact. If the partner uses another fulfilment provider, that dependency should be disclosed because it affects data latency and service recovery.

• Verifiable company identity and authorised commercial representative.
• Documented right to distribute the products and use supplied brand assets.
• Clear fulfilment geography, restrictions and service-level expectations.
• Consistent SKU, GTIN or other stable identifiers wherever available.
• Current cost, recommended selling price rules where applicable and stock status.
• Original or authorised product images with usage rights.
• Defined process for orders, cancellations, returns, shortages and damaged parcels.
• A technical or operational owner who can resolve integration issues.

Preferred supplier API capabilities

A complete REST or GraphQL API is welcome, but the label “API” is less important than predictable behaviour. Documentation should identify authentication, environments, base URLs, request and response formats, rate limits, pagination, timestamps, time zones, error codes, versioning and support contacts. A sandbox or test account should contain representative data without exposing real customer information.

Catalogue endpoints should provide stable product IDs, names, brand, category, description, pack or unit quantity, dimensions or weight where relevant, images, status and modification timestamps. Inventory should distinguish available, unavailable, backorder and discontinued states where the supplier supports them. Price data should identify currency, tax inclusion, effective dates, quantity breaks and any restrictions on presentation.

Order endpoints should support an idempotency key so that a network retry does not create two orders. A response should return the supplier order ID, acceptance state and any line-level exceptions. Subsequent status information should distinguish accepted, rejected, processing, dispatched, partially fulfilled, delivered, cancelled, returned and refunded events as applicable. Tracking numbers should identify the carrier and tracking URL when available.

Webhooks are preferred for time-sensitive changes, with signed messages, unique event IDs, event timestamps and retry rules. If webhooks are unavailable, the parties can agree polling intervals that respect rate limits. In either model, there should be a reconciliation endpoint or report because individual events can be delayed or missed.

Alternatives when a full API is not available

A supplier without a mature API may still propose an integration if it can provide structured, repeatable and timely data. Possible starting points include scheduled CSV, XML or JSON feeds delivered through authenticated HTTPS or secure file transfer, combined with a documented order-import method and status export. Email attachments and spreadsheets edited by multiple people are rarely suitable for scale because they make version control and automation difficult.

A feed must use stable columns and identifiers. It should include a generated timestamp, currency, explicit empty-value rules and a method for marking deleted or discontinued products. Image URLs must be stable and accessible to the agreed importer. The parties should agree the update frequency and the behaviour when a feed is late, incomplete or invalid.

A staged plan can begin with catalogue and inventory synchronisation while orders are exchanged through a controlled portal. Once the commercial model is proven, the partner may add order and webhook endpoints. The proposal form should describe the current capability honestly and include a documentation or example-feed URL if available.

Commercial models

Indie Smoke is primarily interested in a percentage-based relationship tied to measurable sales volume, but the precise model depends on pricing control, fulfilment responsibility, returns and customer-service ownership. The agreement must define the base amount before applying a percentage. “Revenue” can mean gross customer payment, net product revenue after tax, revenue after discounts, or another figure; those definitions produce different results.

The agreement should identify the merchant of record, invoicing flow, payment timing, currencies, tax responsibilities, customer refund process, bad-debt treatment and audit rights. A simple model that both systems can reproduce is generally preferable to a higher theoretical percentage that cannot be reconciled.

Order lifecycle and responsibility

A partnership becomes operational when both parties know who owns each step. Indie Smoke may manage product presentation, customer acquisition and the storefront experience, while the supplier validates inventory, accepts eligible orders and fulfils parcels. The actual split can vary, but it should not be left to assumptions.

At submission, the integration should validate product ID, quantity, destination and price. The supplier should return an acceptance result within the agreed time. If an item is unavailable or a destination is unsupported, the response should be specific enough to inform the customer-service decision. Silent failures create more cost than explicit rejection.

After dispatch, tracking and status should flow back to Indie Smoke. Exceptions such as address problems, partial fulfilment, loss, damage, customs delay or return should have named escalation routes. The parties should define which team communicates with the customer and which team holds the evidence needed to resolve a claim.

Catalogue quality standards

Product content must help identify what is actually supplied. Names should distinguish brand, variant, size and pack quantity without unsupported superlatives. Descriptions should be based on packaging or manufacturer information. Images should depict the correct variant and should not contain third-party watermarks that the supplier cannot authorise.

Each item should have a stable supplier ID. GTIN, EAN, UPC, MPN and brand identifiers should be included when available rather than invented. Variant relationships should be explicit. Units should use a consistent format. If product data changes by batch or destination, the feed should say which field is authoritative and how the customer can confirm final label information.

Duplicate records, conflicting pack quantities and unavailable images reduce customer confidence and search quality. Before launch, the parties should sample the highest-priority products and compare the source record, API response, Indie Smoke listing and delivered item. A repeatable exception process is more valuable than expecting a catalogue to remain perfect without monitoring.

Inventory, pricing and change management

Inventory data should be recent enough for the sales volume and scarcity of the product. A daily update may be sufficient for slow-moving products with deep stock, while limited items may require near-real-time events. The supplier should communicate planned maintenance and identify the last successful update so the storefront can avoid treating stale data as current.

Price updates need an effective timestamp and currency. Large or unexpected changes may require a validation hold rather than automatic publication. If a supplier price changes after a customer order but before acceptance, the contract should explain whether the original order is honoured, rejected or referred for review.

Breaking API or feed changes should follow a versioning and notice policy. Removing or renaming fields without notice can affect listings and orders. The integration should have monitoring for authentication failures, schema validation, abnormal record counts, stale inventory and delayed webhooks. Technical contacts on both sides should receive actionable alerts.

Geography, eligibility and responsible commerce

A supplier proposal must name the origin and destination markets it can support. “Worldwide” should not be used unless the partner has actually evaluated the relevant product, shipping, tax, customs and age-related requirements. Restrictions may differ by product category, brand, nicotine content, packaging and customer location.

The partner should provide the information and documentation it controls, including product classification, origin, authorised distribution territory, label data and carrier restrictions. Indie Smoke and the supplier should agree how a destination becomes eligible and how changes are communicated. If either party identifies a credible restriction or recall, affected listings and orders should be paused while facts are verified.

A commercial partnership does not transfer every compliance responsibility to one side. The agreement should allocate responsibilities while recognising that each party remains accountable for its own conduct and local obligations. Independent professional advice may be appropriate before launching a new market.

Security and data protection

API credentials should be unique to the integration, limited to necessary permissions and rotated through a documented process. Transport must use current HTTPS. Secrets should not appear in catalogue files, browser code, support messages or the proposal form. Production and test environments should be separated where possible.

Webhook signatures, IP controls where practical, request timestamps and replay protection help establish that events are authentic. Logs should record technical identifiers and outcomes without collecting unnecessary personal information. Access to production data should follow least-privilege principles, and departures or role changes should trigger access review.

The parties should minimise customer data exchanged. A supplier needs only the information required to fulfil, support and reconcile the order under the agreed role. Retention, deletion, sub-processors, incident notification and international transfer issues should be addressed in the appropriate data-protection terms.

Partner onboarding process

1. Business proposal. The supplier submits the form with identity, catalogue, geography, fulfilment model, API documentation and preferred commercial structure.
2. Eligibility review. Indie Smoke evaluates strategic fit, product provenance, data quality, operational capability and whether the proposed markets can be supported.
3. Technical discovery. The teams review authentication, endpoints or feeds, sample data, update frequency, webhooks, order events, rate limits, security and support ownership.
4. Commercial and operating agreement. The parties define pricing, percentage calculations, order ownership, service levels, returns, customer communication, reporting, settlement and termination.
5. Pilot catalogue. A limited group of products is mapped and validated. Test orders cover acceptance, rejection, cancellation, tracking and reconciliation before scale.
6. Controlled launch. Eligible products are released in stages with monitoring for stock accuracy, order acceptance, fulfilment time, customer contacts and data errors.
7. Review and expansion. The parties compare agreed measures and resolve recurring exceptions before adding categories, markets or volume.

How partnership performance can be measured

A good scorecard combines sales with reliability. Gross order value alone can hide cancellations, stock errors or slow fulfilment. Useful measures may include catalogue acceptance rate, inventory freshness, order acceptance rate, time to acceptance, dispatch within service level, tracking coverage, cancellation rate, return rate, refund time, support response and completed net sales.

Definitions should be written before the pilot. For example, “dispatch time” could begin at customer checkout, payment confirmation or supplier acceptance. “Completed order” could mean carrier delivery, expiry of a return window or another event. Both systems should be able to reproduce the calculation from identifiers and timestamps.

Reviews can be weekly during launch and monthly after stabilisation. The aim is not punitive reporting; it is to identify where inaccurate data, process delay or unclear ownership prevents sales. Commercial expansion should follow evidence that the operating model works.

Frequently asked questions about Indie Smoke supplier partnerships