Commerce operations automation · Connect · Automate · Orchestrate · Flat-fee pricing

    SupportPartners
    Sign In
    Dropship · Retailer compliance
    Shopify integration logo
    Shopify
    DSCO (Rithum) integration logo
    DSCO (Rithum)

    Connect Shopify + DSCO (Rithum)

    Automate retailer dropship order, item mapping (retailer sku ↔ shopify variant), availability feed, fulfilment + tracking, cancellations and changes between Shopify and DSCO (Rithum) — with monitoring and managed support from APIWORX.

    See How It Works

    APIWORX connects the systems your business already uses and takes responsibility for the agreed integration workflows after go-live. The exact objects, direction and cadence are fixed in writing during scoping.

    ERP + eCommerce Specialists
    Managed & Monitored Integrations
    Expert Integration Team
    APIWORX Provides the Service

    Yes. APIWORX connects Shopify and DSCO (Rithum).

    But connecting the applications is only the beginning. The work that costs you time sits in the process running between them.

    APIWORX automates that process end to end — the objects moving between Shopify and DSCO (Rithum), the ownership rules that decide which system wins, the exceptions when a record will not post, and the monitoring that tells someone before your team finds out from a customer.

    How it works

    From requirements to a managed integration

    1

    Tell Us What You’re Connecting

    Provide the systems, workflow and business requirements.

    2

    We Design the Integration

    APIWORX recommends the integration architecture, mappings and implementation approach.

    3

    We Build, Monitor & Support It

    APIWORX implements the integration and provides ongoing monitoring and support as applicable.

    Who this is for

    For brands using Shopify as their commerce and inventory backbone who have taken on retailer dropship programmes through DSCO.

    What needs to be in place

    • Shopify or Shopify Plus with app/API access and the locations that hold sellable stock identified.
    • An active DSCO supplier account with retailer programmes already onboarded.
    • A fulfilment operation — in-house or 3PL — able to return tracking detail.
    • A decision on whether retailer orders should exist as Shopify orders.

    When you may not need this

    One retailer and a trickle of orders can be worked in the portal. Integration matters when several retailer programmes compete for the same stock, when DTC and wholesale reporting must stay separable, or when confirmation timeliness is affecting your scorecard.

    What is out of scope

    • APIWORX does not onboard you to a retailer or manage your supplier agreement.
    • Routing-guide, packaging and labelling compliance remains your operational responsibility.
    • Whether your account uses a given DSCO interface is confirmed in scoping.

    What actually moves, and who owns it

    A representative Shopify dropship scope. The retailer-order placement decision drives most of it.

    ShopifyAPIWORX (mapping, retries, exception queue)DSCO (Rithum)
    Objects exchanged between Shopify and DSCO (Rithum), with system of record, trigger, failure handling and owner
    Object From To System of record Trigger If it fails Owner
    Retailer dropship order DSCO Shopify (per agreed model) Retailer (via DSCO) New order polled on an agreed cadence Held in exception queue with the mapping error APIWORX
    Item mapping (retailer SKU ↔ Shopify variant) Agreed mapping Shopify Shopify Per order line Unmapped SKU raises a named exception APIWORX (maintenance) / you (approval)
    Availability feed Shopify (nominated locations) DSCO Shopify Scheduled publish on an agreed cadence Last good feed stands; failure alerted APIWORX
    Fulfilment + tracking Shopify / 3PL DSCO Shopify Fulfilment created Retailer rejections queued with reason codes APIWORX
    Cancellations and changes DSCO Shopify Retailer (via DSCO) Change received before fulfilment Escalated when already despatched APIWORX (delivery) / you (decision)
    Invoice / cost confirmation Shopify or your finance system, as agreed DSCO Agreed in scoping Order shipped Rejections queued for correction APIWORX

    Three decisions that make or break this integration

    Retailer orders versus direct-to-consumer orders

    The first decision is whether a retailer order should exist inside Shopify at all. Creating them keeps one fulfilment process; keeping them out keeps DTC analytics and marketing attribution clean. Both are legitimate, and the choice needs to be conscious.

    • If retailer orders are created in Shopify: tagging, separate channel attribution and price handling that does not distort DTC reporting.
    • If they are not: fulfilment instructions flow to your warehouse or 3PL directly, with Shopify used only for inventory truth.
    • Either way, retailer cost is kept distinct from consumer retail price.
    • The decision is recorded in the scope so reporting expectations match reality.

    Inventory allocation and ownership

    Retailer programmes and your own storefront draw on the same physical stock. Whichever way orders are represented, Shopify remains the quantity of record, and the feed is what protects you from overselling either side.

    • Nominated Shopify locations count towards the retailer feed; the rest are excluded.
    • Per-retailer or per-item buffers applied at publish time.
    • Publish cadence chosen against your order pattern and how quickly stock turns.
    • A failed publish is treated as an incident — the last good feed stands and the team is alerted.

    Fulfilment updates and exceptions

    Retailers measure confirmation speed and accuracy. Building confirmations from the Shopify fulfilment (or your 3PL feed) removes the portal step and the transcription errors that come with it.

    • Tracking, carrier and shipped quantity taken from the fulfilment record.
    • Partial fulfilment reflected explicitly rather than collapsed.
    • Rejected confirmations queued with the retailer's reason code and worked by APIWORX.
    • Late cancellations escalated to your ops contact as a decision, not silently ignored.

    Reliability and ownership

    Dropship scorecards degrade quietly. These arrangements make the failure visible while it is still fixable.

    • Every run is logged with the source record reference so a document can be traced end to end.
    • Failed messages are retried on a defined schedule; anything that still fails lands in an exception queue rather than being dropped silently.
    • Duplicate prevention keys on the source system's own identifier (order number, PO number, document ID) so a replayed message does not create a second record.
    • Exceptions are worked by the APIWORX team and escalated to your named contacts when a business decision is needed.
    • Mapping changes — new SKUs, new accounts, new dimensions, new trading-partner requirements — are handled as part of the ongoing engagement.
    • Response commitments and support windows are set in your agreement; this page does not state an SLA.

    Illustrative order mapping

    Illustrative example — not a customer result

    An anonymised mapping shape used in scoping.

    Illustrative order mapping
    DSCO order ID Shopify order note attribute / reference
    Retailer PO number Order tag + reference field
    Retailer SKU Shopify variant (via mapping table)
    Consumer address Shopify shipping address
    Retailer cost Held separately from DTC price
    Fulfilment tracking Confirmation sent to DSCO

    Scope and questions

    Should retailer orders be created in Shopify?
    Both models work and we help you choose. Creating them keeps one fulfilment path; keeping them out protects DTC analytics. The trade-off is decided in scoping and written into the scope.
    Will this stop overselling?
    It reduces it by making Shopify the quantity of record and applying buffers at publish time. No integration eliminates oversell entirely — cadence and buffer choices manage the risk.
    Do you support multiple retailer programmes?
    Yes, each with its own mapping, feed rules and exception handling.
    What about returns?
    Retailer return flows vary by programme. They are scoped as their own workflow rather than assumed to be included.
    Do you replace DSCO?
    No. DSCO stays the retailer-facing network; APIWORX moves the data and owns the agreed workflows.
    Can our 3PL be in the loop?
    Yes. Where the 3PL produces the shipment detail, confirmations are built from their feed instead of Shopify fulfilments.

    Your integration plan

    Get My Integration Plan

    Tell us what systems you need connected. We’ll recommend the architecture, implementation approach, timeline and estimated price range.

    We’ll use these details to prepare your integration plan and follow up about it.

    Related integrations

    Ready to map your integration?

    Tell us what systems you need connected. We’ll recommend the architecture, implementation approach, timeline and estimated price range.

    Next step

    Scope your DSCO + Shopify integration

    Tell us your systems and documents. A specialist confirms scope by email.

    Scope this integration