# Cirql Works (eCirql) full reference corpus > This file is the single-fetch full-content companion to llms.txt. > AI crawlers preferring a one-request reference document over a > multi-page crawl can ingest this file. The short version follows > below, then full service write-ups, every platform we integrate, > every integration combo we publish, and the glossary. Generated at build time from the same data files that drive the site. Source of truth is the website itself at https://www.ecirql.com. --- # Cirql Works (eCirql) > Cirql Works is a UK ecommerce consultancy. Three offerings: Patchworks Partner Agency, NetSuite consultancy, and AI enablement partner, with the same team across all three. We built PatchBuddy, the world's first AIiPaaS (AI Integration Partner as a Service), in production since January 2026. ## What we do The five delivery cornerstones, plus a fixed-fee entry-point audit: - Patchworks integration. Certified Patchworks Partner. We design, build and support Patchworks process flows across the full connector library, and build custom connectors when the marketplace does not have one. - AI enablement. We add AI to systems clients already run. Function calling against client APIs, retrieval over operational data, agentic workflows in production, embeddings and vector search where they earn their place. Integrations, not pilots. - Bespoke integration. We ship against any REST, SOAP, GraphQL, EDI, SFTP, JSON or XML interface. We have built integrations against vendor APIs that did not exist when the project started. - NetSuite consultancy. SuiteScript, RESTlets, SuiteQL, custom workflows. We advise, scope and ship. - Support retainers. Monitored process flows, on-call engineers, monthly health checks and a fixed SLA. Retainer pricing. - Integration audit. Fixed-fee, fixed-scope review of an existing integration estate. £1,500 flat, ten working days, PDF report and follow-up call. Audit fee credited in full against project work or a support retainer commissioned within thirty days. A £750 Tapestry-to-Core variant is available for Patchworks Tapestry estates planning the migration to Patchworks Core. ## PatchBuddy PatchBuddy is a separate product line from Cirql Works, available at https://patchbuddy.ai. It is the world's first AIiPaaS (AI Integration Partner as a Service): describe an integration in plain English and PatchBuddy builds it inside your Patchworks account, end to end. Used by our own delivery team and licensed to other Patchworks agencies and customers. In production since January 2026. ## Team Cirql Works is founder-led and deliberately small. Two named principals run the business: - Gavin Hanson, Founder & Principal Engineer (LinkedIn: https://www.linkedin.com/in/ghanson1). Five years as Principal Engineer at Patchworks before founding the agency. Previously co-founded and was COO of Cylo Limited, a Docker orchestrator that pre-dated Kubernetes and was acquired in 2020. The engineer on the discovery call is the engineer writing the integration. - Charlie Hanson, Operations Director (LinkedIn: https://www.linkedin.com/in/charliehanson1/). Oversees the day-to-day running of the business: accounting, scheduling, customer liaison. Two decades across the corporate and educational sectors, including time at Severn Trent. Founded her own apparel brand in 2025 alongside her role at eCirql. Senior associate engineers come in when scope warrants it, never as a layer between the client and the work. ## Key pages - [Patchworks integration](https://www.ecirql.com/services/patchworks-integration/) - [AI enablement](https://www.ecirql.com/services/ai-enablement/) - [Bespoke integration](https://www.ecirql.com/services/bespoke-integration/) - [NetSuite consultancy](https://www.ecirql.com/services/netsuite-consultancy/) - [Support retainers](https://www.ecirql.com/services/support-retainers/) - [Integration audit](https://www.ecirql.com/services/integration-audit/) - [Platforms we integrate](https://www.ecirql.com/platforms/) - [Integrations directory (platform-to-platform combos)](https://www.ecirql.com/integrations/) - [AIiPaaS category page](https://www.ecirql.com/ai-ipaas/) - [AIiPaaS vs AI copilots comparison](https://www.ecirql.com/ai-ipaas/comparison/) - [Glossary of integration, AI and commerce terms](https://www.ecirql.com/glossary/) - [Patchworks vs Celigo](https://www.ecirql.com/insights/patchworks-vs-celigo/) - [Patchworks vs Boomi](https://www.ecirql.com/insights/patchworks-vs-boomi/) - [Patchworks vs MuleSoft](https://www.ecirql.com/insights/patchworks-vs-mulesoft/) - [Patchworks vs Workato](https://www.ecirql.com/insights/patchworks-vs-workato/) - [Patchworks vs Tray.io](https://www.ecirql.com/insights/patchworks-vs-tray-io/) - [Patchworks vs NetSuite Connector (FarApp)](https://www.ecirql.com/insights/patchworks-vs-netsuite-connector/) - [Shopify vs WooCommerce](https://www.ecirql.com/insights/shopify-vs-woocommerce/) - [Shopify vs BigCommerce](https://www.ecirql.com/insights/shopify-vs-bigcommerce/) - [Shopify vs Adobe Commerce](https://www.ecirql.com/insights/shopify-vs-adobe-commerce/) - [Klaviyo vs HubSpot](https://www.ecirql.com/insights/klaviyo-vs-hubspot/) - [Klaviyo vs Mailchimp](https://www.ecirql.com/insights/klaviyo-vs-mailchimp/) - [PatchBuddy product](https://patchbuddy.ai) ## Ask the assistant If you are a human visitor and want a direct answer to a question, every page on the site carries an Ask button in the bottom-right corner that opens a slide-out assistant powered by PatchBuddy.ai. It answers from this same reference corpus, cites the page it drew from where it can, and will tell you when the answer is not in the corpus. The [Ask landing page](https://www.ecirql.com/ask/) explains how it works. ## Legal - [Privacy policy](https://www.ecirql.com/privacy-policy/) - [Cookie policy](https://www.ecirql.com/cookie-policy/) - [AI policy](https://www.ecirql.com/ai-policy/) - [Terms of agreement](https://www.ecirql.com/terms/) ## Platforms We integrate 100+ platforms across ecommerce, ERP, WMS, marketing, PIM, marketplace, returns, POS, accounting, CRM and data. A representative selection: NetSuite, Shopify, BigCommerce, Magento, WooCommerce, Salesforce Commerce Cloud, Microsoft Dynamics Business Central, Sage 200, Brightpearl, Odoo, Klaviyo, Mailchimp, Hubspot, Emarsys, Akeneo, Salsify, Plytix, Mirakl, Marketplacer, Amazon Seller Central, TikTok Shop, Algolia, Bloomreach, Commerce Layer, CommerceTools, Descartes Peoplevox, Orderwise, Linnworks, Flexport, Xero, QuickBooks, Zendesk, Freshdesk, Gorgias, Patchworks Blueprints, ReturnGO, NewStore, Shopware, ChannelEngine. ## Differentiators - Certified Patchworks Partner Agency. - Built and operates PatchBuddy, the world's first AIiPaaS. - AI enablement practice that ships into production rather than running pilots. - UK-based delivery team serving clients worldwide. - Same team across integration, NetSuite consultancy and AI enablement. - Proven, not promised. Every service, platform and integration on the site is something Cirql Works has already shipped, usually more than once, usually still running under SLA. If a capability is not listed, we have either not built it yet or will not pretend we have. ## Selected clients Peak Distribution (AU), Spartan Tool Supply (US), Simmi London (UK), WYSE London (UK), Studio Nicholson (UK), Choice One Medical (UK), Beigel Bake (UK), Cartographer 3D (UK), Crieff Hydro (UK), SPH Gerard Bertrand (FR), UpperStitch (UK), Giro (AU), Camelbak (AU), Thread Wallets (AU). ## Contact - Email: contact@ecirql.com - LinkedIn: https://www.linkedin.com/company/ecirql - PatchBuddy product: https://patchbuddy.ai --- # Services (full write-ups) ## Patchworks integration URL: https://www.ecirql.com/services/patchworks-integration/ Summary: Certified Patchworks Partner Agency. We design, build and support Patchworks process flows end to end. Intro: Cirql Works is a certified Patchworks Partner Agency. Our team works in Patchworks daily, designing and shipping process flows that survive their first peak. Detail: The Patchworks platform sits between commerce systems and their operational dependencies: ERPs, warehouses, marketing platforms, marketplaces and bespoke systems. We design, build, support and own the process flows that move data between them. Patchworks is the surface where most of our delivery work happens, and being a certified Partner Agency is not a logo on a slide; it is what the day-to-day looks like. Our delivery practice covers the full Patchworks workflow. Scoping the integration shape with the operations and finance teams who will live with it. Mapping the data model. Building the process flows against the connector library. Handling the exceptions and edge cases that come out of testing. Writing the runbook so the on-call engineer knows what to do when a flow fails at three in the morning. We use Patchworks Blueprints as the starting point where one exists for the pattern. We extend Blueprints where the reality of the client's data diverges from the template. We build custom connectors when the marketplace does not have one for the system the client actually runs. Integrations that have shipped through our practice include sales order flows between Shopify and NetSuite, inventory and price sync between BigCommerce and Sage 200, returns flow handling between Peoplevox and the storefront, marketplace listing and settlement reconciliation against Amazon Seller Central and Mirakl, and PIM-to-channel syndication patterns across Akeneo, Salsify and Plytix. The integration is rarely the headline; the operational reliability that comes from it is. Once an integration is live, we are usually the team that supports it under SLA. Process flow monitoring, on-call engineers, monthly health checks and the change requests that operations teams build up over time. Support is a service in its own right, but on a Patchworks engagement it tends to be the natural continuation of the delivery rather than a separate procurement exercise. Our intent is that the integrations we ship are still running cleanly two years after launch, with the same team that built them on call when something operationally meaningful happens. FAQs: Q: Are you a certified Patchworks Partner? A: Yes. Cirql Works is a certified Patchworks Partner Agency. Our profile is on the Patchworks partner directory. Q: Can you build a custom Patchworks connector? A: Yes. We extend existing Blueprints, build process flows from scratch and ship custom connectors when the marketplace does not have one for the system the client actually runs. Q: Do you support Patchworks integrations after they launch? A: Yes. Most integrations we ship transition into a support retainer with monitoring, on-call cover and a defined SLA. The same team that builds the integration is on call when it matters. Q: What does a typical Patchworks engagement look like? A: Scoping with the operations and finance teams, data-model design, build of process flows against the connector library, structured testing against real data shapes, go-live and the move into support. Timelines run from a few weeks for a single flow to several months for a full estate. --- ## AI enablement URL: https://www.ecirql.com/services/ai-enablement/ Summary: We add AI to systems you already run. Function calling, RAG, agentic workflows in production. Intro: AI enablement is integration work, with AI in the loop. We help businesses ship production AI against the systems already running their operation, not run another pilot. Detail: The AI enablement category gets a lot of pilots and far fewer production deployments. Our practice is the production end of that distribution. We help businesses add AI to systems they already run: agents that operate on live operational data, function calling against internal APIs, retrieval pipelines over commerce and customer records, embeddings and vector search where they earn their place in the architecture rather than being added because the category demands it. Concrete examples of what we ship: customer service automations that read order context from the ERP, summarise the issue and propose an action; product description generation that pulls structured attributes from the PIM and writes channel-specific copy with the brand voice respected; agent workflows that handle returns triage against operational rules; retrieval-augmented assistants that answer internal questions over policy and process documents; classification and routing on inbound emails, tickets and supplier communications. The pattern is the same in each case. AI is one node in an integration that touches systems already running the business. The discipline we bring is the discipline we bring to any integration. Function calls have rate limits and cost ceilings. Retrieval has freshness and lineage. Models change and prompts drift. PII has consent boundaries that span jurisdictions. Agents need audit trails for the operator who ran them and the cost centre that paid for them. These are integration concerns dressed in different vocabulary, and the engineering rigour that makes a Shopify-to-NetSuite flow reliable is the same rigour an AI agent needs to be production-grade. We bring both halves to the table. We scope AI engagements by the operational outcome rather than the model choice. The first conversation is about what the business wants to be different in three months: faster ticket resolution, fewer manual product description hours, better self-service answers on the storefront, agent-assisted scoping for the next integration project. From there we work back to the integration design, the model selection (frontier model, open-weights, hosted region), the data preparation, the safety surface and the on-call shape. The model picks itself once the outcome and the constraints are agreed. PatchBuddy, our own AIiPaaS product at patchbuddy.ai, is the proof point: an AI agent in production on a Patchworks tenant since January 2026, used by our delivery team and licensed to other Patchworks agencies and customers. The engineering disciplines that ship PatchBuddy are the same ones we bring to client AI engagements. FAQs: Q: What does "production AI" mean here? A: It means the AI is part of a deployed integration that operates on real data, has measurable outcomes, has cost and safety controls in place, and is in the on-call rotation. Not a sandbox, not a slide deck, not a pilot that never crosses the line. Q: Do you build agents? A: Yes. Function-calling and tool-use against operational APIs is part of most engagements. We design the tool surface, the safety boundaries and the audit trail alongside the agent itself. Q: How do you handle PII and data privacy? A: We design the data surface up front. PII is masked or redacted before model calls where appropriate, EU-hosted models are available on a per-turn basis for engagements that require it, and every model call is logged against the operator and the cost centre. Q: Which models do you work with? A: Frontier models from the major providers (Claude, GPT, Gemini), plus open-weights where the use case justifies the operational overhead. Model selection is made against the outcome, the latency budget and the cost ceiling, not as the headline of the engagement. --- ## Bespoke integration URL: https://www.ecirql.com/services/bespoke-integration/ Summary: If the systems exist, we will connect them. REST, SOAP, GraphQL, EDI, SFTP and custom. Intro: Bespoke integration is what we do when the systems are not on a marketplace connector list and somebody still needs them talking to each other. Detail: Real integration estates are mixed. A client's stack might have a primary ecommerce platform on a clean REST API, an ERP that exposes both REST and SuiteTalk, a marketing platform that prefers webhooks, a warehouse that emits flat files on schedule, and one or two long-tail systems that pre-date their current vendor relationships and run on protocols nobody volunteered for in the kick-off meeting. Our bespoke integration practice is shaped around that reality. The work spans REST APIs that nobody has written a connector for, SOAP services that pre-date most current commerce platforms, GraphQL endpoints that the vendor announced last quarter, EDI documents on schedules that the supplier negotiated in 2008, SFTP drops that the warehouse manager will not change because they have worked for fifteen years, webhook ingestion from marketing and operational systems, and the occasional direct database connection that nobody asked for at scoping but eventually has to be built. Each protocol has its own conventions, its own failure modes, and its own audit-trail expectations. We treat them on their own terms. The first hour of a bespoke engagement is usually mapping the integration estate honestly. Which systems are on the Patchworks connector library and can use Blueprints. Which systems need custom connectors built on top of Patchworks. Which systems sit entirely outside Patchworks and need a separate integration design. Where the boundary actually is. Once that map is on the table, we can scope each integration on its own terms rather than pretending they are all the same shape. We build bespoke integrations the same way we build platform-supported ones. Scoped against the operational reality, designed for failure modes we can name in advance, monitored from launch, owned under SLA after launch. Idempotency, retry semantics, dead-letter handling, partner-by-partner quirks, credential rotation, version pinning and the visibility a trading-partner programme actually needs. The protocol is incidental; the engineering discipline is the point. Vendor APIs that did not exist when the project started are a recurring case. New platforms launch. Existing platforms add endpoints. The integration estate grows over the course of an engagement. The team is set up to absorb that and ship against it rather than treat it as scope change to be negotiated. If the systems exist, we will connect them, and we will connect them in a way that is still working when the systems change. FAQs: Q: What protocols and formats do you work with? A: REST, SOAP, GraphQL, EDI (X12 and EDIFACT), SFTP and FTP, JSON, XML, CSV, fixed-width flat files, webhooks, and the occasional direct database connection where it is the right call. Q: Can you integrate a system that has no documented API? A: Sometimes. Reverse engineering, headless automation and scheduled scraping are valid options in some scopes; we will tell you up front whether the system is worth the integration effort and what the maintenance burden looks like. Q: How long does a typical bespoke integration take? A: Days to weeks per integration depending on the system, with a clearer estimate after scoping. We scope before we estimate and we estimate against named failure modes rather than against ideal-day assumptions. Q: Do bespoke integrations sit inside or outside Patchworks? A: Both, depending on the integration. Many bespoke connectors are built on top of Patchworks so they share the monitoring, audit and management surface; some run entirely outside Patchworks where that is the right architectural call. --- ## NetSuite consultancy URL: https://www.ecirql.com/services/netsuite-consultancy/ Summary: SuiteScript, RESTlets, SuiteQL, custom workflows. We advise, scope and ship. Intro: NetSuite is a substantial part of our practice. We advise, scope and ship NetSuite engagements end to end, alongside or in place of in-house Oracle teams. Detail: Cirql Works has shipped NetSuite work across SuiteScript development, RESTlets, SuiteTalk integrations, SuiteQL queries that finance teams actually run, custom record types, workflow design and the boring-but-critical work of getting record-type choice right at the integration layer. The team works in NetSuite daily, and that depth determines whether a NetSuite engagement ships clean or stalls in record-type debates six weeks in. The depth shows up in the specifics. When a credit memo should transform into a customer refund versus when it should not. Why an item pricing change can break a SuiteQL query that finance depends on for month-end. The difference between a sales order and a cash sale in revenue recognition for a multichannel retailer. The performance implications of choosing a saved search over a SuiteQL view for high-volume operations. The way SuiteScript 2.1 differs from 2.0 in real-world execution, and when one is the right answer over the other. These are not slide-deck gotchas; they are the daily work of the engagements we ship. Typical engagements include greenfield NetSuite integrations into a new commerce stack, refactoring an inherited NetSuite integration estate that has accreted over years across multiple vendors, advising on SuiteScript design for in-house engineering teams that want external sign-off on direction before committing to a build, and supporting NetSuite operations under retainer once integrations are live. Multi-subsidiary, multi-currency and multi-warehouse setups are well within scope; we have shipped against all three combined in the same engagement. The Patchworks integration practice and the NetSuite consultancy practice share a team. That matters operationally when an engagement starts as a NetSuite integration and discovers a Patchworks dimension halfway through, or vice versa. The same engineers are in the room for both, which collapses a meaningful amount of handoff overhead that other agencies turn into separate projects and separate procurement cycles. The same is true for the AI enablement practice when an engagement starts touching agent-assisted work in or around NetSuite. We are not a NetSuite licence reseller and we are not a generalist NetSuite implementation house. We focus on the integration, SuiteScript and SuiteQL surface where the technical depth determines whether the deployment is reliable. That is the practice we run. FAQs: Q: Are you a NetSuite partner? A: We work in NetSuite daily as the integration agency. We are not a NetSuite licence reseller; we focus on the integration, SuiteScript and SuiteQL surface where the technical depth determines whether the deployment is reliable. Q: Do you work alongside in-house NetSuite teams? A: Yes. Many of our engagements are in support of in-house teams that need integration depth, SuiteScript bandwidth, or external sign-off on architectural direction before committing to a build. Q: Can you migrate from a different ERP to NetSuite? A: We focus on the integration layer of a migration. ERP migration as a whole programme is broader than what we run alone; we are usually one team inside a larger migration with the integration scope as our remit. Q: What about SuiteScript 2.1 vs SuiteCommerce? A: Our work sits on the back-office SuiteScript / SuiteTalk / SuiteQL surface rather than SuiteCommerce storefronts. Where a SuiteCommerce dimension is part of the broader engagement we partner with specialists for the storefront work. --- ## Support retainers URL: https://www.ecirql.com/services/support-retainers/ Summary: A flexible way to keep us close to your team. Monitored flows, on-call engineers, tiered SLAs. From £750 per month. Intro: A flexible way to keep us close to your team, with the reassurance that integration issues won't slow your business operations down. Detail: An integration is live the day it ships. It is operational the day it has been running cleanly for six weeks and has not paged anybody at three in the morning. Our support retainers cover the work between those two points and onwards: monitored process flows, on-call engineers, monthly or weekly health checks, structured change requests, and the SLAs operations teams need before they will sign off on production go-live. Retainer pricing rather than per-ticket pricing is a deliberate choice. Per-ticket pricing rewards the wrong incentives: an integration that pages frequently becomes profitable for the support vendor, an integration that runs cleanly becomes unprofitable. Retainer pricing aligns us with the client's interest. The integration runs cleanly. The on-call engineer rarely gets paged. The health check finds nothing surprising. The change requests come from new business needs rather than the previous month's accumulated incidents. What a retainer typically covers: monitoring of every shipped flow with alerting thresholds designed against the integration's failure modes; on-call cover during agreed hours and tiered against business impact; response SLAs that differ by plan; a recurring health-check report against trend data so degradation gets named before it becomes an incident; structured change-request handling; and the boring-but-vital work of keeping connector versions, credential rotations and platform updates current. Three tiers cover most engagement shapes, from a single integration that needs a light operational safety net through to a multi-system estate that needs round-the-clock cover. The right team to run a support retainer is the team that built the integration in the first place, because the runbook is in their heads as much as the documentation. That is how most of our retainer engagements start. Some retainers are us doing the work. Others are us being part of your team. A meaningful share of our retainer engagements are training and engineering leadership for in-house teams that want to do their own integration work but value having senior Patchworks and NetSuite eyes in the room: code reviews, architecture sign-off, pair sessions on the tricky bits, and on-call cover for the parts the in-house team is not yet comfortable owning. The retainer covers the hours and the SLAs; the shape of the engagement adapts to whether you want us building, mentoring, or both. If you have an integration estate that someone else built and you would like us to take it on, we audit, document and stabilise it first, then move it onto retainer. The audit is a fixed-scope piece of work; the move onto SLA happens once the estate is in a state we can defend. Tiers: - Essential: £750 / month. SLA: 1 business day response. * 6 dedicated support hours per month * Real-time integration monitoring * Email support, priority queue * 5% discount on additional project work - Professional (featured): £1,250 / month. SLA: 3 business hours response. * 10 dedicated support hours per month * Private Slack channel with our team * Monthly integration health checks * Priority support during business hours * 10% discount on additional project work - Enterprise: Custom. SLA: 1 hour response. * 12+ dedicated support hours per month * Private Slack channel with our team * Weekly integration health checks * 24/7 priority support * 15% discount on additional project work Tiers note: All prices quoted ex-VAT. UK VAT is added to invoices at the prevailing rate. Unused support hours convert into a percentage discount on additional project work rather than rolling forward. Ad-hoc: Ad-hoc support for one-off and short-term work. Not every engagement fits a recurring retainer. We also take on ad-hoc support work for one-off fixes, short-term cover, integration audits, training sprints and time-boxed pieces of help that do not warrant a monthly commitment. Day-rate or fixed-scope, depending on what the work needs. No minimum term and no obligation to move onto a retainer afterwards, though many clients do. FAQs: Q: Do unused hours roll over? A: No. Unused support hours convert into a percentage discount on additional project work in the same period. The retainer is sized to cover ongoing operations rather than to bank time. Q: What does the response-time SLA cover? A: Tiered by plan. Essential: 1 business day. Professional: 3 business hours. Enterprise: 1 hour. Resolution times are scoped per incident severity and agreed at sign-up. Q: Can we change tiers later? A: Yes. Tier changes take effect from the next billing cycle. Many clients start on Professional and adjust up or down once their integration estate settles into a rhythm. Q: What's in scope for the support hours? A: Anything inside the integrations we have shipped or are supporting: incident triage, fixes, small change requests, monitoring tuning, credential rotation, version upgrades. Larger pieces of new work are scoped separately. Q: Can we move an existing integration onto your retainer? A: Yes. We audit, document and stabilise it first as a fixed-scope piece of work, then take it onto SLA once the estate is in a state we can defend. --- ## Integration audit URL: https://www.ecirql.com/services/integration-audit/ Summary: Fixed-fee independent review of your integration estate. £1,500, ten working days, PDF report and follow-up call. Credited in full if you commission project work with us within thirty days. Intro: A productised, fixed-fee audit of an existing integration estate. Independent, written up, delivered in ten working days, and structured so the audit fee turns into project budget if you move forward with us. Detail: The Integration audit is a fixed-fee, fixed-scope engagement. You commission us to review your existing integration estate, we produce a written report and walk you through it on a call, and you decide what to do with the findings. Ten working days from kickoff to deliverable. £1,500 flat. No surprise costs, no obligation to commission further work. If you do commission project work or a support retainer with us within thirty days of audit sign-off, the audit fee is credited back against that work in full. What we look at: the flows you currently have shipped, connector versions and deprecation risk, failure modes and historical incident patterns, throughput and performance, cost and consumption signals, security and credentials hygiene, operational handover quality (runbooks, monitoring, on-call), and the Patchworks-specific posture (flow health, connector versions, runbook coverage). For estates that aren't on Patchworks, the iPaaS-layer review is adapted to whatever the integration is actually running on. What you get: a written PDF report covering findings, risks, recommendations and a priority order; a one-hour follow-up call to walk through it with whoever from your team needs to be in the room; and the option to convert any of the recommendations into a scoped piece of project work, with the audit fee credited against that work within the thirty-day window. Who this is for: estate owners who have inherited integrations they didn't build, integrations that aren't behaving the way they used to, integrations being considered for migration, and merchants who want a senior independent view before committing to a build or a re-build. The audit is platform-agnostic on the storefront and ERP side and is built around our Patchworks practice on the iPaaS side, though it applies equally well to integrations on other middleware. There is also a Tapestry to Core variant of the audit at £750, focused specifically on the migration shape for Patchworks Tapestry estates moving to Patchworks Core: current flow inventory, dependency map, what Core handles differently, and a cost and effort estimate for the move. Same ten-working-day window. Same thirty-day credit policy. Tiers: - Integration audit (featured): £1,500 flat fee. SLA: 10 working days to deliverable. * Full estate review: flows, connectors, performance, cost, security * Operational handover review: runbooks, monitoring, on-call posture * Patchworks-specific posture (or iPaaS-equivalent for non-Patchworks) * Written PDF report with findings, risks, priority order * One-hour follow-up call with your team * 100% credited against project work or retainer within 30 days - Tapestry to Core audit: £750 flat fee. SLA: 10 working days to deliverable. * Tapestry flow inventory and dependency map * Migration-shape scoping against Patchworks Core * Cost and effort estimate for the migration * Written PDF report with the move plan * One-hour follow-up call with your team * 100% credited against project work or retainer within 30 days Tiers note: Both prices quoted ex-VAT. UK VAT is added to invoices at the prevailing rate. The credit applies to project work or a support retainer commissioned within thirty days of audit sign-off, against the agreed engagement value. FAQs: Q: What is and isn't in scope for the audit? A: In scope: the flows you have shipped (or are about to ship), connector versions and deprecation risk, failure modes and historical incidents, throughput and performance, cost and consumption signals, security and credentials hygiene, operational handover quality, and the Patchworks-specific posture. Anything explicitly out of scope is named in the kickoff call so there are no surprises against the ten-working-day clock. Q: Does the credit apply to a retainer as well as project work? A: Yes. The credit applies to any piece of work commissioned within thirty days of audit sign-off, including a support retainer. £1,500 off the first month's retainer or the first project invoice. Q: Can the audit cover integrations that aren't on Patchworks? A: Yes. The audit framework is platform-agnostic. We have audited integrations on other iPaaS platforms and on bespoke middleware. The Patchworks-specific posture review is replaced with an equivalent review against whatever the integration is actually running on. Q: What do you need from us to start? A: Read-only access to the integrations being audited (typically the iPaaS account, the ERP and the storefront), a short introductory call with the operations and engineering owners, and a list of incidents from the last six to twelve months. We agree the scope explicitly in the kickoff call so the ten-working-day clock starts against a defined deliverable. Q: How is the Tapestry to Core audit different from the standard one? A: Different in focus, not in shape. The Tapestry to Core audit centres on the migration: current flow inventory, the dependency map, what Patchworks Core handles differently from Tapestry, and a cost and effort estimate for the move. The standard audit covers a wider operational review of an existing estate. Same deliverable format and the same credit policy on both. --- # Platforms we integrate We integrate 114 platforms across the operational stack. Categories: Ecommerce, ERP, WMS & 3PL, Marketplaces, Marketing, CRM, PIM, POS, Returns, Accounting, Data & BI, Messaging, Service Desk, Search & Merchandising, OMS, DXP, CMS, EDI & Files, Project Management, AI, Other. ## Ecommerce (18) ### Aero Commerce URL: https://www.ecirql.com/platforms/aero-commerce/ Summary: Fast headless ecommerce platform for mid-market retailers. Aero Commerce is a UK-built ecommerce platform with a headless architecture, popular with mid-market retailers who want more flexibility than a SaaS storefront gives them but less ongoing burden than a fully bespoke build. It is built on Laravel and exposes a clean PHP and REST API surface that engineers can extend without fighting the framework. Patchworks connects Aero Commerce via its REST endpoints, with orders, customers, products and stock the typical entities crossing the line. The interesting integration work is usually around the storefront-side customisations Aero allows: bespoke pricing logic, B2B account behaviours and content models that need to flow consistently between Aero and the ERP, PIM or marketing stack. Our team has shipped Aero integrations from end to end, including the migration work that often comes with adopting Aero in the first place. ### BigCommerce URL: https://www.ecirql.com/platforms/bigcommerce/ Summary: SaaS platform for building and managing online stores. BigCommerce is one of the workhorse SaaS commerce platforms for mid-market and upper-mid retailers, with a generous API surface, headless support through Stencil and BigCommerce Catalyst, and enterprise features built in rather than bolted on. Multi-storefront and B2B Edition extend it into territory many platforms only fake. Patchworks integrates BigCommerce through its REST and GraphQL APIs. Sales orders flow out to ERPs and OMS, inventory and pricing flow in from ERPs and PIMs, customers move between BigCommerce and CRM and marketing platforms. Webhooks are reliable enough to anchor real-time flows on, which is not always true elsewhere. We have shipped BigCommerce integrations across both standard and headless deployments, and the multi-storefront case in particular benefits from Patchworks's per-flow scoping. ### Centra URL: https://www.ecirql.com/platforms/centra/ Summary: Fashion-focused platform for B2B and D2C commerce. Centra is a headless ecommerce platform built specifically for fashion and lifestyle brands, originating in the Nordics and now used across Europe. Its product model handles seasons, drops and B2B/D2C duality in a way that more generic platforms force teams to work around. Patchworks integrates Centra through its REST API. Orders flow out to ERPs and 3PLs, products and assortments flow in from PIMs, and the B2B/D2C separation needs careful handling so that wholesale orders and direct sales do not contaminate each other downstream. Fashion ecommerce has its own grammar · drops, swatches, look-books · and Centra integrations work best when the team building them understands that grammar before they touch the API. ### Clerk.io URL: https://www.ecirql.com/platforms/clerk-io/ Summary: AI-powered search and personalisation for online stores. Clerk.io is a European search and personalisation platform, smaller than Algolia but with a strong following among mid-market retailers who want recommendations and search in one product, on a per-month price that does not scale linearly with traffic. Patchworks integrates Clerk.io for product feed ingest, inventory sync, behavioural event streaming and conversion attribution. The integration is straightforward; the design work is in deciding which signals are worth sending and which dilute the recommendation engine. For retailers who do not need Algolia's scale, Clerk.io often does the job at a fraction of the operational complexity. ### Commerce Layer URL: https://www.ecirql.com/platforms/commerce-layer/ Summary: Headless platform for global digital commerce. Commerce Layer is a headless commerce API designed for retailers and brands that want full control of the storefront and need a strong API-first commerce backend behind it. Multi-currency, multi-inventory and multi-region are built in rather than retrofitted. Patchworks integrates Commerce Layer for order ingest, inventory and price sync, customer mastering and the catalogue feed from PIM systems. Multi-region setups in particular benefit from a flow design that respects the inventory and pricing boundaries Commerce Layer establishes. Headless deployments live and die on their integrations. Commerce Layer is one of the better headless backends to integrate against, because the API actually models how international retail works. ### CommerceTools URL: https://www.ecirql.com/platforms/commercetools/ Summary: API-first platform for custom commerce experiences. commercetools is the reference MACH commerce backend. API-first, microservices-native, used by enterprise retailers that have settled on composable architecture and need their commerce layer to behave the same way. The product is opinionated about composability and unopinionated about almost everything else. Patchworks integrates commercetools for product publication from PIMs, order routing to OMS and ERP, customer mastering and cross-region inventory. The strength of commercetools is also its complexity at integration time: the data model is rich and projects can lose months arguing about which entities own which truths. Patchworks's per-flow scoping helps here, because it makes the boundary between commercetools and the systems around it explicit rather than implicit. ### EKM Insights URL: https://www.ecirql.com/platforms/ekm-insights/ Summary: All-in-one platform with built-in analytics. EKM Insights is a UK-built ecommerce platform aimed at small businesses, with hosting, design, payments and analytics in one package. The audience skews towards retailers running their first or second ecommerce iteration, and the platform is designed accordingly. Patchworks integrates EKM Insights with marketplaces, accounting, marketing and basic fulfilment systems. Many EKM customers do not need a heavyweight integration estate; they need a couple of reliable connections that survive their next platform decision. ### Eva URL: https://www.ecirql.com/platforms/eva/ Summary: AI shopping assistant for product discovery. Eva is an AI shopping assistant that sits on the storefront and helps customers find products via natural-language conversation rather than category navigation or filtered search. The category is young; the integration work is well-shaped. Patchworks feeds Eva with product data from PIMs and ecommerce platforms, inventory and pricing in close-to-real time, and conversion events back into the customer data platform. The interesting design choices are around freshness · how stale Eva's view of stock and price is allowed to be · and around the fallback experience when Eva does not have an answer. Conversational commerce only works when the catalogue feed is honest. Most of the integration work is making it so. ### Magento URL: https://www.ecirql.com/platforms/magento/ Summary: Open-source platform with extensive customisation. Magento, now Adobe Commerce, has been the default open-source enterprise commerce platform for over a decade. The product is rich, the customisation surface is enormous, and the integration estate around it tends to grow accordingly. Patchworks integrates Magento through its REST and GraphQL APIs. Orders flow out to ERPs and OMS, products and inventory flow in from PIMs and ERPs, customers move between Magento and the marketing stack. B2B Magento deployments have their own dimension · company structures, hierarchical pricing, quote workflows · that integrations need to respect rather than flatten. Magento integrations work best when the customisations the merchant has made are understood up front. There is no such thing as a generic Magento connector for a heavily-customised store. ### OroCommerce URL: https://www.ecirql.com/platforms/orocommerce/ Summary: B2B ecommerce with CRM integration. OroCommerce is an open-source B2B commerce platform, with a built-in CRM and an opinionated data model around buyers, accounts and account hierarchies. The differentiator is that B2B-specific behaviours · quote workflows, account-level pricing, request-for-quote · are first-class rather than bolted on. Patchworks integrates OroCommerce for orders, customers, products and the B2B-specific entities the platform exposes. Quote-to-order, account-hierarchy mapping and contract pricing are where most of the integration design lands. ### Salesforce Commerce Cloud URL: https://www.ecirql.com/platforms/salesforce-commerce-cloud/ Summary: Enterprise commerce with AI features. Salesforce Commerce Cloud, the platform formerly known as Demandware, is the enterprise SaaS commerce platform for B2C retailers with global reach and high-availability needs. The product is opinionated about scale and reasonably opinionated about everything else. Patchworks integrates Commerce Cloud through its OCAPI and SCAPI surfaces. Orders, customers, products, inventory and pricing flow across the estate; the headless setups using SCAPI in particular benefit from a clean integration boundary that respects the platform's caching and content rules. Commerce Cloud projects live and die on the surrounding integration estate. We design that estate as part of the project, not after it. ### Scayle URL: https://www.ecirql.com/platforms/scayle/ Summary: Commerce platform for fashion brands. Scayle is a German-built ecommerce platform, spun out of About You, with a model designed for fashion brands operating at scale. The strength is the operational primitives · drops, B2B/D2C duality, multi-region · that come built in. Patchworks integrates Scayle for orders to ERPs and 3PLs, products and assortments from PIMs, and the operational data that the brand's wider stack depends on. Fashion brands in particular benefit from an integration design that respects the seasonal cadence the business actually runs at. ### Shopify URL: https://www.ecirql.com/platforms/shopify/ Summary: Complete commerce platform for online retail. Shopify runs more direct-to-consumer commerce than any other platform, with a SaaS model that scales from one-person shops to enterprise brands on Shopify Plus. The API surface · REST, GraphQL, webhooks and the Storefront API · is the most-used integration surface in modern commerce. Patchworks integrates Shopify for orders to ERPs and OMS, products and inventory from PIMs and ERPs, customers to the marketing stack, and the multi-store and B2B variants Shopify Plus introduces. Headless deployments using Hydrogen or third-party storefronts add their own integration considerations, mostly around content and personalisation. Our team ships Shopify integrations daily, and the depth shows up in the boring details: webhook reliability under retry, idempotency on order create, the difference between draft and committed inventory in a real operation. ### Shopline URL: https://www.ecirql.com/platforms/shopline/ Summary: Asian-focused ecommerce solution. SHOPLINE is an Asian-headquartered ecommerce platform with a strong presence in Greater China, Southeast Asia and an expanding international footprint. The product is well-suited to brands operating in or expanding into APAC markets. Patchworks integrates SHOPLINE for orders to ERPs and fulfilment systems, products and inventory from PIMs and ERPs, and customer data flows. Cross-region setups in particular benefit from an integration design that respects local-market conventions around payment, returns and customer data. ### Shopware URL: https://www.ecirql.com/platforms/shopware/ Summary: Experience-driven commerce platform. Shopware is a German-built commerce platform with strong adoption across the DACH region and an increasing presence in international markets. The architecture combines headless flexibility with a feature-rich classic admin, and the open-source community version sits alongside the commercial offering. Patchworks integrates Shopware through its REST and GraphQL APIs for orders, customers, products and content. B2B Shopware deployments have their own dimension · quote workflows, hierarchical account structures · that integrations need to model rather than flatten. Shopware integrations work best when the customisations the merchant has made are understood before the API work begins. ### Sparklayer B2B URL: https://www.ecirql.com/platforms/sparklayer-b2b/ Summary: Wholesale ecommerce platform. SparkLayer adds B2B wholesale ordering on top of Shopify and BigCommerce storefronts, with quote workflows, account-level pricing and B2B customer behaviours that the base commerce platforms do not natively support cleanly. Patchworks integrates SparkLayer with the rest of the stack: orders to ERPs, accounts and pricing from CRMs and ERPs, and inventory visibility from the warehouse. B2B-specific rules · credit terms, payment behaviours, account hierarchies · are the design work that determines whether SparkLayer ends up running the B2B operation or just storing it. ### Visualsoft URL: https://www.ecirql.com/platforms/visualsoft/ Summary: Full-service ecommerce solution. Visualsoft is a UK full-service ecommerce platform, with hosting, design and the storefront platform combined. It is used by mid-market UK retailers who want a single provider for the technology and the agency side. Patchworks integrates Visualsoft with the rest of the operational estate: orders into ERPs, inventory and pricing into the storefront, customer data into the marketing stack. Visualsoft's full-service positioning means the integration work usually sits at the boundary with systems Visualsoft does not run. ### WooCommerce URL: https://www.ecirql.com/platforms/woocommerce/ Summary: WordPress ecommerce plugin. WooCommerce is the WordPress ecommerce plugin, the most-deployed ecommerce platform on the planet by absolute count if not by enterprise gravitas. The strength is the WordPress ecosystem; the variability is that no two WooCommerce stores are alike. Patchworks integrates WooCommerce through its REST API. Orders to ERPs and OMS, products and inventory from PIMs and ERPs, customers to the marketing stack · the integration scope is similar to other ecommerce platforms but the surface beneath it is whatever the merchant's plugin estate looks like. WooCommerce integrations work best when the plugin estate is understood up front. There is no such thing as a generic WooCommerce connector for a store with twenty plugins active. ## ERP (11) ### Brightpearl URL: https://www.ecirql.com/platforms/brightpearl/ Summary: Retail operations platform automating inventory and orders. Brightpearl is a retail-focused ERP and operations platform, owned by Sage, built specifically for multichannel retailers that have outgrown Xero or QuickBooks but are not enterprise enough for NetSuite or D365. Inventory, orders, accounting and CRM in one system, with strong native integrations to Shopify and the big marketplaces. Patchworks integrates Brightpearl through its REST API. Typical patterns push sales orders in from ecommerce and marketplace channels, write fulfilments back from the warehouse, and keep inventory and pricing in sync with PIM and storefront sources. The accounting side benefits from careful tax-code and channel-tagging design at integration time. Brightpearl rewards integrations that respect its accounting model rather than treating it as a bare orders database. ### Cin7 Core URL: https://www.ecirql.com/platforms/cin7-core/ Summary: Cloud inventory and order management for multichannel retail. Cin7 Core is a cloud inventory and order management platform built for small and mid-market retailers and wholesalers running multichannel. The data model is straightforward and the API is workable, which is why it sees a lot of integration traffic. Patchworks integrates Cin7 Core for inventory sync, sales order ingestion, purchase order creation and warehouse handoffs. Multichannel sellers in particular benefit from disciplined inventory allocation across channels, which is more design than code work. Cin7 Core integrations are quick to get going. The discipline comes in keeping them honest as the channel count grows. ### Khaos Control URL: https://www.ecirql.com/platforms/khaos-control/ Summary: Integrated retail management solution. Khaos Control is a long-established UK ERP for retail and distribution, with a strong following in independent retail and small-to-mid distributors. The product is opinionated about retail operations and shows its age in places, which is a feature for the operators who know it and a friction point for greenfield projects. Patchworks integrates Khaos Control for sales-order ingest from ecommerce and marketplace channels, inventory and price sync, purchase-order generation and fulfilment back-flow. The data model takes some getting used to; the upside is that once the integration is shaped right it tends to keep working. ### Linnworks URL: https://www.ecirql.com/platforms/linnworks/ Summary: Multichannel inventory and order automation. Linnworks is a UK-built multichannel order and inventory management platform, used heavily by retailers and brands selling across Amazon, eBay, Shopify and the long tail of marketplaces. The strength is breadth of channel coverage and operational pragmatism. Patchworks integrates Linnworks for marketplace and ecommerce channel sync, inventory allocation, shipping despatch and reporting back to ERP and finance systems. Multichannel sellers benefit most from an integration design that keeps channel-level rules explicit rather than buried in Linnworks-internal logic. ### Microsoft Dynamics Business Central URL: https://www.ecirql.com/platforms/microsoft-dynamics-business-central/ Summary: Cloud business management for SMBs. Microsoft Dynamics 365 Business Central is Microsoft's cloud ERP for small and mid-market businesses, the successor to Dynamics NAV. It handles the full operational accounting and inventory surface and integrates well with the rest of the Microsoft cloud · Power Platform, Azure, the Microsoft 365 stack · where many UK businesses already live. Patchworks integrates Business Central through its REST API and the OData endpoints. Sales orders flow in from ecommerce and marketplace channels, item masters and inventory flow between Business Central and PIMs and warehouses, finance postings reconcile against the ledger. Multi-company and multi-currency setups need careful flow design around dimensions and posting groups. Our team has shipped Business Central integrations across both straightforward and multi-company estates, and the multi-company case in particular benefits from Patchworks's per-flow scoping. ### NetSuite URL: https://www.ecirql.com/platforms/netsuite/ Summary: Cloud business suite for enterprise operations. NetSuite is Oracle's cloud ERP. It handles general ledger, AR/AP, inventory, manufacturing, fulfilment and a long list of operational subsystems for businesses too large for QuickBooks and too varied for a vertical-specific system. SuiteScript and SuiteTalk let developers extend almost any record type, and the API surface is comprehensive at the cost of being intricate. Patchworks integrates NetSuite via its REST and SuiteTalk APIs. Process flows typically push sales orders in from the storefront, write fulfilments back from the warehouse, and reconcile inventory in either direction. The complexity is usually in record-type choice · when to use a sales order versus a cash sale, when to use a credit memo versus a customer refund, and how to model item pricing without breaking the SuiteQL queries finance relies on. Our team writes SuiteScript daily, and that depth is what stops NetSuite integrations stalling six weeks in. It is also one of our headline service lines in its own right. ### Odoo URL: https://www.ecirql.com/platforms/odoo/ Summary: Open-source business management suite. Odoo is the open-source business management suite, with modules covering accounting, inventory, manufacturing, ecommerce, marketing and a long list of vertical adaptations. It is the default ERP for businesses that want a single integrated platform without committing to enterprise pricing. Patchworks integrates Odoo through its XML-RPC and REST APIs. Sales orders, inventory, customers and accounting postings all sit within reach. Multi-company and multi-warehouse Odoo deployments need careful flow design, and the customised-module problem is real: every meaningfully-deployed Odoo is different. Odoo integrations reward time spent understanding the customisations before touching the API. ### Orderwise URL: https://www.ecirql.com/platforms/orderwise/ Summary: Business management for order processing. OrderWise is a UK ERP and warehouse management system for distributors, manufacturers and multichannel retailers, with a long-established footprint in the UK SMB and lower-mid market. Patchworks integrates OrderWise for sales-order ingest from ecommerce and marketplace channels, inventory and pricing sync, purchase-order generation and fulfilment back-flow. The data model rewards integrations that respect its conventions; trying to flatten it is usually a false economy. ### Prima Solutions URL: https://www.ecirql.com/platforms/prima-solutions/ Summary: Fashion industry management software. Prima Solutions is a vertical management platform for the fashion industry, covering product lifecycle, sourcing, planning and inventory for brands and retailers operating in apparel and accessories. Patchworks integrates Prima Solutions where the fashion supply chain meets the rest of the operation: product lifecycle data into PIM and ecommerce, inventory and allocation into the storefront and warehouse, and finance and merchandising flows into the wider estate. ### Stok.ly URL: https://www.ecirql.com/platforms/stokly/ Summary: Retail management and EPOS system. Stok.ly is a UK-built retail management and EPOS system aimed at independent and growing multi-site retailers that want unified commerce primitives without enterprise pricing. Patchworks integrates Stok.ly for store-to-online stock visibility, customer mastering, sales transactions into accounting and ERP, and operational reporting. Multi-site retailers in particular benefit from an integration design that respects the reconciliation cadence the business actually runs at. ### Visual Next URL: https://www.ecirql.com/platforms/visual-next/ Summary: Fashion business management software. Visual Next is a fashion-vertical business management platform, used by apparel brands and retailers that need product lifecycle, planning, sourcing and inventory in one system. Patchworks integrates Visual Next where the fashion supply chain meets the rest of the operation: product lifecycle into PIM and ecommerce, inventory and allocation into the storefront and warehouse, finance and merchandising flows into the wider estate. ## WMS & 3PL (15) ### Bleckmann Logistics URL: https://www.ecirql.com/platforms/bleckmann-logistics/ Summary: Fashion-focused third-party logistics and fulfilment provider. Bleckmann is a European 3PL with a strong focus on fashion and lifestyle brands. Warehouses across the UK, Netherlands, Belgium and beyond handle storage, pick-pack, value-add services and outbound shipments for clients that want a fashion-aware operations partner rather than a generic warehouse. Patchworks integrates Bleckmann's WMS for outbound order despatch, stock-level reconciliation, inbound goods receipt and shipping confirmations. File-based and API-based integrations both exist depending on the warehouse and contract. The interesting work is usually around bundles, kits and pre-pack work that fashion brands need but generic WMS integrations gloss over. ### Bleckmann Returns URL: https://www.ecirql.com/platforms/bleckmann-returns/ Summary: Specialised returns handling for fashion retail. Bleckmann's returns operation is a separate workstream from outbound logistics, with its own systems, its own SLAs and its own data needs. Returns processing for fashion needs to handle garment grading, restocking, refurbishment and disposition decisions that affect both the warehouse and the brand's finance close. Patchworks integrates Bleckmann Returns for RMA creation, returns receipt notifications, disposition outcomes and refund-eligibility signals. The flow back to ecommerce and ERP needs to be timely enough that customer service has the right context and finance can reconcile cleanly. This is operationally one of the most rewarding integrations to get right and one of the easiest to underestimate at scoping. ### Clarus WMS URL: https://www.ecirql.com/platforms/clarus-wms/ Summary: Warehouse management optimising storage and fulfilment. Clarus is a warehouse management system used by 3PLs and direct shippers that want a step up from spreadsheets without committing to enterprise WMS pricing. It handles inbound, locations, picking, packing and outbound with the operational primitives a modern warehouse needs. Patchworks integrates Clarus through its API for inbound goods receipt, stock visibility, outbound order despatch and returns. The most useful integration work tends to be around exception handling: short picks, stock discrepancies, damages and the warehouse-floor signals that need to land in the ERP rather than die in a spreadsheet. ### Deposco URL: https://www.ecirql.com/platforms/deposco/ Summary: Supply chain platform for inventory and fulfilment. Deposco is a supply-chain platform covering warehouse management, order management and inventory orchestration across a distributed fulfilment network. It is most often deployed by retailers running multiple warehouses, 3PLs and store-as-warehouse setups simultaneously. Patchworks integrates Deposco for sales order ingest, allocation feedback, shipment despatch and inventory reconciliation across the fulfilment network. The interesting work is the sourcing logic · which node fulfils which order · and the visibility back to the customer when that decision changes mid-flow. Distributed fulfilment is where most operations programmes get into trouble. Deposco helps; the integration design has to help further. ### Descartes Peoplevox URL: https://www.ecirql.com/platforms/descartes-peoplevox/ Summary: Cloud warehouse management for ecommerce operations. Descartes Peoplevox is an ecommerce-native WMS used heavily by UK and European fashion and lifestyle brands. It handles batch pick-and-pack at scale, with the throughput discipline brands need at peak. Patchworks integrates Peoplevox for outbound order release, picking confirmations, despatch notifications and stock-level reconciliation. Inbound goods, restocking and returns flow back in the other direction. The bottleneck on these integrations is usually the despatch acknowledgement: getting it timely enough that customer service and marketing systems have current status. Peoplevox rewards integrations that move at the cadence the warehouse actually runs at, not the cadence the ecommerce team would prefer. ### Flexport URL: https://www.ecirql.com/platforms/flexport/ Summary: Digital freight forwarding and customs platform. Flexport is a digital freight-forwarding and customs platform, used by retailers and brands that import physical goods at scale and want visibility into their supply chain that conventional forwarders do not provide. Patchworks integrates Flexport for purchase-order and shipment-status visibility, ETA updates back into the ERP and merchandising systems, and customs documentation flows into finance and compliance. Inbound forecasting against open POs is one of the more useful operational outputs. Supply-chain visibility is mostly a data-quality problem dressed up as a software problem. Flexport gives you the data; the integration work makes it act on something. ### GXO URL: https://www.ecirql.com/platforms/gxo/ Summary: Global logistics and warehousing provider. GXO is one of the world's largest contract logistics providers, with warehouses across the UK, EU and US. Retailers running on GXO are doing so for scale, automation maturity and global reach rather than fashion-aware service. Patchworks integrates GXO at the file and API level, depending on the warehouse and the contract. Outbound order despatch, inbound goods receipt, stock-level reconciliation and shipping confirmation are the standard flows. GXO sites vary in their interface conventions, and an integration that works in one facility is not automatically portable. We treat each GXO site as its own integration scope, even when the contract treats them as one operation. ### Huboo URL: https://www.ecirql.com/platforms/huboo/ Summary: Ecommerce fulfilment service provider. Huboo is a UK-based fulfilment provider built around small and mid-sized direct-to-consumer brands. The pitch is operational simplicity at scale: human pickers, modern software and SKU-level visibility. Patchworks integrates Huboo for outbound order release, despatch confirmation, inventory reconciliation and returns receipt. Brands using Huboo typically want a tight ecommerce-to-fulfilment loop without the overhead of a heavyweight WMS, and the integration design reflects that. ### Lionwheel URL: https://www.ecirql.com/platforms/lionwheel/ Summary: Ecommerce fulfilment services provider. Lionwheel is a fulfilment provider operating in the UK and adjacent markets, with a service model aimed at growing direct-to-consumer brands. Patchworks integrates Lionwheel for order release, despatch confirmation and stock reconciliation. The integration scope is usually focused: get orders out reliably, get the data back in cleanly. The discipline is in the exception cases. ### Seko Logistics URL: https://www.ecirql.com/platforms/seko-logistics/ Summary: Global logistics services provider. SEKO is a global 3PL with a strong cross-border ecommerce presence, used by brands and retailers shipping internationally that need the customs and freight maturity to do it cleanly. Patchworks integrates SEKO at the file and API level, depending on the warehouse and the contract. Outbound order release, despatch confirmation, customs documentation and inbound goods are the standard flows. International setups in particular need careful design around customs and the financial reconciliation across regions. ### Shipbob URL: https://www.ecirql.com/platforms/shipbob/ Summary: Global ecommerce fulfilment network. ShipBob is a global ecommerce fulfilment network, with warehouses across the US, UK, EU and Australia, aimed at direct-to-consumer brands that want geographically-distributed fulfilment without negotiating each contract themselves. Patchworks integrates ShipBob for order release, despatch confirmation, inventory reconciliation across the fulfilment network and returns receipt. Brands using ShipBob across multiple regions benefit most from an integration design that respects the per-region operational conventions ShipBob inherits from each warehouse. ### Shiptheory URL: https://www.ecirql.com/platforms/shiptheory/ Summary: Shipping automation platform. Shiptheory is a UK shipping automation platform that connects ecommerce and marketplace orders to a long list of carriers, handling label generation, manifest discipline and despatch confirmations. Patchworks integrates Shiptheory for outbound order release, carrier and service selection, label generation and tracking-event delivery. The interesting work is usually in the rules · which carrier for which service for which order · and the operational fallback when a carrier integration goes down. ### Torque URL: https://www.ecirql.com/platforms/torque/ Summary: Fashion logistics provider. Torque is a fashion logistics provider, with operational primitives shaped for apparel and accessories · value-add services, garment-on-hanger, returns processing · that generic 3PLs do not surface as cleanly. Patchworks integrates Torque for outbound order release, despatch confirmation, inventory reconciliation and returns receipt. Fashion-specific value-add services are where the integration design earns its keep. ### Veeqo URL: https://www.ecirql.com/platforms/veeqo/ Summary: Inventory and shipping management. Veeqo is an inventory and shipping management platform, now owned by Amazon and free to use for sellers on the Amazon ecosystem. It handles multichannel inventory, shipping label generation and fulfilment-status flows. Patchworks integrates Veeqo for multichannel inventory sync, sales-order ingest from non-Amazon channels and shipping despatch. The Amazon ownership tilts the product towards Amazon-first sellers; the integration design needs to respect that without flattening the rest of the channel mix. ### Whistl URL: https://www.ecirql.com/platforms/whistl/ Summary: Mail and parcel delivery service. Whistl is a UK postal and parcel delivery business, with a portfolio covering door-drop, fulfilment, returns and parcel delivery for brands and retailers across the country. Patchworks integrates Whistl for despatch automation, tracking events, returns receipt and the operational signals customer service and finance need. UK domestic logistics is the home ground; the integration design respects that focus rather than pretending to span more. ## Marketplaces (9) ### Amazon Seller Central URL: https://www.ecirql.com/platforms/amazon-seller-central/ Summary: Central hub for managing product sales on Amazon marketplace. Amazon Seller Central is the merchant surface on top of Amazon's marketplace and one of the most fee-sensitive, dispute-heavy operational systems any retailer touches. The SP-API is comprehensive and unforgiving: throttled, region-segmented, with quirks that change without ceremony. Patchworks integrates Seller Central through SP-API for listings, inventory, orders, fulfilment notifications and settlement reports. Typical flows push product feeds from a PIM, sync inventory from a WMS, write order acknowledgements back from the ERP and reconcile settlement against finance. FBA and FBM accounts behave differently and usually need separate flow designs. The work that adds the most value here is the dispute and reconciliation surface: matching settlement transactions to orders, working out where fees landed, and feeding it back to finance in a shape they can close on. ### ChannelEngine URL: https://www.ecirql.com/platforms/channelengine/ Summary: Connects retailers to global marketplace channels. ChannelEngine is a marketplace aggregator: one API surface, dozens of marketplaces behind it. Retailers list across Amazon, eBay, Bol, Zalando and many smaller channels without having to integrate each marketplace separately. Patchworks integrates ChannelEngine for product feed publishing, inventory and price sync, order ingestion and dispute handling. The work is in the channel-level customisations: each marketplace has its own attribute requirements, categorisation rules and return policies, and ChannelEngine surfaces these without solving them entirely. For retailers running on a thin team it is one of the highest-leverage marketplace integrations to get right. ### Marketplacer URL: https://www.ecirql.com/platforms/marketplacer/ Summary: Platform for building online marketplaces. Marketplacer is an Australian-built platform for retailers and brands that want to operate their own marketplace, with curated seller programmes, third-party stock and the operational primitives that come with multi-seller commerce. Patchworks integrates Marketplacer for product feed ingest from seller systems, order routing to sellers, inventory and price sync, and settlement reconciliation across the seller base. The hard problems are usually around dispute handling and the financial reconciliation that follows. ### Mirakl URL: https://www.ecirql.com/platforms/mirakl/ Summary: Enterprise marketplace solutions. Mirakl is the enterprise marketplace platform: retailers like Carrefour, Best Buy and Maisons du Monde run Mirakl-powered marketplaces alongside their first-party operations. The platform handles seller onboarding, product catalogues, order routing and settlement at enterprise scale. Patchworks integrates Mirakl for seller-side product feed publishing, inventory and pricing sync, order ingestion and settlement processing. Operator-side flows handle seller onboarding, catalogue moderation and dispute reconciliation. Both sides of a Mirakl deployment have their own integration surface, and treating them separately is usually correct. Marketplace integrations are unforgiving about timing and fee mapping. Mirakl is no exception, and the discipline of running them under SLA is where the value lands. ### Onbuy URL: https://www.ecirql.com/platforms/onbuy/ Summary: UK online marketplace platform. OnBuy is a UK marketplace positioned as a smaller-fees alternative to Amazon and eBay for British sellers. The audience is mid-market retailers who want incremental marketplace presence without re-architecting their operation around Amazon. Patchworks integrates OnBuy for listings, inventory, pricing and order ingestion. The work is similar in shape to other marketplace integrations and tends to be less unforgiving than Amazon, which is a feature rather than a bug for the seller base. ### Rithum | Channel Advisor URL: https://www.ecirql.com/platforms/rithum-channel-advisor/ Summary: Multichannel commerce management platform. Rithum, formerly Channel Advisor, is one of the larger multichannel commerce platforms, with a heritage in marketplace management and a current footprint covering retail media, brand operations and seller programmes. Patchworks integrates Rithum for product feed publication, inventory and pricing sync, order ingest and settlement reconciliation across the multichannel footprint. Each channel has its own conventions; Rithum surfaces them but does not abolish them, and the integration design has to respect that. ### The Edge By John Lewis URL: https://www.ecirql.com/platforms/the-edge-by-john-lewis/ Summary: Marketplace for John Lewis partners. The Edge by John Lewis is the John Lewis Partnership's marketplace programme, allowing third-party retailers to list and sell through John Lewis's curated storefront. Patchworks integrates The Edge for product feed publication, inventory and pricing sync, order ingestion and the operational handoffs the marketplace's SLAs require. UK retailers operating on The Edge benefit from an integration design that treats it with the discipline of any other tier-one marketplace. ### TikTok Shop URL: https://www.ecirql.com/platforms/tiktok-shop/ Summary: Social commerce on TikTok platform. TikTok Shop is the social-commerce arm of TikTok, combining short-form video, live shopping and direct in-app checkout. For brands that have already built a TikTok audience it is one of the higher-leverage channels in current commerce. Patchworks integrates TikTok Shop for product feed publication, inventory and pricing sync, order ingestion and the social-commerce-specific events that conversion attribution and influencer programmes depend on. The operational dimension · fulfilment SLAs, return windows, dispute handling · works similarly to other marketplaces despite the channel feeling different to the marketing team. ### Virtualstock URL: https://www.ecirql.com/platforms/virtualstock/ Summary: Dropship marketplace platform. Virtualstock runs a dropship marketplace platform used by some of the largest UK retailers, with seller onboarding, product catalogues, order routing and dispute handling at the kind of scale the John Lewises and Argoses of the world require. Patchworks integrates Virtualstock for seller-side product feed publishing, inventory and pricing sync, and order ingestion. Operator-side flows handle seller onboarding and dispute reconciliation. The financial reconciliation across the seller base is where the integration design earns its keep. ## Marketing (5) ### Dotdigital URL: https://www.ecirql.com/platforms/dotdigital/ Summary: Omnichannel marketing automation tools. Dotdigital is a UK marketing automation platform with strong ecommerce roots, used widely by retailers running on Shopify, Magento and BigCommerce. The strength is in segmentation, programmes and the operational SLAs UK marketing teams actually need. Patchworks integrates Dotdigital for customer and order data sync, behavioural event streaming and back-flow of marketing engagement metrics into the CRM or CDP. Consent state and subscription preferences need to live consistently across systems, and that is where most data-quality issues surface. Dotdigital integrations work best when the segmentation strategy is written down before the API work begins. ### Mailchimp URL: https://www.ecirql.com/platforms/mailchimp/ Summary: Email marketing and automation tools. Mailchimp is the default email platform for small and mid-market businesses, with marketing automation, audience management and reporting that scale from one-person shops to several-thousand-employee organisations. Patchworks integrates Mailchimp for audience and contact sync, behavioural and transactional event delivery, and back-flow of engagement metrics into the CRM. Consent state is the field most integrations get wrong; getting it right is mostly discipline rather than technology. ### Mailjet URL: https://www.ecirql.com/platforms/mailjet/ Summary: Email delivery and campaign management. Mailjet is a transactional and marketing email platform, used by businesses that want a more developer-friendly API and a more European compliance posture than the US-headquartered alternatives. Patchworks integrates Mailjet for transactional email triggers from operational systems, marketing list sync and engagement-event back-flow. The integration is usually quick; the discipline is in the deliverability conventions and the audit-trail Mailjet's compliance features depend on. ### Twilio URL: https://www.ecirql.com/platforms/twilio/ Summary: Cloud communications platform. Twilio is the default cloud communications platform: SMS, voice, WhatsApp, email, the lot, behind a single developer-friendly API. For ecommerce specifically, transactional messaging and conversational commerce are the integration surfaces that matter. Patchworks integrates Twilio for transactional message triggers from operational systems, two-way conversational flows and message delivery telemetry into the CRM. Consent state and message-template discipline are the integration concerns that determine whether deliverability holds up at scale. ### ZAP~POST URL: https://www.ecirql.com/platforms/zap-post/ Summary: Direct mail automation platform. ZAP~POST is a UK direct-mail automation platform, allowing ecommerce brands to trigger physical mail · postcards, letters, samples · from operational events the same way they would trigger an email. Patchworks integrates ZAP~POST for trigger-event delivery from operational systems, address mastering and back-flow of send and delivery confirmations. Physical mail has a longer feedback loop than digital, which deserves real care in the trigger logic. ## CRM (7) ### Bloomreach URL: https://www.ecirql.com/platforms/bloomreach/ Summary: AI-driven platform for personalised customer experiences. Bloomreach started as a search-and-merchandising specialist and has since grown into a customer engagement platform that combines content, search, personalisation and email marketing. The breadth is the strength and also where integration scope tends to expand. Patchworks integrates Bloomreach across the engagement surface: customer profiles and events from the ecommerce platform, transactional and behavioural data from the order systems, content syndication from the CMS or PIM. Real-time event delivery matters for personalisation, and the event schema deserves more design attention than it usually gets. Bloomreach integrations work best when the data model is agreed up front between marketing, merchandising and engineering. ### Emarsys URL: https://www.ecirql.com/platforms/emarsys/ Summary: AI marketing platform for customer engagement. Emarsys, now part of SAP, is an enterprise-grade customer engagement platform with strong cross-channel orchestration, predictive segmentation and ecommerce-specific use cases. It is most often deployed by retailers that have outgrown Klaviyo, Bloomreach or Salesforce Marketing Cloud and need an opinionated engagement programme. Patchworks integrates Emarsys for customer and order data sync, behavioural events and the programme-level data Emarsys needs to run predictive segments. The integration work is structural: agreeing the customer identity model, deciding how transactional data lands, and respecting consent boundaries that span EU jurisdictions. For enterprise retailers running Emarsys, the quality of the data going in is the single biggest determinant of programme outcomes. ### Hubspot URL: https://www.ecirql.com/platforms/hubspot/ Summary: Inbound marketing and sales platform. HubSpot started as an inbound marketing tool and is now a full CRM, marketing and sales suite. It is the default CRM for a large share of mid-market B2B businesses and a real contender in B2C ecommerce CRM use cases. Patchworks integrates HubSpot with ecommerce platforms, ERPs and customer data sources. Contacts, deals, orders and behavioural events flow in either direction, and the customer-identity model deserves real design attention. HubSpot's properties model is forgiving, which can produce data sprawl quickly if integrations are not opinionated. For B2B ecommerce in particular HubSpot earns its keep when integrated rigorously and gets in the way when integrated lazily. ### Klaviyo URL: https://www.ecirql.com/platforms/klaviyo/ Summary: Ecommerce marketing and customer data platform. Klaviyo is the dominant ecommerce CRM and email platform for Shopify-first retailers, with steadily growing traction outside the Shopify ecosystem. The differentiator is the data model: events, profiles and metrics rather than just lists. Patchworks integrates Klaviyo via its events API. Order events, fulfilment milestones, return events and custom triggers from operational systems land as profile properties and metric events. Behavioural flows and segments key off this data, so the freshness and the granularity matter more than they do for traditional ESPs. The design work is in deciding what to send and at what granularity. Klaviyo will accept everything; marketing teams pay for ingestion and clutter quickly buries the segments that actually drive revenue. ### Mapp URL: https://www.ecirql.com/platforms/mapp/ Summary: Insight-led customer engagement platform. Mapp is a European customer engagement platform with strong roots in cross-channel orchestration and an audience that skews towards mid-market and enterprise retail across the UK, DACH and Nordics. Patchworks integrates Mapp for customer profile sync, transactional and behavioural event ingest, and back-flow of campaign engagement data into the CRM or CDP. The data model deserves real design attention; Mapp performs in proportion to the quality of what you feed it. ### Ometria URL: https://www.ecirql.com/platforms/ometria/ Summary: Retail-focused customer data platform. Ometria is a UK-built customer data platform focused on retail, with predictive segmentation, cross-channel orchestration and a data model designed for the messy reality of multichannel customers. Patchworks integrates Ometria for customer profile sync, transactional and behavioural event delivery, and back-flow of engagement and prediction data into the CRM and operational systems. Identity resolution across channels is the design work that determines whether Ometria's predictions are worth acting on. ### Voyado URL: https://www.ecirql.com/platforms/voyado/ Summary: Retail loyalty and CRM platform. Voyado is a Nordic-built retail loyalty and CRM platform, with strong adoption among European fashion and lifestyle brands that want loyalty mechanics · points, tiers, member-only experiences · wired into the customer data layer rather than bolted onto it. Patchworks integrates Voyado for customer mastering across channels, transactional and behavioural events, loyalty-balance reconciliation and back-flow of segment and prediction data. Cross-channel identity resolution is the design work that determines whether the loyalty programme reflects reality. ## PIM (5) ### Akeneo URL: https://www.ecirql.com/platforms/akeneo/ Summary: Centralised product information management for digital catalogues. Akeneo is an enterprise-grade PIM, open source at its core, used by mid-market and large retailers to centralise product data across catalogues, locales and channels. The model is opinionated: families, attributes, categories and channels. Getting the model right is the integration work. Patchworks connects Akeneo through its REST API and standard import jobs. Outbound, Akeneo syndicates products and media to ecommerce platforms, marketplaces and DAMs. Inbound, supplier feeds, ERP item masters and translation services keep Akeneo current. The wrinkles are usually in the rules: which channel sees which attribute, how locale fallbacks work, when a variant axis changes meaning across families. We design the syndication rules with the merchandising and product teams, not just the data engineers, so the PIM ends up matching how the business actually sells. ### Inriver URL: https://www.ecirql.com/platforms/inriver/ Summary: Digital-first product information management. Inriver is an enterprise PIM that competes most directly with Akeneo and Salsify, with a strong following in industrial and B2B retail where digital-first product information is the constraint on growth. Patchworks integrates Inriver for syndication to commerce platforms, marketplaces and DAMs, and for inbound supplier data, ERP item-master sync and translation services. The model design · entity types, channels, relationships · is the design effort that determines whether the PIM serves the business or constrains it. ### Pimberly URL: https://www.ecirql.com/platforms/pimberly/ Summary: Cloud PIM and DAM solution. Pimberly is a UK-built PIM and DAM with strong adoption among mid-market retailers and brands that need a more affordable on-ramp than the enterprise alternatives without losing the syndication features that make a PIM worth deploying. Patchworks integrates Pimberly for product publication to ecommerce platforms, marketplaces and channel-specific destinations, and for inbound supplier and ERP data. The model design is the design work that determines whether the PIM accelerates the merchandising team or trips it up. ### Plytix URL: https://www.ecirql.com/platforms/plytix/ Summary: PIM platform for SMB product data. Plytix is a PIM platform aimed at small and mid-market retailers, with a lighter feature set than Akeneo or Salsify and a price point to match. The fit is operationally pragmatic for businesses that need disciplined product data without enterprise overhead. Patchworks integrates Plytix for syndication to ecommerce platforms, marketplaces and DAMs, and for inbound supplier and ERP product data. The integration work is generally quick; the discipline is in the model design. ### Salsify URL: https://www.ecirql.com/platforms/salsify/ Summary: Commerce experience management platform. Salsify is a commerce experience management platform combining PIM, DAM and digital shelf analytics, with strong adoption among consumer brands selling through retailer and marketplace channels. Patchworks integrates Salsify for syndication to retailer portals, marketplaces and direct-to-consumer storefronts, and for inbound supplier feeds, ERP item-master sync and translation services. Channel-specific attribute requirements are where most of the integration design lands. Salsify rewards integrations that treat the channel as a first-class concept rather than an afterthought. ## POS (5) ### Cybertill URL: https://www.ecirql.com/platforms/cybertill/ Summary: Cloud retail management for unified commerce. Cybertill is a UK cloud retail platform with EPOS, stock control and CRM in one system, popular with multi-site independent retailers and charity retail. The fit is operational and pragmatic rather than enterprise-architectural. Patchworks integrates Cybertill for store-to-online stock visibility, customer-record reconciliation between till and ecommerce, and reporting flows into accounting and BI systems. The cross-channel reconciliation work · making sure a store sale and an online sale agree on the customer they belong to · is where these integrations earn their keep. ### Lightspeed Restaurant URL: https://www.ecirql.com/platforms/lightspeed-restaurant/ Summary: Cloud POS system for hospitality businesses. Lightspeed Restaurant, the K-Series, is the hospitality POS that came in via the Kounta acquisition. It is the choice for venue groups and restaurant operators running multi-location hospitality with menu and stock management built in. Patchworks integrates Lightspeed Restaurant for sales data into accounting and BI, stock movements into the inventory system, customer loyalty across venues, and reporting flows that finance can close on. Multi-location reconciliation is the area where these integrations earn their keep. ### Lightspeed Retail Epos URL: https://www.ecirql.com/platforms/lightspeed-retail/ Summary: Retail management with integrated payments. Lightspeed Retail Epos is the retail-side POS, used by independent and mid-market store operators across the UK, Europe and North America. The strength is retail-aware inventory and the integration touch-points that come with it. Patchworks integrates Lightspeed Retail for store-to-online stock visibility, customer mastering across retail and ecommerce, sales transactions into accounting and ERP, and loyalty reconciliation. Store and online conflict resolution · who saw the customer first, who owns the loyalty balance · is where most of the integration design lands. ### NewStore URL: https://www.ecirql.com/platforms/newstore/ Summary: Mobile-first retail management platform. NewStore is a mobile-first retail platform, popular with brand-led retailers that want a store-as-flagship experience and need the technology to match. POS, OMS and clienteling come from one platform with shared data. Patchworks integrates NewStore for store-to-online customer mastering, stock visibility across the fulfilment network, order ingestion from non-NewStore channels and back-flow into the ERP and finance systems. Clienteling data, in particular, has to land somewhere usable outside the store-associate app to earn its keep. ### Sitoo URL: https://www.ecirql.com/platforms/sitoo/ Summary: Cloud POS for unified commerce. Sitoo is a cloud POS platform built specifically for unified commerce, used by retailers running multi-store networks alongside ecommerce. The data model treats store and online as a single operation rather than two systems pretending to agree. Patchworks integrates Sitoo for store-to-online stock and customer mastering, sales transactions into accounting and ERP, and operational reporting flows. The reconciliation work · making sure store and online agree on inventory, customer state and loyalty balance · is where most of the integration value lives. ## Returns (7) ### Happy Returns URL: https://www.ecirql.com/platforms/happy-returns/ Summary: In-person and online returns solution. Happy Returns, now part of PayPal, runs an in-person and online returns network in the US, with drop-off bars and reverse-logistics consolidation as the differentiator. For US-active retailers it is one of the more operationally meaningful returns platforms. Patchworks integrates Happy Returns for RMA creation, drop-off and return-arrival events, disposition outcomes and refund triggers. The retailer's ecommerce, ERP and WMS all need the right signals at the right time so customer service, finance and the warehouse stay in sync. ### Rebound Returns URL: https://www.ecirql.com/platforms/rebound-returns/ Summary: Global returns management solution. ReBOUND is a global returns platform, with strong adoption among brands and retailers managing cross-border returns and the consolidation that makes them economical at scale. Patchworks integrates ReBOUND for RMA creation, returns-status events, disposition outcomes and refund triggers. Cross-border flows in particular benefit from a careful design around customs documentation and the financial reconciliation that follows. ### ReturnGO URL: https://www.ecirql.com/platforms/returngo/ Summary: Automated returns platform for ecommerce. ReturnGO is a returns automation platform built around self-service portals, AI-assisted disposition and exchange-first flows that prefer keeping the customer in the brand rather than refunding out of it. Patchworks integrates ReturnGO for RMA flows, refund and exchange decisions, restocking signals and operational back-flow into ERP, WMS and customer-service systems. Exchange-first flows in particular benefit from real-time inventory visibility, which is mostly an integration design choice. ### returnless URL: https://www.ecirql.com/platforms/returnless/ Summary: Digital returns optimisation platform. Returnless is a Netherlands-headquartered returns platform with a portfolio of returns and exchange flows aimed at European ecommerce. It competes most directly with ReturnGO and the regional incumbents. Patchworks integrates Returnless for RMA creation, returns-status events and refund or exchange flows. The integration shape is broadly similar across returns platforms; the differences are in the model and the partner-by-partner courier integrations Returnless ships. ### Reveni URL: https://www.ecirql.com/platforms/reveni/ Summary: Returns management for online retail. Reveni is a Spanish-built returns platform with a strong focus on instant-refund flows that improve customer experience while the actual returns logistics catches up behind the scenes. Patchworks integrates Reveni for RMA creation, instant-refund triggers, courier handoffs and reconciliation against the actual returned goods. The financial design needs care: instant refunds work for the customer experience and against finance if the reconciliation back to received stock is not airtight. ### Swap Commerce URL: https://www.ecirql.com/platforms/swap-commerce/ Summary: Returns optimisation platform. Swap is a returns and post-purchase platform focused on retention through exchanges, store credit and lifetime-value-aware refund decisions, rather than treating every return as a refund opportunity. Patchworks integrates Swap for RMA flows, exchange and store-credit decisions, restocking signals and customer-service handoffs. The integration design that determines retention outcomes is mostly in the inventory-visibility and exchange-eligibility rules, which deserve real care. ### ZigZag Returns URL: https://www.ecirql.com/platforms/zigzag-returns/ Summary: Global returns management platform. ZigZag is a global returns platform with a particular strength in cross-border returns and the consolidation that makes them economical. It is used by brands and retailers managing international returns flows that do not fit a single 3PL. Patchworks integrates ZigZag for RMA creation, courier handoffs, returns-status events, customs documentation and refund triggers. Cross-border returns are unforgiving operationally; the integration design respects that and surfaces the failure modes early. ## Accounting (5) ### CacheFlow URL: https://www.ecirql.com/platforms/cacheflow/ Summary: B2B payment platform optimising cash flow management. CacheFlow is a B2B payment platform built around the way modern subscription and platform businesses actually invoice: deal-shaped, multi-line, with structured terms and approvals. It sits between the CRM, the billing system and the bank. Patchworks integrates CacheFlow with CRMs, billing platforms and accounting systems. Deals flow from the CRM as structured contract data, billing schedules generate invoices, and finance sees the result without manual transcription. For finance and revops teams CacheFlow is most useful when its data lands cleanly in the ledger, which is where the integration work pays off. ### FreeAgent URL: https://www.ecirql.com/platforms/freeagent/ Summary: Online accounting for freelancers and small business. FreeAgent is UK SMB accounting, popular with freelancers, micro-businesses and small agencies. The product is opinionated about simplicity, which is most of its appeal. Patchworks integrates FreeAgent for invoice and credit-note creation, payment reconciliation and the basic data flows ecommerce SMBs need into their accountant's preferred system. The integration is usually quick; the design care is in how returns and refunds map into FreeAgent's ledger so the close stays clean. ### QuickBooks URL: https://www.ecirql.com/platforms/quickbooks/ Summary: Financial management for small business. QuickBooks Online is the default cloud accounting platform for small and mid-market businesses worldwide. It is the system the bookkeeper uses, and that is mostly what matters when designing the integration. Patchworks integrates QuickBooks for invoice and credit-note creation, customer mastering, payment reconciliation and ledger postings from ecommerce, ERP and marketplace channels. The discipline is in the tax-code and chart-of-accounts mapping at integration time, which determines whether finance can close cleanly or has to clean up after the integration each month. ### Sage 200 URL: https://www.ecirql.com/platforms/sage-200/ Summary: Business management for manufacturing. Sage 200 is a UK-favoured business management platform, popular with manufacturers, distributors and multichannel retailers in the £5m to £50m range. It handles the operational accounting and stock surface with the dialect British businesses are used to. Patchworks integrates Sage 200 for sales-order ingest from ecommerce and marketplace channels, stock and pricing sync, purchase-order generation and finance postings. The data model rewards integrations that respect its accounting conventions; the integrations that try to treat it as a generic database tend to need rework. We have shipped Sage 200 integrations across both standard and customised deployments, and the customised case in particular benefits from Patchworks's per-flow scoping. ### Xero URL: https://www.ecirql.com/platforms/xero/ Summary: Cloud accounting for small business. Xero is the cloud accounting platform of choice for UK, Australian and New Zealand SMBs, with a steadily growing footprint elsewhere. The product is opinionated about bookkeeper experience, which is most of its value. Patchworks integrates Xero for invoice and credit-note creation, customer mastering, payment reconciliation and ledger postings from ecommerce, ERP and marketplace channels. Tracking categories and chart-of-accounts mapping at integration time are the discipline that determines whether finance can close cleanly each month. ## Data & BI (5) ### Airtable URL: https://www.ecirql.com/platforms/airtable/ Summary: Collaborative platform combining spreadsheet and database functionality. Airtable sits between a spreadsheet and a database. Operations teams use it as a lightweight system of record for things that do not deserve a full application: supplier onboarding workflows, content production trackers, returns triage, campaign briefs. The API is generous, the rate limits are not, and views can mask the shape of the underlying data in ways integrations need to handle carefully. Patchworks integrates Airtable via its REST API. Typical flows push data into Airtable from an ERP, ecommerce platform or marketing tool so operations teams can act on it in the surface they already use, and pull updates back out so changes do not stay trapped in a side system. Most Airtable integrations earn their keep by closing the loop between an operations team's spreadsheet and the systems that fulfil what the spreadsheet promises. ### Google BigQuery URL: https://www.ecirql.com/platforms/google-bigquery/ Summary: Cloud data warehouse for large-scale analytics. BigQuery is Google Cloud's serverless data warehouse. It is the default destination for analytical workloads on GCP and a common one for retailers and brands regardless of where their operational systems live, because the pricing and the SQL surface are forgiving. Patchworks integrates BigQuery as a destination, source or both. Operational data from ecommerce, ERP, WMS and marketing systems lands in BigQuery on schedule or via event triggers; analytical outputs and segments flow back out to operational tools. Idempotency, lineage and clear ownership are the design conversations worth having early. BigQuery integrations are easy to start and easy to neglect. Owning the freshness and shape of the data going in is where the discipline pays off. ### Google Sheets URL: https://www.ecirql.com/platforms/google-sheets/ Summary: Collaborative spreadsheet application. Google Sheets is the world's most-deployed lightweight integration target. Operations teams reach for it constantly, and the gap between "this lives in Google Sheets" and "this is now a real system" is where integration agencies make themselves useful. Patchworks integrates Google Sheets for data ingest from operational systems, exception-handling workflows that need a spreadsheet shape to work with, and reporting outputs that finance and operations teams already know how to consume. The discipline is in not letting the Sheet become a permanent system of record by accident. ### MongoDB URL: https://www.ecirql.com/platforms/mongodb/ Summary: NoSQL database for modern applications. MongoDB is the default document database for modern application stacks, with a permissive data model and a generous query surface that suit the parts of operations that do not fit cleanly into a relational schema. Patchworks integrates MongoDB as a data source or destination, depending on where it sits in the estate. Document shape and indexing strategy matter for the integration's stability; getting them right is usually a joint conversation between the integration team and the application engineers who own the database. ### Snowflake URL: https://www.ecirql.com/platforms/snowflake/ Summary: Cloud data platform for enterprises. Snowflake is the cloud data platform that has displaced the older data-warehouse incumbents across mid-market and enterprise. The separation of storage and compute, the SQL surface and the partner ecosystem make it the default destination for analytical workloads in retail. Patchworks integrates Snowflake as a destination, source or both. Operational data lands on schedule or via event triggers; analytical outputs and segments flow back into operational tools. The freshness and shape of the data going in determines whether downstream analytics is useful or merely impressive. ## Messaging (2) ### Google Pub/Sub URL: https://www.ecirql.com/platforms/google-pubsub/ Summary: Real-time messaging for event-driven systems. Pub/Sub is Google Cloud's managed message broker. It handles the asynchronous, event-driven plumbing for integration estates that need to scale beyond synchronous request/response patterns. Patchworks uses Pub/Sub as a backbone for event-driven integration. Topics carry order events, fulfilment milestones, inventory changes and operational signals between systems. Retry, replay, dead-letter handling and delivery semantics are first-class concerns rather than afterthoughts. The integrations that benefit most from Pub/Sub are the ones where systems do not need to know about each other directly. The design effort is in deciding what the events mean, not what the broker does. ### rabbitMQ URL: https://www.ecirql.com/platforms/rabbitmq/ Summary: Message broker for applications. RabbitMQ is the established open-source message broker, used in integration estates that need queueing, pub/sub and routing without going all-in on a cloud-vendor's managed service. Patchworks uses RabbitMQ as a backbone for event-driven integration, with topics carrying operational events between systems. Retry, dead-letter handling and replay semantics are first-class concerns. The design effort is in the topology · exchanges, queues, routing keys · and the operational ownership of the broker itself. ## Service Desk (4) ### Freshdesk URL: https://www.ecirql.com/platforms/freshdesk/ Summary: Customer support and ticket management system. Freshdesk is Freshworks's customer support platform, a Zendesk alternative with strong adoption in mid-market and global support operations. The product is generally easier to deploy than Zendesk and slightly less rich at the high end, which is mostly a feature. Patchworks integrates Freshdesk for ticket creation, customer-context lookup against ERP and ecommerce data, and macro automation that respects the operational truth elsewhere in the stack. Order status, RMA state and customer history flowing into the agent surface is where most of the value lands. ### Gorgias URL: https://www.ecirql.com/platforms/gorgias/ Summary: Ecommerce-focused customer service platform. Gorgias is a customer service platform built specifically for ecommerce, with native integrations to Shopify, BigCommerce, Magento and the big marketplaces. The product is opinionated about ecommerce workflows, which is why it tends to displace generic helpdesks once a retailer has scaled past a certain size. Patchworks integrates Gorgias for order-context lookup against ERP and OMS data, automated ticket routing based on operational state, and feedback of resolution data into the CRM. The work that pays off most is closing the loop between support and operations: the right context on every ticket, the right escalation path when the answer lives outside the storefront. ### Pagerduty URL: https://www.ecirql.com/platforms/pagerduty/ Summary: Digital operations management platform. PagerDuty is the incident-response platform for engineering and operations teams that need on-call rotations, escalation policies and the audit trail incidents require. Patchworks integrates PagerDuty for incident creation from operational signals, escalation hooks and resolution feedback into the CRM and support systems. The work is in deciding what should page a human and what should not, which is mostly a design conversation about thresholds and ownership. ### Zendesk URL: https://www.ecirql.com/platforms/zendesk/ Summary: Customer service platform. Zendesk is the default enterprise customer service platform, with strong agent workflows, automation and integration breadth. For ecommerce specifically, the integration scope is around order context, post-purchase events and the customer-history surface agents need. Patchworks integrates Zendesk for ticket creation, customer-context lookup against ERP and ecommerce data, automated routing and resolution feedback into the CRM. The work that pays off most is closing the loop between support and operations: tickets with the right context, agents with the right tools, finance with the right reconciliation. ## Search & Merchandising (1) ### Algolia URL: https://www.ecirql.com/platforms/algolia/ Summary: Fast and relevant search for websites and applications. Algolia is hosted search. It runs the on-site search and merchandising surface for a long list of mid-market and enterprise retailers, with InstantSearch on the front end and a managed indexing pipeline behind it. The trade-off is that the search experience is only as good as the index, and the index is only as good as what you push to it. Patchworks pushes products, variants, prices, inventory state and ranking signals into Algolia from ecommerce platforms, PIMs and ERPs. Reindex cadence, partial updates and synonyms live alongside the product feed work. Conversion events flow back into Algolia for ranking and personalisation when those features are licensed. Most search integrations live or die on the index schema. We design that schema in the open, with the merchandising team in the room. ## OMS (3) ### Fluent Commerce URL: https://www.ecirql.com/platforms/fluent-commerce/ Summary: Distributed order management for omnichannel retail. Fluent Commerce is a distributed order management platform, designed for retailers running omnichannel fulfilment with stores, warehouses and dropship suppliers all participating in fulfilling the same order. Sourcing rules, allocation, splits and routing are first-class. Patchworks integrates Fluent for order ingestion from ecommerce and marketplace channels, sourcing-decision feedback to the customer experience layer, fulfilment-status updates from WMS systems and back-flow into the ERP. The design effort is in the sourcing rules · which node fulfils which order · and the visibility of those decisions to the operations team. Distributed fulfilment is where omnichannel promises get tested. Fluent helps. Integration design helps further. ### Fulfillment Tools URL: https://www.ecirql.com/platforms/fulfillment-tools/ Summary: Order management optimising multichannel fulfilment. Fulfillment Tools is a German-built distributed order management platform, recently spun out of REWE Digital, focused on retailers and brands operating store fulfilment, micro-fulfilment and warehouse-as-a-network setups. Patchworks integrates Fulfillment Tools for order routing, store and warehouse fulfilment confirmations, inventory reconciliation across the fulfilment network and back-flow into ERP and ecommerce. Store-fulfilment in particular benefits from a careful flow design that respects the cadence and constraints of in-store picking. ### OneStock URL: https://www.ecirql.com/platforms/onestock/ Summary: Omnichannel order management solution. OneStock is a French-built distributed order management platform, with strong adoption in European retail running store fulfilment, multi-warehouse setups and click-and-collect. Patchworks integrates OneStock for order routing, inventory orchestration across the fulfilment network, fulfilment-status updates and back-flow into the ecommerce and ERP layers. Store-fulfilment in particular benefits from a flow design that respects the realities of in-store picking SLAs. ## DXP (1) ### Occtoo URL: https://www.ecirql.com/platforms/occtoo/ Summary: Digital experience platform for headless commerce. Occtoo is a data orchestration platform built for commerce, helping retailers and brands collect, model and serve product, content and customer data across the systems that depend on it. Patchworks integrates Occtoo as a data hub between commerce platforms, PIMs, ERPs and downstream consumers. The interesting design work is the shape of the unified model and the latency budget different consumers need. Occtoo earns its keep when the data model is designed in the open with the teams that will live with it. ## CMS (1) ### Sanity URL: https://www.ecirql.com/platforms/sanity/ Summary: Headless content management system. Sanity is a headless content platform with a structured-content model that suits brands and retailers who want editorial flexibility without a CMS dictating the data shape. The Studio editor and the GROQ query language are unusually thoughtful pieces of tooling. Patchworks integrates Sanity with commerce platforms, PIMs and operational data sources. Content models, components, locales and previews flow with the editorial team's needs respected and the front-end's data needs met. Co-designing the content model with editorial and engineering is usually the first hour of work that saves the last week. ## EDI & Files (2) ### ediFabric URL: https://www.ecirql.com/platforms/edifabric/ Summary: Framework for EDI document processing. ediFabric is an EDI framework for .NET, used by developers and integration teams who need to parse, validate and emit EDI documents without paying for a full EDI platform. It is library-shaped: the rest of the integration estate has to provide the orchestration, the partner-by-partner config and the retry semantics. Patchworks pairs naturally with ediFabric. ediFabric handles the document layer; Patchworks handles the transport, partner-routing, mapping into ERP or WMS systems and the visibility a trading-partner programme actually needs. EDI integrations get judged on reliability under pressure. The architecture matters more than the tooling, and that is where the design effort lands. ### SFTP Connector URL: https://www.ecirql.com/platforms/sftp-connector/ Summary: Secure file transfer integration. SFTP is not a platform but a protocol, and it is the lowest-common-denominator integration surface for trading partners, ERPs and warehouses that pre-date REST APIs. A surprising amount of operational integration traffic still moves over SFTP. Patchworks's SFTP connector handles file drops, scheduled polls, encryption and the partner-by-partner conventions every SFTP relationship accretes. The design work is in the file naming, the manifest discipline and the visibility a trading-partner programme needs around what landed when. SFTP integrations are uncool and durable. We treat them with the same engineering rigour as anything else. ## Project Management (3) ### Jira URL: https://www.ecirql.com/platforms/jira/ Summary: Issue tracking and agile project management. Jira is Atlassian's issue tracker, used by most development teams and a large share of operational ones. Integration estates touch Jira whenever ops, support or engineering work needs to cross system boundaries: tickets become deployments, incidents become tasks, releases become customer notifications. Patchworks integrates Jira for ticket-driven automation, release-cycle hooks and the operational feedback developers actually need. The work is mostly in the agreed boundaries · what counts as a ticket, who owns the transition, when the integration writes back. ### Tempo URL: https://www.ecirql.com/platforms/tempo/ Summary: Time tracking and project planning. Tempo is an Atlassian-ecosystem time tracking and resource planning tool, used by agencies, consultancies and product teams that need professional-services-grade time data on top of Jira. Patchworks integrates Tempo for time and cost data into finance and billing systems, project state into operational reporting and back-flow from operational systems into project plans. The integration scope is usually narrow; the discipline is in the data conventions that make finance happy. ### Trello URL: https://www.ecirql.com/platforms/trello/ Summary: Visual task management tool. Trello is Atlassian's visual project management tool, used widely outside engineering for operational checklists, content production, supplier onboarding and the daily-cadence work that does not justify a full PM system. Patchworks integrates Trello where the visual board needs to talk to the systems that fulfil what the board promises: order operations, customer service workflows, content pipelines. The design effort is in deciding when the board is the source of truth and when it is the dashboard. ## AI (1) ### OpenAI URL: https://www.ecirql.com/platforms/openai/ Summary: AI research and deployment platform. OpenAI's API is the most-deployed AI integration surface in commerce today. Models for generation, embeddings, function calling and structured output sit behind a single API, with the cost model and the latency budget being the operational constraints most projects underestimate. Patchworks integrates OpenAI as part of agentic workflows, retrieval pipelines and operational automations. Model calls, embeddings, tool definitions and event triggers all flow through the same pipes as the rest of the integration estate. Cost controls, retry semantics, audit logging and the safety boundary deserve as much design attention as any classic integration concern. This is the heart of our AI enablement practice: production AI integrations, not pilots. ## Other (4) ### Avasam URL: https://www.ecirql.com/platforms/avasam/ Summary: UK dropshipping platform connecting retailers with suppliers. Avasam is a UK-based dropshipping marketplace that connects retailers with verified suppliers, with the platform handling stock visibility, order routing, shipping and supplier billing. Smaller than the wholesale-marketplace incumbents but well-suited to UK retailers that want a curated supplier base rather than a global one. Patchworks integrates Avasam for product feed ingest, real-time stock updates, order routing and shipment confirmations. The interesting work is usually on the retailer's ERP and ecommerce side, where dropship items need to behave operationally like own-stock items without confusing finance or fulfilment. ### Octopus Energy URL: https://www.ecirql.com/platforms/octopus-energy/ Summary: Digital energy supply management. Octopus Energy is a UK energy supplier with a substantial software practice and an open API for partners working in the energy supply ecosystem. Outside the energy market the platform is unusual but the integration patterns translate. Patchworks integrates Octopus where the supply chain requires it: usage data, smart-meter telemetry, billing flows and the operational signals partners need to act on. Each use case is its own design conversation. ### Patchworks Blueprints URL: https://www.ecirql.com/platforms/patchworks-blueprints/ Summary: Integration platform for commerce systems. Blueprints are Patchworks's library of pre-built process flows for common integration patterns: Shopify to NetSuite orders, BigCommerce to OrderWise inventory, and a long list of the connector-to-connector flows that recur across projects. They are starting points, not finished integrations. Our delivery practice uses Blueprints as the foundation and customises from there, which is faster than starting from a blank canvas and more honest than promising a Blueprint will deploy unmodified into a real operation. The point of a certified Patchworks Partner Agency is that we know which Blueprints to use, which to extend, and which to replace. That judgement is the agency work. ### Reviews URL: https://www.ecirql.com/platforms/reviews/ Summary: Customer review management system. Customer reviews · through Reviews.io, Yotpo, Trustpilot or another platform · sit between marketing, customer service and product. The integration scope is usually narrower than it looks: trigger requests at the right point, ingest the responses, surface them where the rest of the operation can act on them. Patchworks integrates reviews platforms for trigger-event delivery, review and rating ingest, and back-flow into the storefront and PIM where ratings appear. Negative-review escalation into the customer service tool is one of the higher-leverage flows that often goes unconsidered. --- # Integration combos 45 platform-to-platform combos published. Each describes a real pair we ship, with the capability flows actually supported. ## Shopify to NetSuite URL: https://www.ecirql.com/integrations/shopify-to-netsuite/ Lead: Shopify is where the orders come in. NetSuite is where the business runs: stock, finance, customers, fulfilment, the lot. Connecting them properly means deciding which side owns each piece of data, then enforcing that decision in every flow that moves between them. We design, build and support Shopify-to-NetSuite integrations as a certified Patchworks Partner Agency. Order capture, customer sync, inventory and pricing publication, fulfilment writeback, refunds and tax. Same team for delivery and ongoing support, with a defined SLA from day one. Patchworks angle: Patchworks ships Blueprints for the canonical Shopify-to-NetSuite patterns: orders, customers, items, inventory and fulfilment events. Our delivery extends those Blueprints where the merchant's NetSuite account diverges from the template: custom record types, OneWorld subsidiary routing, non-standard item types, locked-period handling. We build directly in Patchworks, version flows alongside the merchant's release process, and hand over a runbook the on-call engineer can act on at three in the morning without needing to call us. Capabilities (8): - Order sync (Shopify -> NetSuite): Orders raised in Shopify flow into NetSuite on creation, status change and edit. The flow normalises Shopify's order schema into the record shape NetSuite expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so NetSuite stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (NetSuite -> Shopify): Stock levels in NetSuite push to Shopify on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where Shopify has its own location model we map NetSuite's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with NetSuite retaining authority. - Product sync (NetSuite -> Shopify): Product master data syncs from NetSuite to Shopify on publish, with channel-aware enrichment so Shopify only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Shopify has channel-specific requirements that NetSuite does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (NetSuite -> Shopify): Price lists in NetSuite push to Shopify with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where NetSuite runs effective-dated pricing, the flow coordinates the cutover so Shopify's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Customer sync (Shopify -> NetSuite): Customers created or updated in Shopify flow into NetSuite with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to NetSuite's defaults. Where NetSuite is the customer system of record (CRM or ERP) we publish back into Shopify so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Returns sync (Shopify -> NetSuite): Return authorisations created in Shopify flow into NetSuite with reason codes, inspection state, restocking decisions and refund eligibility carried through. Where NetSuite is the ERP or WMS, the return becomes an inbound record that affects available stock and accounts. Where NetSuite is the storefront, the order record updates so the customer-facing return state stays honest. Exchanges are handled as a paired return-plus-outbound rather than collapsed into a refund-plus-new-order, which keeps the accounting clean and the operational picture accurate. - Refund sync (NetSuite -> Shopify): Refund decisions raised in NetSuite push into Shopify as the financial event they are, with original payment method, partial-versus-full handling, tax recalculation and currency intact. The flow waits on inspection outcome where the merchant policy requires it rather than firing on RMA creation. Refunds against gift cards, multi-tender orders and marketplace orders (where the marketplace owns the refund execution) each take a different path; the integration picks the right one based on the original order's tender mix rather than a single default rule. - Tax sync (NetSuite -> Shopify): Tax codes, tax classes and jurisdiction rules in NetSuite push to Shopify so the storefront or marketplace charges what finance will actually post. VAT groups, reverse-charge B2B handling, marketplace-of-record tax (where the channel collects on the seller's behalf) and US sales-tax nexus are each modelled explicitly. The integration validates that Shopify's tax calculation matches NetSuite's before publishing a price; mismatches are flagged loudly rather than left to surface at month-end on a VAT return. Timeline: 6 to 10 weeks for a standard delivery - Week 1: Discovery: data-model walkthrough, NetSuite record-type choice, edge-case mapping. - Weeks 2 to 4: Build: order, customer, inventory, fulfilment and refund flows in Patchworks. - Weeks 5 to 6: Integration testing against real Shopify and NetSuite sandbox data. - Weeks 7 to 8: UAT with operations and finance teams; sign-off on edge cases. - Weeks 9 to 10: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: Do we need NetSuite OneWorld? A: No. The integration works with single-instance NetSuite and OneWorld. OneWorld is required where you trade through multiple subsidiaries with separate ledgers; for many UK merchants single-instance is the right call. Q: How does the integration handle Shopify gift cards? A: Gift card sales post to NetSuite as a deferred-revenue line against a liability account; redemptions release the liability against the order they're used on. We don't collapse the two events into a single discount line, because that breaks the VAT trail. Q: Can we keep Shopify's inventory native, or must NetSuite be the source? A: Either pattern is supportable. The right answer depends on where the operational workflow sits. For merchants with multiple sales channels we generally make NetSuite the source of truth, with channel-aware availability rules pushing into Shopify; for single-channel Shopify merchants the inverse is sometimes simpler. Q: What about Shopify Plus checkout extensibility? A: Supported. Custom checkout fields land on the order payload and map into NetSuite custom transaction fields. We define the mapping at scoping so finance and operations both know what's where. Q: Do you support Shopify-to-NetSuite under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Sage 200 URL: https://www.ecirql.com/integrations/shopify-to-sage-200/ Lead: Shopify is the storefront. Sage 200 is where the UK back office runs: nominal ledger, stock, purchase orders, VAT, the whole accounting and operational stack. The integration moves orders, customers and payments out of Shopify into Sage 200 as proper sales documents, and pushes stock and pricing back the other way so the storefront reflects the warehouse rather than wishful inventory. We design, build and support Shopify-to-Sage 200 integrations as a Patchworks Partner Agency, with the SLA picking up the moment the integration goes live. Patchworks angle: Sage 200's data model is built around accounting conventions rather than ecommerce expectations, and integrations that try to ignore that tend to need rework within months. We build the Shopify-to-Sage 200 flows directly in Patchworks, mapping orders onto the right Sage transaction types, respecting nominal codes and VAT groups, and letting Sage's batch posting cadence drive the rhythm where finance needs it to. The runbook covers the edge cases Sage tends to surface loudest at month-end. Capabilities (8): - Order sync (Shopify -> Sage 200): Orders raised in Shopify flow into Sage 200 on creation, status change and edit. The flow normalises Shopify's order schema into the record shape Sage 200 expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Sage 200 stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (Sage 200 -> Shopify): Stock levels in Sage 200 push to Shopify on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where Shopify has its own location model we map Sage 200's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with Sage 200 retaining authority. - Product sync (Sage 200 -> Shopify): Product master data syncs from Sage 200 to Shopify on publish, with channel-aware enrichment so Shopify only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Shopify has channel-specific requirements that Sage 200 does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (Sage 200 -> Shopify): Price lists in Sage 200 push to Shopify with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where Sage 200 runs effective-dated pricing, the flow coordinates the cutover so Shopify's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Customer sync (Shopify -> Sage 200): Customers created or updated in Shopify flow into Sage 200 with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Sage 200's defaults. Where Sage 200 is the customer system of record (CRM or ERP) we publish back into Shopify so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Returns sync (Shopify -> Sage 200): Return authorisations created in Shopify flow into Sage 200 with reason codes, inspection state, restocking decisions and refund eligibility carried through. Where Sage 200 is the ERP or WMS, the return becomes an inbound record that affects available stock and accounts. Where Sage 200 is the storefront, the order record updates so the customer-facing return state stays honest. Exchanges are handled as a paired return-plus-outbound rather than collapsed into a refund-plus-new-order, which keeps the accounting clean and the operational picture accurate. - Refund sync (Shopify -> Sage 200): Refund decisions raised in Shopify push into Sage 200 as the financial event they are, with original payment method, partial-versus-full handling, tax recalculation and currency intact. The flow waits on inspection outcome where the merchant policy requires it rather than firing on RMA creation. Refunds against gift cards, multi-tender orders and marketplace orders (where the marketplace owns the refund execution) each take a different path; the integration picks the right one based on the original order's tender mix rather than a single default rule. - Tax sync (Sage 200 -> Shopify): Tax codes, tax classes and jurisdiction rules in Sage 200 push to Shopify so the storefront or marketplace charges what finance will actually post. VAT groups, reverse-charge B2B handling, marketplace-of-record tax (where the channel collects on the seller's behalf) and US sales-tax nexus are each modelled explicitly. The integration validates that Shopify's tax calculation matches Sage 200's before publishing a price; mismatches are flagged loudly rather than left to surface at month-end on a VAT return. Timeline: 6 to 9 weeks for a standard delivery - Week 1: Discovery: Sage 200 chart-of-accounts walkthrough, VAT scheme, nominal posting rules. - Weeks 2 to 4: Build: order, customer, stock and pricing flows in Patchworks. - Weeks 5 to 6: Integration testing against the live Sage instance using a staged Shopify store. - Weeks 7 to 8: UAT with finance and operations; sign-off on VAT and nominal mappings. - Week 9: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: Does the integration work with Sage 200 on-premise or only Sage 200 Cloud? A: Both. The Patchworks connector supports Sage 200 Standard (cloud-hosted) and Sage 200 Professional (on-premise or partner-hosted). The flow logic is the same; the access path differs. Q: How are Shopify discounts represented in Sage 200? A: Order-level and line-level discounts post as discount lines against the relevant nominal code rather than being baked into the unit price. Finance can see what was sold at what value and what was discounted; reporting stays honest. Q: Can Sage 200 stock drive Shopify availability? A: Yes. For most engagements Sage is the source of truth for stock, with location-aware availability rules publishing to Shopify on a delta schedule plus event-driven updates on warehouse movement. Safety stock buffers are configurable per SKU group. Q: What about multi-currency orders? A: Supported. Shopify Markets orders post to Sage 200 in the order currency, with FX policy applied at the configured rate. We agree the rate source at scoping so finance isn't reconciling two interpretations. Q: Do you support Shopify-to-Sage 200 under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## NetSuite to Amazon Seller Central URL: https://www.ecirql.com/integrations/netsuite-to-amazon-seller-central/ Lead: Selling on Amazon is half the work. Reconciling Amazon back into the ERP without losing the trail is the other half. Our NetSuite to Amazon Seller Central integration runs the listings, the inventory, the order ingest and the settlement reconciliation as one connected flow, so the finance team sees Amazon revenue land in the right GL accounts and the operations team sees Amazon orders alongside the rest of the channel mix. We deliver and support the integration as a certified Patchworks Partner Agency. Patchworks angle: Amazon's seller APIs change often and rarely warn you. The Patchworks connector abstracts the moving parts so the merchant-side flows stay stable when Amazon shifts a schema or deprecates an endpoint. We build NetSuite-to-Amazon delivery directly in Patchworks: product publication, inventory sync per marketplace, order ingest, fulfilment writeback for on-time-dispatch SLA, and settlement reports reconciled line by line against NetSuite transactions and item-fulfilment records. Capabilities (5): - Order sync (Amazon Seller Central -> NetSuite): Orders raised in Amazon Seller Central flow into NetSuite on creation, status change and edit. The flow normalises Amazon Seller Central's order schema into the record shape NetSuite expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so NetSuite stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (NetSuite -> Amazon Seller Central): Stock levels in NetSuite push to Amazon Seller Central on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where Amazon Seller Central has its own location model we map NetSuite's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with NetSuite retaining authority. - Product sync (NetSuite -> Amazon Seller Central): Product master data syncs from NetSuite to Amazon Seller Central on publish, with channel-aware enrichment so Amazon Seller Central only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Amazon Seller Central has channel-specific requirements that NetSuite does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (NetSuite -> Amazon Seller Central): Price lists in NetSuite push to Amazon Seller Central with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where NetSuite runs effective-dated pricing, the flow coordinates the cutover so Amazon Seller Central's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Settlement reconciliation (Amazon Seller Central -> NetSuite): Marketplace settlement reports from Amazon Seller Central reconcile against the order, refund and fee records on the NetSuite side. Each line in the settlement is matched to the underlying transaction or surfaced as an unmatched item for finance review; nothing is silently dropped. Marketplace-specific concepts (chargebacks, A-to-Z claims, FBA reimbursements, listing fees, referral fees) get their own GL account mapping rather than being lumped into a single 'marketplace fees' bucket. Period close becomes tractable instead of a week of spreadsheet detective work. Timeline: 5 to 8 weeks for a standard delivery - Week 1: Discovery: marketplace scope (UK / EU / US), FBA vs seller-fulfilled mix, tax-of-record handling. - Weeks 2 to 4: Build: listing, inventory, order, fulfilment and settlement flows in Patchworks. - Weeks 5 to 6: Integration testing against the Amazon sandbox and NetSuite, including settlement reconciliation. - Week 7: UAT with operations and finance; sign-off on FBA edge cases and chargeback handling. - Week 8: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: Can the integration handle multiple Amazon marketplaces? A: Yes. Each marketplace (Amazon.co.uk, Amazon.de, Amazon.com, and so on) maps to its own NetSuite channel and subsidiary where appropriate. Listings, inventory and orders are scoped per marketplace, with shared product master data where it makes sense. Q: How does settlement reconciliation work? A: Amazon settlement reports import line by line. Each line matches to the underlying NetSuite transaction (order, refund, adjustment, fee) or surfaces as an unmatched item for finance review. Nothing is silently dropped, and the GL impact is itemised rather than lumped into a single 'marketplace fees' bucket. Q: Do you support FBA inventory? A: Yes. FBA inventory is modelled as a distinct NetSuite location with its own availability rules. Sellable inventory at FBA is published back to Amazon listings; movement between FBA and merchant locations is logged so the operations team sees the full stock picture. Q: What happens when Amazon updates the SP-API? A: The Patchworks connector absorbs most schema and endpoint changes without the merchant-side flows needing rework. Where a change is structural, the support retainer covers the upgrade work within the same agreement rather than as a separate procurement. Q: Do you support NetSuite-to-Amazon under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Descartes Peoplevox URL: https://www.ecirql.com/integrations/shopify-to-descartes-peoplevox/ Lead: Peoplevox is one of the most capable warehouse management systems in UK ecommerce, and Shopify is the storefront most often sitting in front of it. The integration carries the order from the moment it's placed through to the moment it leaves the warehouse, and then carries the fulfilment and tracking back so the customer-facing surface reflects reality rather than the warehouse's last known state. We design, build and support Shopify-to-Peoplevox integrations as a Patchworks Partner Agency. Patchworks angle: Peoplevox rewards integrations that respect its picking, packing and dispatch model rather than treating it as a generic order sink. We build the Shopify-to-Peoplevox flows in Patchworks with explicit handling for split shipments, partial fulfilments, back-orders, gift messages and the carrier service rules Peoplevox uses to route work on the warehouse floor. Inventory, fulfilment and tracking flow back into Shopify in the same Patchworks integration so the storefront stays honest end to end. Capabilities (5): - Order sync (Shopify -> Descartes Peoplevox): Orders raised in Shopify flow into Descartes Peoplevox on creation, status change and edit. The flow normalises Shopify's order schema into the record shape Descartes Peoplevox expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Descartes Peoplevox stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (Descartes Peoplevox -> Shopify): Stock levels in Descartes Peoplevox push to Shopify on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where Shopify has its own location model we map Descartes Peoplevox's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with Descartes Peoplevox retaining authority. - Fulfilment sync (Descartes Peoplevox -> Shopify): Pick, pack and dispatch events from Descartes Peoplevox push back into Shopify so the order record advances in step with the physical warehouse. Partial fulfilments, split shipments, backorders and substitutions are modelled rather than collapsed into a single 'shipped' state. Carrier, service level, tracking number and dispatched-at timestamp arrive on the same event so Shopify's customer comms can fire at the right moment. Where Shopify is a marketplace, the flow conforms to that marketplace's strict on-time-dispatch SLA rather than the storefront's looser conventions. - Tracking sync (Descartes Peoplevox -> Shopify): Carrier tracking numbers and delivery events from Descartes Peoplevox sync into Shopify so the customer-facing surface (order page, dispatch email, helpdesk ticket) reflects real delivery state rather than the warehouse's last known status. Updates flow through as events: in-transit, out-for-delivery, delivered, attempted, returned-to-sender. Shopify's notification rules fire against these events rather than against Descartes Peoplevox's internal status codes, which means the customer experience stays consistent even when the carrier mix changes underneath. - Returns sync (Shopify -> Descartes Peoplevox): Return authorisations created in Shopify flow into Descartes Peoplevox with reason codes, inspection state, restocking decisions and refund eligibility carried through. Where Descartes Peoplevox is the ERP or WMS, the return becomes an inbound record that affects available stock and accounts. Where Descartes Peoplevox is the storefront, the order record updates so the customer-facing return state stays honest. Exchanges are handled as a paired return-plus-outbound rather than collapsed into a refund-plus-new-order, which keeps the accounting clean and the operational picture accurate. Timeline: 4 to 7 weeks for a standard delivery - Week 1: Discovery: Peoplevox warehouse setup, carrier mix, packaging hints, fulfilment rules. - Weeks 2 to 3: Build: order, fulfilment, inventory and tracking flows in Patchworks. - Weeks 4 to 5: Integration testing against a real Peoplevox sandbox using staged Shopify orders. - Week 6: UAT with the warehouse team; sign-off on split shipments and carrier routing edge cases. - Week 7: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: Can Peoplevox inventory drive Shopify availability? A: Yes. Peoplevox can be the source of truth for sellable stock, with channel-aware availability rules publishing to Shopify on a fast cadence plus event-driven updates on receipt and movement. Safety stock buffers are configurable per SKU group and per location. Q: How does the integration handle split shipments? A: Split shipments are first-class. When Peoplevox ships an order across multiple parcels, each fulfilment posts back to Shopify with its own carrier, service level and tracking number against the right order lines. Customer notification fires per parcel rather than collapsing into a single 'shipped' event. Q: What about gift messages and packaging hints? A: Carried through. Custom Shopify checkout fields, line-item attributes and order notes map onto Peoplevox fields the warehouse team can act on at pick and pack time. We define the mapping during scoping so nothing arrives at the warehouse as a surprise. Q: How are returns handled? A: The integration treats returns as an inbound flow into Peoplevox with a reason code and inspection state. Where you also run a returns platform (ReturnGO, Returnless, or similar), the three-way flow runs in the same Patchworks integration as the outbound fulfilment. Q: Do you support Shopify-to-Peoplevox under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Brightpearl URL: https://www.ecirql.com/integrations/shopify-to-brightpearl/ Lead: Brightpearl is a retail operations platform that does a lot in one place: orders, inventory, purchasing, accounting and CRM. Sitting it behind Shopify means deciding which side of that combined surface owns each piece of data, and enforcing that decision in every flow. We design, build and support Shopify-to-Brightpearl integrations as a certified Patchworks Partner Agency. Orders, customers, inventory, pricing, fulfilments and credit notes flow as one coherent estate rather than a stack of point-to-point connections. Patchworks angle: Brightpearl has a clear opinion about how retail operations should run, and integrations that respect that opinion are the ones that stay clean. We build the Shopify-to-Brightpearl flows in Patchworks with explicit handling for Brightpearl's order lifecycle, pick-and-pack model, and accounting treatment. Inventory rules per warehouse, automatic SKU routing, and the events that Brightpearl emits on shipment all flow back into Shopify so the storefront reads the same state operations and finance do. Capabilities (7): - Order sync (Shopify -> Brightpearl): Orders raised in Shopify flow into Brightpearl on creation, status change and edit. The flow normalises Shopify's order schema into the record shape Brightpearl expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Brightpearl stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (Brightpearl -> Shopify): Stock levels in Brightpearl push to Shopify on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where Shopify has its own location model we map Brightpearl's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with Brightpearl retaining authority. - Product sync (Brightpearl -> Shopify): Product master data syncs from Brightpearl to Shopify on publish, with channel-aware enrichment so Shopify only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Shopify has channel-specific requirements that Brightpearl does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (Brightpearl -> Shopify): Price lists in Brightpearl push to Shopify with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where Brightpearl runs effective-dated pricing, the flow coordinates the cutover so Shopify's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Customer sync (Shopify -> Brightpearl): Customers created or updated in Shopify flow into Brightpearl with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Brightpearl's defaults. Where Brightpearl is the customer system of record (CRM or ERP) we publish back into Shopify so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Returns sync (Shopify -> Brightpearl): Return authorisations created in Shopify flow into Brightpearl with reason codes, inspection state, restocking decisions and refund eligibility carried through. Where Brightpearl is the ERP or WMS, the return becomes an inbound record that affects available stock and accounts. Where Brightpearl is the storefront, the order record updates so the customer-facing return state stays honest. Exchanges are handled as a paired return-plus-outbound rather than collapsed into a refund-plus-new-order, which keeps the accounting clean and the operational picture accurate. - Refund sync (Shopify -> Brightpearl): Refund decisions raised in Shopify push into Brightpearl as the financial event they are, with original payment method, partial-versus-full handling, tax recalculation and currency intact. The flow waits on inspection outcome where the merchant policy requires it rather than firing on RMA creation. Refunds against gift cards, multi-tender orders and marketplace orders (where the marketplace owns the refund execution) each take a different path; the integration picks the right one based on the original order's tender mix rather than a single default rule. Timeline: 5 to 8 weeks for a standard delivery - Week 1: Discovery: Brightpearl account setup, warehouse map, accounting period rules, fulfilment workflow. - Weeks 2 to 4: Build: order, customer, inventory, fulfilment and credit-note flows in Patchworks. - Weeks 5 to 6: Integration testing against the Brightpearl sandbox using staged Shopify orders. - Week 7: UAT with operations and finance; sign-off on edge cases and accounting mappings. - Week 8: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: Can Brightpearl own inventory while Shopify shows availability? A: Yes. Brightpearl is typically the source of truth for stock, with channel-aware availability publishing to Shopify on a delta cadence plus event-driven updates on movement. Safety stock buffers are configurable per SKU group and per warehouse. Q: How are Brightpearl's automation rules respected? A: We build the integration around Brightpearl's automation rather than fighting it. Order status transitions, allocation rules and accounting period locks are treated as authoritative; the Patchworks flows trigger and respect Brightpearl's lifecycle rather than bypassing it. Q: What about Shopify subscriptions and pre-orders? A: Supported. Subscription rebills post as discrete orders with the subscription metadata mapped onto Brightpearl custom fields. Pre-orders carry a flag so allocation waits for available stock; the order stays open in Brightpearl rather than being auto-cancelled. Q: Can we use Brightpearl's POS alongside the Shopify integration? A: Yes. The integration is scoped around the Shopify channel; Brightpearl POS sales sit alongside it in Brightpearl as their own channel and the inventory model accounts for both. Where you also use Shopify POS we model that as a third channel. Q: Do you support Shopify-to-Brightpearl under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Microsoft Dynamics Business Central URL: https://www.ecirql.com/integrations/shopify-to-microsoft-dynamics-business-central/ Lead: Microsoft Dynamics 365 Business Central is where mid-market operations and finance live in a lot of UK and EU retailers. Shopify is increasingly what sits in front of it. The integration carries orders into Business Central as proper sales documents with the right dimensions, posts customer and item data the right direction, and lifts inventory and pricing back out so the storefront stays honest. We design, build and support the integration as a Patchworks Partner Agency, with the SLA picking up from go-live. Patchworks angle: Business Central rewards integrations that respect its document model: orders are sales orders, not generic transactions. We build the Shopify-to-Business-Central flows in Patchworks mapping orders onto the right document types, posting groups and dimensions, with explicit handling for the VAT and currency rules Business Central enforces at posting. Item ledger entries, item availability and unit-of-measure conversions all flow back into Shopify in the same Patchworks integration. Capabilities (8): - Order sync (Shopify -> Microsoft Dynamics Business Central): Orders raised in Shopify flow into Microsoft Dynamics Business Central on creation, status change and edit. The flow normalises Shopify's order schema into the record shape Microsoft Dynamics Business Central expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Microsoft Dynamics Business Central stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (Microsoft Dynamics Business Central -> Shopify): Stock levels in Microsoft Dynamics Business Central push to Shopify on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where Shopify has its own location model we map Microsoft Dynamics Business Central's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with Microsoft Dynamics Business Central retaining authority. - Product sync (Microsoft Dynamics Business Central -> Shopify): Product master data syncs from Microsoft Dynamics Business Central to Shopify on publish, with channel-aware enrichment so Shopify only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Shopify has channel-specific requirements that Microsoft Dynamics Business Central does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (Microsoft Dynamics Business Central -> Shopify): Price lists in Microsoft Dynamics Business Central push to Shopify with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where Microsoft Dynamics Business Central runs effective-dated pricing, the flow coordinates the cutover so Shopify's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Customer sync (Shopify -> Microsoft Dynamics Business Central): Customers created or updated in Shopify flow into Microsoft Dynamics Business Central with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Microsoft Dynamics Business Central's defaults. Where Microsoft Dynamics Business Central is the customer system of record (CRM or ERP) we publish back into Shopify so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Returns sync (Shopify -> Microsoft Dynamics Business Central): Return authorisations created in Shopify flow into Microsoft Dynamics Business Central with reason codes, inspection state, restocking decisions and refund eligibility carried through. Where Microsoft Dynamics Business Central is the ERP or WMS, the return becomes an inbound record that affects available stock and accounts. Where Microsoft Dynamics Business Central is the storefront, the order record updates so the customer-facing return state stays honest. Exchanges are handled as a paired return-plus-outbound rather than collapsed into a refund-plus-new-order, which keeps the accounting clean and the operational picture accurate. - Refund sync (Shopify -> Microsoft Dynamics Business Central): Refund decisions raised in Shopify push into Microsoft Dynamics Business Central as the financial event they are, with original payment method, partial-versus-full handling, tax recalculation and currency intact. The flow waits on inspection outcome where the merchant policy requires it rather than firing on RMA creation. Refunds against gift cards, multi-tender orders and marketplace orders (where the marketplace owns the refund execution) each take a different path; the integration picks the right one based on the original order's tender mix rather than a single default rule. - Tax sync (Microsoft Dynamics Business Central -> Shopify): Tax codes, tax classes and jurisdiction rules in Microsoft Dynamics Business Central push to Shopify so the storefront or marketplace charges what finance will actually post. VAT groups, reverse-charge B2B handling, marketplace-of-record tax (where the channel collects on the seller's behalf) and US sales-tax nexus are each modelled explicitly. The integration validates that Shopify's tax calculation matches Microsoft Dynamics Business Central's before publishing a price; mismatches are flagged loudly rather than left to surface at month-end on a VAT return. Timeline: 6 to 9 weeks for a standard delivery - Week 1: Discovery: BC tenant setup, posting groups, dimensions, VAT scheme, location codes. - Weeks 2 to 4: Build: order, customer, inventory, pricing and credit-note flows in Patchworks. - Weeks 5 to 6: Integration testing against a BC sandbox using staged Shopify orders. - Weeks 7 to 8: UAT with finance and operations; sign-off on dimension and posting-group mappings. - Week 9: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: Does the integration work with Business Central SaaS or on-premise? A: Both. The Patchworks connector talks to Business Central SaaS via OData and web services; on-premise deployments are reachable via the same APIs through a published web service tier. The flow logic is the same. Q: How are BC dimensions handled? A: Dimensions are first-class. Channel, location, salesperson, project and any custom dimension you use get mapped explicitly during scoping. The integration enforces them at the boundary rather than relying on BC posting defaults. Q: What about multi-company Business Central? A: Supported. Where you run multiple BC companies for separate legal entities or currencies, each maps to its own integration target. Orders route to the right company based on the storefront, market or channel attribute. Q: Can BC inventory drive Shopify availability across locations? A: Yes. BC location-level inventory publishes to Shopify with channel-aware availability rules. Safety stock buffers and in-transit handling are configurable per item or item category. Q: Do you support Shopify-to-Business-Central under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## BigCommerce to NetSuite URL: https://www.ecirql.com/integrations/bigcommerce-to-netsuite/ Lead: BigCommerce is a strong SaaS storefront with a clean API surface and real B2B credentials. NetSuite is where the rest of the business lives: stock, finance, customers, fulfilment. The integration moves orders and customers into NetSuite as the system of record, lifts inventory and pricing back to BigCommerce, and reconciles the rest as one coherent estate. We design, build and support the integration as a certified Patchworks Partner Agency, with monitoring and SLA in place from cutover. Patchworks angle: BigCommerce's APIs are well-shaped for integration, but the work still lives in respecting NetSuite's record-type model on the other side. We build the BigCommerce-to-NetSuite flows in Patchworks: order ingest with channel and subsidiary routing, customer and item creation, fulfilment writeback for the operations team, and explicit handling of BigCommerce price lists where B2B customer-specific pricing is in play. Patchworks Blueprints get the canonical patterns shipped; bespoke work covers the rest. Capabilities (7): - Order sync (BigCommerce -> NetSuite): Orders raised in BigCommerce flow into NetSuite on creation, status change and edit. The flow normalises BigCommerce's order schema into the record shape NetSuite expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so NetSuite stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (NetSuite -> BigCommerce): Stock levels in NetSuite push to BigCommerce on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where BigCommerce has its own location model we map NetSuite's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with NetSuite retaining authority. - Product sync (NetSuite -> BigCommerce): Product master data syncs from NetSuite to BigCommerce on publish, with channel-aware enrichment so BigCommerce only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where BigCommerce has channel-specific requirements that NetSuite does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (NetSuite -> BigCommerce): Price lists in NetSuite push to BigCommerce with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where NetSuite runs effective-dated pricing, the flow coordinates the cutover so BigCommerce's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Customer sync (BigCommerce -> NetSuite): Customers created or updated in BigCommerce flow into NetSuite with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to NetSuite's defaults. Where NetSuite is the customer system of record (CRM or ERP) we publish back into BigCommerce so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Refund sync (NetSuite -> BigCommerce): Refund decisions raised in NetSuite push into BigCommerce as the financial event they are, with original payment method, partial-versus-full handling, tax recalculation and currency intact. The flow waits on inspection outcome where the merchant policy requires it rather than firing on RMA creation. Refunds against gift cards, multi-tender orders and marketplace orders (where the marketplace owns the refund execution) each take a different path; the integration picks the right one based on the original order's tender mix rather than a single default rule. - Tax sync (NetSuite -> BigCommerce): Tax codes, tax classes and jurisdiction rules in NetSuite push to BigCommerce so the storefront or marketplace charges what finance will actually post. VAT groups, reverse-charge B2B handling, marketplace-of-record tax (where the channel collects on the seller's behalf) and US sales-tax nexus are each modelled explicitly. The integration validates that BigCommerce's tax calculation matches NetSuite's before publishing a price; mismatches are flagged loudly rather than left to surface at month-end on a VAT return. Timeline: 6 to 9 weeks for a standard delivery - Week 1: Discovery: NetSuite record types, BigCommerce API scope, B2B pricing model, channel mapping. - Weeks 2 to 4: Build: order, customer, inventory, pricing and fulfilment flows in Patchworks. - Weeks 5 to 6: Integration testing against the NetSuite sandbox and a staged BigCommerce store. - Weeks 7 to 8: UAT with operations and finance; sign-off on B2B pricing and channel edge cases. - Week 9: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: How does the integration handle BigCommerce B2B customer pricing? A: Customer-specific price lists in BigCommerce can be sourced from NetSuite (typical for B2B-led operations) or maintained natively in BigCommerce. We agree the source of truth at scoping and build the integration around that, not the other way around. Q: Can the integration support BigCommerce multi-storefront? A: Yes. Each storefront maps to its own NetSuite channel and, where appropriate, its own subsidiary. Inventory and pricing publish per storefront so customers in different markets see what's right for them. Q: What about BigCommerce checkout customisations? A: Custom checkout fields and order metadata land on the BigCommerce order payload and map into NetSuite custom transaction fields. We define the mapping at scoping so the finance and operations teams both know what's where. Q: Do you support BigCommerce B2B (formerly B2B Edition)? A: Yes. Company hierarchies, account managers and buyer roles map onto NetSuite customer hierarchies and contacts. Quote-to-order workflows can be modelled where the engagement needs them. Q: Do you support BigCommerce-to-NetSuite under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Magento to NetSuite URL: https://www.ecirql.com/integrations/magento-to-netsuite/ Lead: Magento (Adobe Commerce) is a serious enterprise storefront with a lot of moving parts: stores, websites, customer groups, attribute sets. Connecting it to NetSuite without breaking the catalogue or the accounting takes care. We design, build and support the Magento-to-NetSuite integration as a Patchworks Partner Agency, moving orders and customers into NetSuite as the system of record and lifting inventory, pricing, tax and fulfilment back into Magento as one connected estate. Patchworks angle: Magento's website / store / view hierarchy doesn't map one-to-one onto NetSuite's subsidiary / channel model, and integrations that skip that translation tend to ship correctly only for the first merchant they're built for. We build the Magento-to-NetSuite flows in Patchworks with explicit mapping between Magento store views and NetSuite channels, attribute sets and item records, and customer groups and price lists. The runbook covers the edge cases each merchant's catalogue surfaces. Capabilities (7): - Order sync (Magento -> NetSuite): Orders raised in Magento flow into NetSuite on creation, status change and edit. The flow normalises Magento's order schema into the record shape NetSuite expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so NetSuite stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (NetSuite -> Magento): Stock levels in NetSuite push to Magento on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where Magento has its own location model we map NetSuite's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with NetSuite retaining authority. - Product sync (NetSuite -> Magento): Product master data syncs from NetSuite to Magento on publish, with channel-aware enrichment so Magento only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Magento has channel-specific requirements that NetSuite does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (NetSuite -> Magento): Price lists in NetSuite push to Magento with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where NetSuite runs effective-dated pricing, the flow coordinates the cutover so Magento's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Customer sync (Magento -> NetSuite): Customers created or updated in Magento flow into NetSuite with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to NetSuite's defaults. Where NetSuite is the customer system of record (CRM or ERP) we publish back into Magento so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Refund sync (NetSuite -> Magento): Refund decisions raised in NetSuite push into Magento as the financial event they are, with original payment method, partial-versus-full handling, tax recalculation and currency intact. The flow waits on inspection outcome where the merchant policy requires it rather than firing on RMA creation. Refunds against gift cards, multi-tender orders and marketplace orders (where the marketplace owns the refund execution) each take a different path; the integration picks the right one based on the original order's tender mix rather than a single default rule. - Tax sync (NetSuite -> Magento): Tax codes, tax classes and jurisdiction rules in NetSuite push to Magento so the storefront or marketplace charges what finance will actually post. VAT groups, reverse-charge B2B handling, marketplace-of-record tax (where the channel collects on the seller's behalf) and US sales-tax nexus are each modelled explicitly. The integration validates that Magento's tax calculation matches NetSuite's before publishing a price; mismatches are flagged loudly rather than left to surface at month-end on a VAT return. Timeline: 8 to 12 weeks for a standard delivery - Weeks 1 to 2: Discovery: Magento store hierarchy, attribute sets, customer groups, NetSuite record-type mapping. - Weeks 3 to 6: Build: order, customer, inventory, pricing, tax and fulfilment flows in Patchworks. - Weeks 7 to 8: Integration testing against NetSuite sandbox and a staged Magento store. - Weeks 9 to 10: UAT with operations and finance; sign-off on configurable products and customer-group edge cases. - Weeks 11 to 12: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: Does the integration support Magento configurable and bundle products? A: Yes. Configurable products are expanded into their underlying simple SKUs on the way into NetSuite so item ledger and inventory stay accurate. Bundle pricing is preserved at the order level for revenue recognition. Q: How are Magento store views mapped to NetSuite? A: Each store view maps explicitly to a NetSuite channel (and subsidiary, where OneWorld is in play). We agree the mapping during scoping rather than relying on defaults, so multi-market operations land in the right place from day one. Q: Can customer-group pricing be driven from NetSuite? A: Yes. NetSuite can be the source of truth for customer-group pricing, with the integration publishing into Magento price-list structures. The inverse pattern (Magento-native pricing) is also supported where it fits the operation. Q: What about Magento B2B features? A: Company accounts, requisition lists, quotes and shared catalogues are supported. Where you use Adobe Commerce B2B features they map onto NetSuite customer hierarchies and contact records via the same flows that handle B2C orders. Q: Do you support Magento-to-NetSuite under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Magento to Sage 200 URL: https://www.ecirql.com/integrations/magento-to-sage-200/ Lead: Magento (Adobe Commerce) and Sage 200 is one of the most common UK ecommerce-to-ERP patterns: serious storefront in front, British accounting and stock control behind. The integration carries orders, customers and credit decisions out of Magento into Sage 200 as proper sales documents, and lifts stock and pricing back the other way so the storefront reflects warehouse reality. We design, build and support the integration as a certified Patchworks Partner Agency. Patchworks angle: Sage 200's data model rewards integrations that respect its accounting conventions, and Magento's catalogue model needs explicit translation onto Sage's stock item and nominal structure. We build the Magento-to-Sage 200 flows in Patchworks with VAT groups, nominal codes and customer ledger entries handled at the boundary, plus explicit handling for Magento's configurable products and store views. Sage's batch posting cadence drives the rhythm where finance needs it to. Capabilities (6): - Order sync (Magento -> Sage 200): Orders raised in Magento flow into Sage 200 on creation, status change and edit. The flow normalises Magento's order schema into the record shape Sage 200 expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Sage 200 stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (Sage 200 -> Magento): Stock levels in Sage 200 push to Magento on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where Magento has its own location model we map Sage 200's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with Sage 200 retaining authority. - Product sync (Sage 200 -> Magento): Product master data syncs from Sage 200 to Magento on publish, with channel-aware enrichment so Magento only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Magento has channel-specific requirements that Sage 200 does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (Sage 200 -> Magento): Price lists in Sage 200 push to Magento with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where Sage 200 runs effective-dated pricing, the flow coordinates the cutover so Magento's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Customer sync (Magento -> Sage 200): Customers created or updated in Magento flow into Sage 200 with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Sage 200's defaults. Where Sage 200 is the customer system of record (CRM or ERP) we publish back into Magento so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Tax sync (Sage 200 -> Magento): Tax codes, tax classes and jurisdiction rules in Sage 200 push to Magento so the storefront or marketplace charges what finance will actually post. VAT groups, reverse-charge B2B handling, marketplace-of-record tax (where the channel collects on the seller's behalf) and US sales-tax nexus are each modelled explicitly. The integration validates that Magento's tax calculation matches Sage 200's before publishing a price; mismatches are flagged loudly rather than left to surface at month-end on a VAT return. Timeline: 7 to 10 weeks for a standard delivery - Weeks 1 to 2: Discovery: Magento catalogue, Sage 200 chart of accounts, VAT scheme, nominal posting rules. - Weeks 3 to 5: Build: order, customer, stock and pricing flows in Patchworks. - Weeks 6 to 7: Integration testing against the live Sage instance using a staged Magento store. - Weeks 8 to 9: UAT with finance and operations; sign-off on VAT and nominal mappings. - Week 10: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: Does the integration work with Sage 200 on-premise or only Sage 200 Cloud? A: Both. The Patchworks connector supports Sage 200 Standard (cloud-hosted) and Sage 200 Professional (on-premise or partner-hosted). The flow logic is the same; the access path differs. Q: How are Magento configurable products posted to Sage? A: Configurable products are expanded into their underlying SKUs at the integration boundary so Sage's stock and nominal ledger see real SKUs rather than parent placeholders. Order lines keep the parent reference for reporting. Q: Can Sage 200 stock drive Magento availability? A: Yes. Sage is typically the source of truth for stock, with location-aware availability rules publishing to Magento on a fast cadence plus event-driven updates on warehouse movement. Safety stock buffers are configurable per SKU group. Q: What about Magento multi-store and multi-website? A: Supported. Each store or website maps explicitly to a Sage 200 source, with the right nominal posting rules per channel. Multi-currency orders post in the order currency with FX policy applied at the configured rate. Q: Do you support Magento-to-Sage 200 under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## NetSuite to Mirakl URL: https://www.ecirql.com/integrations/netsuite-to-mirakl/ Lead: Mirakl powers a large share of the marketplaces UK and EU retailers sell into, and a growing share of the marketplaces they operate themselves. Connecting NetSuite to Mirakl carries the listings, the inventory, the orders and the settlements as one connected flow, so finance and operations see Mirakl revenue land in the right places without the reconciliation tax. We design, build and support the integration as a certified Patchworks Partner Agency. Patchworks angle: Mirakl's operator API is consistent, but every marketplace running on it has its own category taxonomy, attribute requirements and service-level rules. We build the NetSuite-to-Mirakl flows in Patchworks with marketplace-specific category mapping and attribute enforcement at the boundary, plus settlement reconciliation that matches each line in the Mirakl report against a NetSuite transaction. The result is a multi-marketplace operation that doesn't drown finance at period close. Capabilities (5): - Order sync (Mirakl -> NetSuite): Orders raised in Mirakl flow into NetSuite on creation, status change and edit. The flow normalises Mirakl's order schema into the record shape NetSuite expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so NetSuite stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (NetSuite -> Mirakl): Stock levels in NetSuite push to Mirakl on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where Mirakl has its own location model we map NetSuite's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with NetSuite retaining authority. - Product sync (NetSuite -> Mirakl): Product master data syncs from NetSuite to Mirakl on publish, with channel-aware enrichment so Mirakl only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Mirakl has channel-specific requirements that NetSuite does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (NetSuite -> Mirakl): Price lists in NetSuite push to Mirakl with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where NetSuite runs effective-dated pricing, the flow coordinates the cutover so Mirakl's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Settlement reconciliation (Mirakl -> NetSuite): Marketplace settlement reports from Mirakl reconcile against the order, refund and fee records on the NetSuite side. Each line in the settlement is matched to the underlying transaction or surfaced as an unmatched item for finance review; nothing is silently dropped. Marketplace-specific concepts (chargebacks, A-to-Z claims, FBA reimbursements, listing fees, referral fees) get their own GL account mapping rather than being lumped into a single 'marketplace fees' bucket. Period close becomes tractable instead of a week of spreadsheet detective work. Timeline: 5 to 8 weeks for a standard delivery - Week 1: Discovery: marketplace scope, category mapping, attribute requirements, SLA tier per operator. - Weeks 2 to 4: Build: listing, inventory, order, fulfilment and settlement flows in Patchworks. - Weeks 5 to 6: Integration testing against the Mirakl sandbox per operator, including settlement reconciliation. - Week 7: UAT with operations and finance; sign-off on SLA handling and commission reporting. - Week 8: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: Can the integration handle multiple Mirakl operators? A: Yes. Each operator maps to its own NetSuite channel and, where required, its own subsidiary. Listings, inventory and orders are scoped per operator, with shared product master data where it makes sense. Q: How does settlement and commission reporting work? A: Mirakl settlement reports import line by line. Commission, refunds, adjustments and fees each get their own GL mapping. Each line matches to the underlying NetSuite transaction or surfaces as an unmatched item for finance review. Q: What about Mirakl's strict dispatch SLAs? A: Fulfilment writeback is engineered around the operator's SLA. Carrier, service level and tracking number arrive on the same dispatch event so the SLA clock stops cleanly. Late shipments are flagged via monitoring before the operator does. Q: How are category-specific attributes handled? A: Each operator's category attributes are enforced at the integration boundary using a per-operator schema. Where the merchant's NetSuite item data is missing a required attribute, the listing flow blocks rather than publishing a non-compliant SKU. Q: Do you support NetSuite-to-Mirakl under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to ReturnGO URL: https://www.ecirql.com/integrations/shopify-to-returngo/ Lead: ReturnGO runs the customer-facing returns experience for a lot of Shopify merchants, but the experience only works if the rest of the stack hears about returns as first-class events. We integrate Shopify and ReturnGO so order context flows the right way, returns and refunds flow back into Shopify and downstream systems as they happen, and the customer-facing return state reflects what the warehouse and finance teams know. Built and supported as a certified Patchworks Partner Agency. Patchworks angle: ReturnGO has good webhooks, but the work is in making sure each return event lands in the right place across the rest of the estate. We build the Shopify-to-ReturnGO flows in Patchworks with paired return-and-refund handling, restocking signals to the warehouse, and explicit treatment of exchanges so they don't collapse into refund-plus-new-order. Where the merchant also runs an ERP or WMS, the same Patchworks integration carries the events to those systems. Capabilities (4): - Order sync (Shopify -> ReturnGO): Orders raised in Shopify flow into ReturnGO on creation, status change and edit. The flow normalises Shopify's order schema into the record shape ReturnGO expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so ReturnGO stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Customer sync (Shopify -> ReturnGO): Customers created or updated in Shopify flow into ReturnGO with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to ReturnGO's defaults. Where ReturnGO is the customer system of record (CRM or ERP) we publish back into Shopify so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Returns sync (ReturnGO -> Shopify): Return authorisations created in ReturnGO flow into Shopify with reason codes, inspection state, restocking decisions and refund eligibility carried through. Where Shopify is the ERP or WMS, the return becomes an inbound record that affects available stock and accounts. Where Shopify is the storefront, the order record updates so the customer-facing return state stays honest. Exchanges are handled as a paired return-plus-outbound rather than collapsed into a refund-plus-new-order, which keeps the accounting clean and the operational picture accurate. - Refund sync (ReturnGO -> Shopify): Refund decisions raised in ReturnGO push into Shopify as the financial event they are, with original payment method, partial-versus-full handling, tax recalculation and currency intact. The flow waits on inspection outcome where the merchant policy requires it rather than firing on RMA creation. Refunds against gift cards, multi-tender orders and marketplace orders (where the marketplace owns the refund execution) each take a different path; the integration picks the right one based on the original order's tender mix rather than a single default rule. Timeline: 3 to 5 weeks for a standard delivery - Week 1: Discovery: returns policy, RMA workflow, refund tender rules, exchange handling, warehouse signals. - Weeks 2 to 3: Build: order, customer, returns and refund flows in Patchworks. - Week 4: Integration testing using staged Shopify orders and ReturnGO sandbox; UAT on edge cases. - Week 5: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: How are exchanges handled? A: As a paired return-and-outbound pattern rather than a refund-plus-new-order. The original return advances cleanly, the replacement order carries the exchange reference, and accounting sees both halves of the transaction. Q: Can ReturnGO trigger restocking signals to the warehouse? A: Yes. Where you run a WMS (Peoplevox, Veeqo, ShipBob and others), the same Patchworks integration routes ReturnGO inspection outcomes to the warehouse so restockable items move back to sellable stock without manual intervention. Q: Does the integration support partial refunds? A: Yes. Line-level partial refunds, restocking fees and gift-card-tendered refunds all map onto Shopify refund records in the right shape. The original payment method drives the refund destination by default; merchant rules can override. Q: What about refunds against marketplace orders sold via Shopify? A: Where the marketplace owns refund execution (Amazon, eBay), the integration coordinates the request rather than executing it directly. The status in Shopify and ReturnGO advances when the marketplace confirms. Q: Do you support Shopify-to-ReturnGO under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Akeneo to Shopify URL: https://www.ecirql.com/integrations/akeneo-to-shopify/ Lead: Akeneo is the most-deployed open-source PIM in UK retail, and Shopify is increasingly what sits at the channel end of the product data pipeline. The integration carries enriched, locale-aware product data out of Akeneo and into Shopify as channel-ready listings, with variants, media, metafields and category mappings handled explicitly. We design, build and support Akeneo-to-Shopify publication as a certified Patchworks Partner Agency. Patchworks angle: The work on a PIM-to-storefront integration is in respecting Akeneo's channel and locale model and translating it onto Shopify's product, variant and metafield surface. We build the Akeneo-to-Shopify flows in Patchworks with channel-aware publication, locale-specific copy and pricing, attribute enrichment and a publication gate so the merchandising team controls when a product goes live. New launches and routine updates use the same flow. Capabilities (2): - Product sync (Akeneo -> Shopify): Product master data syncs from Akeneo to Shopify on publish, with channel-aware enrichment so Shopify only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Shopify has channel-specific requirements that Akeneo does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Product syndication (Akeneo -> Shopify): Channel-ready product feeds from Akeneo push to Shopify respecting each channel's category taxonomy, required attributes, image requirements and compliance fields (origin country, hazmat flags, age restrictions). Locale-specific copy and pricing variants are sent through together so the channel listing is shippable on arrival rather than needing manual cleanup. New product launches and re-launches use the same flow as routine updates, with a publication-state field gating visibility until the merchandising team explicitly green-lights the listing. Timeline: 5 to 8 weeks for a standard delivery - Week 1: Discovery: Akeneo channel + locale setup, Shopify metafield architecture, media handling rules. - Weeks 2 to 4: Build: product, variant, media and metafield publication flows in Patchworks. - Weeks 5 to 6: Integration testing against the Shopify store with a representative product set. - Week 7: UAT with merchandising team; sign-off on attribute mapping and locale handling. - Week 8: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: How are Shopify metafields modelled in Akeneo? A: Each Shopify metafield maps to an Akeneo attribute with the right type and scope (per channel, per locale). The mapping is configured during scoping so merchandising sees Akeneo as the source of truth without needing to learn Shopify's metafield UI. Q: Does the integration support Shopify Markets and locale-specific copy? A: Yes. Akeneo locales publish to the corresponding Shopify market or locale, including translated copy, market-specific pricing where Akeneo owns pricing, and locale-specific media variants. Q: How are product variants handled? A: Akeneo's variant axes (size, colour and any custom dimension) map onto Shopify product options. New variants flow through automatically; deprecated variants are flagged rather than hard-deleted so historical orders stay intact. Q: Can merchandising control when a product goes live? A: Yes. The integration uses Akeneo's publication state as the gate. A product only reaches Shopify when merchandising explicitly publishes it on the relevant channel; status changes propagate immediately. Q: Do you support Akeneo-to-Shopify under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Akeneo to Mirakl URL: https://www.ecirql.com/integrations/akeneo-to-mirakl/ Lead: Marketplace listings are unforgiving: a missing required attribute, an oversized image or the wrong category mapping and the listing either fails or sells incorrectly. Akeneo holds the enriched product data; Mirakl wants it shaped its own way per operator. The integration syndicates Akeneo product data to one or many Mirakl marketplaces with category mapping, attribute enforcement and publication control in place from the first feed. Built and supported as a certified Patchworks Partner Agency. Patchworks angle: Each Mirakl operator runs its own category taxonomy and required-attribute schema, and product-syndication integrations that don't respect that need rework every time the merchant opens a new marketplace. We build the Akeneo-to-Mirakl flows in Patchworks with a per-operator category map, attribute enforcement at the boundary, and a publication state that merchandising controls. New marketplaces are configuration rather than rebuild. Capabilities (2): - Product sync (Akeneo -> Mirakl): Product master data syncs from Akeneo to Mirakl on publish, with channel-aware enrichment so Mirakl only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Mirakl has channel-specific requirements that Akeneo does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Product syndication (Akeneo -> Mirakl): Channel-ready product feeds from Akeneo push to Mirakl respecting each channel's category taxonomy, required attributes, image requirements and compliance fields (origin country, hazmat flags, age restrictions). Locale-specific copy and pricing variants are sent through together so the channel listing is shippable on arrival rather than needing manual cleanup. New product launches and re-launches use the same flow as routine updates, with a publication-state field gating visibility until the merchandising team explicitly green-lights the listing. Timeline: 5 to 8 weeks for a standard delivery (first operator) - Week 1: Discovery: target operators, category mapping, required-attribute schema per operator. - Weeks 2 to 4: Build: product, attribute, media, offer and listing-state flows in Patchworks. - Weeks 5 to 6: Integration testing against the operator sandbox with a representative product set. - Week 7: UAT with merchandising; sign-off on category mapping and compliance gating. - Week 8: Cutover and hyper-care; subsequent operators are configuration, not rebuild. FAQs: Q: How does the integration handle multiple Mirakl operators? A: Each operator has its own category map and attribute schema. Adding a new operator after the first one is configuration rather than a fresh build, because the underlying flows are designed around the operator boundary from the start. Q: What happens when a SKU is missing a required attribute? A: The flow blocks at the compliance gate rather than publishing a non-compliant listing. Merchandising sees the missing attribute on the Akeneo side, fills it, and the listing publishes on the next cycle. Nothing reaches the marketplace half-cooked. Q: How are price and stock policies modelled? A: Per operator. Each marketplace can have its own pricing rule, stock buffer and lead-time policy without affecting the others. Where pricing is sourced from an ERP, the ERP feeds the offer-pricing layer at the integration boundary. Q: Can the integration handle media at the right dimensions per marketplace? A: Yes. Each operator's image requirements (dimensions, aspect ratio, count) are enforced at the integration boundary. Where Akeneo holds source media, the integration applies the per-operator transformation rather than asking merchandising to upload variants manually. Q: Do you support Akeneo-to-Mirakl under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Klaviyo URL: https://www.ecirql.com/integrations/shopify-to-klaviyo/ Lead: Klaviyo is the customer-data and email-marketing platform most Shopify merchants choose, and it earns the choice by being deep on ecommerce data shapes. The native Shopify connector handles the happy path; the work we get called in for is the cases it doesn't, or the cases where Klaviyo needs to coexist with other systems in the estate. We design, build and support Shopify-to-Klaviyo integrations as a certified Patchworks Partner Agency, with full support for downstream system handoffs. Patchworks angle: Klaviyo's native Shopify connector is good. Where it stops being enough is when customers and orders need to flow through Klaviyo and on into a CRM, a CDP or an ERP as part of the same event chain. We build Shopify-to-Klaviyo in Patchworks so that customer and order events route to Klaviyo with the segment-shaped data its flows need, and onward to whichever systems should also hear about them. One integration. One audit trail. Capabilities (2): - Order sync (Shopify -> Klaviyo): Orders raised in Shopify flow into Klaviyo on creation, status change and edit. The flow normalises Shopify's order schema into the record shape Klaviyo expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Klaviyo stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Customer sync (Shopify -> Klaviyo): Customers created or updated in Shopify flow into Klaviyo with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Klaviyo's defaults. Where Klaviyo is the customer system of record (CRM or ERP) we publish back into Shopify so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. Timeline: 3 to 5 weeks for a standard delivery - Week 1: Discovery: existing native connector scope, gap analysis, downstream system handoffs. - Weeks 2 to 3: Build: customer, order, refund and product flows in Patchworks. - Week 4: Integration testing against the Klaviyo sandbox using staged Shopify events. - Week 5: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: Why not just use Klaviyo's native Shopify connector? A: For many merchants it's enough. We get called in where the merchant needs the same customer and order events to flow through Klaviyo and on into other systems (CRM, ERP, CDP, marketing data warehouse) as part of one event chain, or where the native connector doesn't model a piece of data the merchant relies on. Q: Can identity be resolved across systems? A: Yes. Where the merchant runs a CRM or CDP that owns identity, we use that as the source of truth and reconcile Klaviyo profiles to it. Email plus an external ID is the typical merge key; we can add more where the data model needs it. Q: How are refunds and returns reflected in Klaviyo? A: Refund and return events post as Klaviyo metrics so flows can react (post-return surveys, win-back campaigns gated on return history). Profile properties update to reflect refunded LTV and return-rate signals. Q: Can the integration coexist with the native Klaviyo connector? A: Yes. The typical pattern is to keep the native connector for the patterns it does well and use the Patchworks flows for the events that need to fan out to other systems. We document the boundary so nothing gets double-counted. Q: Do you support Shopify-to-Klaviyo under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## SFTP Connector to NetSuite URL: https://www.ecirql.com/integrations/sftp-to-netsuite/ Lead: Not every system in a retail estate has a modern API. Legacy ERPs, in-house tools and long-running vendor systems still talk in files: a daily orders.csv on an SFTP server, a stock.txt drop at midnight, a fixed-width customer extract on the hour. We pick those files up, parse them, validate them, and synchronise the contents into NetSuite as proper records, with the same monitoring and SLA we apply to API-first integrations. Built and supported as a certified Patchworks Partner Agency. Patchworks angle: Patchworks handles file-based sources as a first-class flow shape rather than a fallback. We build the SFTP-to-NetSuite integration in Patchworks with explicit file pickup, parsing, schema validation and dead-letter handling for malformed rows. The merchant sees the same monitoring, retry behaviour and on-call cover for a CSV drop as for a webhook from Shopify. Where the legacy system can also accept files back, the same Patchworks integration can publish outbound extracts on schedule. Capabilities (5): - Order sync (SFTP Connector -> NetSuite): Orders raised in SFTP Connector flow into NetSuite on creation, status change and edit. The flow normalises SFTP Connector's order schema into the record shape NetSuite expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so NetSuite stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (SFTP Connector -> NetSuite): Stock levels in SFTP Connector push to NetSuite on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where NetSuite has its own location model we map SFTP Connector's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with SFTP Connector retaining authority. - Product sync (SFTP Connector -> NetSuite): Product master data syncs from SFTP Connector to NetSuite on publish, with channel-aware enrichment so NetSuite only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where NetSuite has channel-specific requirements that SFTP Connector does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (SFTP Connector -> NetSuite): Price lists in SFTP Connector push to NetSuite with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where SFTP Connector runs effective-dated pricing, the flow coordinates the cutover so NetSuite's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Customer sync (SFTP Connector -> NetSuite): Customers created or updated in SFTP Connector flow into NetSuite with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to NetSuite's defaults. Where NetSuite is the customer system of record (CRM or ERP) we publish back into SFTP Connector so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. Timeline: 3 to 6 weeks for a standard delivery - Week 1: Discovery: file formats, drop cadence, NetSuite record-type mapping, error-handling policy. - Weeks 2 to 3: Build: pickup, parse, validate, map, post and archive flows in Patchworks. - Weeks 4 to 5: Integration testing using real legacy file samples against the NetSuite sandbox. - Week 6: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: What file formats do you support? A: CSV, TSV, fixed-width text, pipe-delimited and most variants in between. Where the source produces an unusual flavour (mixed delimiters, embedded headers, multi-record per line), we build a custom parser at the integration boundary. XML and JSON dropped on SFTP are also handled. Q: How are malformed rows handled? A: Bad rows route to a dead-letter folder with the original line and a parse-error reason logged. Valid rows in the same file still process. Finance or operations can review the dead-letter file, fix the source data, and re-drop. Nothing silently corrupts the NetSuite side. Q: What about character encoding, line endings and BOMs? A: Handled explicitly. UTF-8 with or without BOM, Windows-1252, ISO-8859-1, mixed CRLF / LF line endings. We agree the encoding at scoping rather than guessing, and the parser fails loudly if a file arrives in an unexpected encoding rather than corrupting the data on the way in. Q: Can the integration push files back to the legacy system? A: Yes. The same Patchworks integration can publish outbound extracts from NetSuite to SFTP on schedule: stock counts, posted invoices, settlement reports, anything the legacy system needs to consume. Filename, folder, and format conventions match whatever the legacy system expects. Q: Do you support SFTP-to-NetSuite under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. File-pickup monitoring, on-call cover, monthly health checks and tiered response SLAs from £750/month. Missed file drops alert before the next batch posts late. --- ## Shopify to FreeAgent URL: https://www.ecirql.com/integrations/shopify-to-freeagent/ Lead: FreeAgent is the accounting platform a lot of UK Shopify merchants use to keep on top of VAT, MTD submissions and the year-end. The integration moves orders, customers and refunds out of Shopify and into FreeAgent as proper sales invoices and credit notes, with VAT treatment, tender and currency correct from the first run. We design, build and support Shopify-to-FreeAgent integrations as a certified Patchworks Partner Agency, so the accounting side stays in step with the storefront without manual reconciliation. Patchworks angle: FreeAgent's API is clean but opinionated about how invoices, customers and tax rates should look. The work is in shaping Shopify order events into the right FreeAgent constructs while respecting the MTD reporting rules HMRC enforces. We build the Shopify-to-FreeAgent flows in Patchworks with explicit VAT rate mapping, tender-aware refund handling and a customer-resolution step so the FreeAgent ledger doesn't fragment into duplicates over time. Capabilities (3): - Order sync (Shopify -> FreeAgent): Orders raised in Shopify flow into FreeAgent on creation, status change and edit. The flow normalises Shopify's order schema into the record shape FreeAgent expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so FreeAgent stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Customer sync (Shopify -> FreeAgent): Customers created or updated in Shopify flow into FreeAgent with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to FreeAgent's defaults. Where FreeAgent is the customer system of record (CRM or ERP) we publish back into Shopify so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Refund sync (Shopify -> FreeAgent): Refund decisions raised in Shopify push into FreeAgent as the financial event they are, with original payment method, partial-versus-full handling, tax recalculation and currency intact. The flow waits on inspection outcome where the merchant policy requires it rather than firing on RMA creation. Refunds against gift cards, multi-tender orders and marketplace orders (where the marketplace owns the refund execution) each take a different path; the integration picks the right one based on the original order's tender mix rather than a single default rule. Timeline: 3 to 5 weeks for a standard delivery - Week 1: Discovery: VAT scheme, MTD requirements, tender mapping, customer-resolution policy. - Weeks 2 to 3: Build: order, customer and refund flows in Patchworks. - Week 4: Integration testing using staged Shopify orders against a FreeAgent sandbox; UAT with finance. - Week 5: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: How is VAT handled across rates? A: Each Shopify tax line maps to a FreeAgent VAT rate explicitly: standard, reduced, zero-rated, exempt, outside the scope. We agree the mapping during scoping, so MTD submissions reflect the same VAT treatment finance expects to see on the FreeAgent VAT return. Q: What about refunds and partial refunds? A: Refunds post as credit notes in FreeAgent against the original invoice. Partial refunds map to line-level credit notes; restocking fees and gift-card refunds get the right tax treatment rather than collapsing into a single adjustment. Q: Does the integration support Shopify Markets and multi-currency? A: Yes. Orders post to FreeAgent in the order currency with FX policy applied at the configured rate. We agree the rate source during scoping so finance isn't reconciling two interpretations of exchange rates. Q: How are Shopify customers reconciled to FreeAgent contacts? A: Email plus an external identifier is the typical merge key. New customers create FreeAgent contacts on first order; existing customers reuse the same contact across all subsequent orders so the ledger stays clean. Q: Do you support Shopify-to-FreeAgent under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## NetSuite to FreeAgent URL: https://www.ecirql.com/integrations/netsuite-to-freeagent/ Lead: Some groups run NetSuite at the consolidated level but need a UK subsidiary on FreeAgent for MTD-compliant VAT submission and HMRC-friendly reporting. The integration carries sales invoices, credit notes, customer ledger entries and VAT-relevant transactions out of the NetSuite UK subsidiary and into FreeAgent on a controlled schedule, so MTD filings reflect group reality without manual export. We design, build and support this NetSuite-to-FreeAgent pattern as a certified Patchworks Partner Agency. Patchworks angle: The complexity in NetSuite-to-FreeAgent isn't volume, it's correctness. VAT codes, posting periods and subsidiary scope have to line up between the two systems with no drift, because the FreeAgent side is what HMRC sees through MTD. We build the flows in Patchworks with explicit period-aware batching, VAT rate mapping and a reconciliation receipt back into NetSuite so finance can audit the trail at month-end without rebuilding it from spreadsheets. Capabilities (2): - Credit note sync (NetSuite -> FreeAgent): Credit notes raised against returns in NetSuite post into FreeAgent as accounting documents tied to the original invoice, with VAT / sales-tax adjustment, cost-of-goods reversal and customer ledger entry handled in step. The flow batches into the period that matches the merchant's close cadence rather than firing in real time, so the finance team isn't reconciling mid-period noise. Where multi-entity or multi-currency posting is in play, the integration resolves the right subsidiary and exchange-rate policy before the credit note lands. - Tax sync (NetSuite -> FreeAgent): Tax codes, tax classes and jurisdiction rules in NetSuite push to FreeAgent so the storefront or marketplace charges what finance will actually post. VAT groups, reverse-charge B2B handling, marketplace-of-record tax (where the channel collects on the seller's behalf) and US sales-tax nexus are each modelled explicitly. The integration validates that FreeAgent's tax calculation matches NetSuite's before publishing a price; mismatches are flagged loudly rather than left to surface at month-end on a VAT return. Timeline: 5 to 8 weeks for a standard delivery - Week 1: Discovery: subsidiary scope, MTD requirements, period close cadence, VAT code mapping. - Weeks 2 to 4: Build: customer, invoice, credit-note and tax flows in Patchworks. - Weeks 5 to 6: Integration testing against a NetSuite sandbox and a FreeAgent test account, including a full VAT period cycle. - Week 7: UAT with finance; reconciliation receipt validated against a manually-prepared VAT return. - Week 8: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: Why would a NetSuite user also run FreeAgent? A: Most don't. The pattern shows up when a group runs NetSuite at the consolidated level but a UK trading entity needs MTD-compliant submission through FreeAgent. It also shows up where a small UK subsidiary was on FreeAgent before the group standardised on NetSuite and finance prefers to keep MTD filing where it was. Q: How are VAT codes reconciled between the two systems? A: Explicitly. Each NetSuite tax code maps to a FreeAgent VAT rate with documented intent. Where the source data uses a code that isn't in the mapping, the flow blocks rather than posting under an arbitrary fallback rate. Nothing silently misfiles VAT. Q: Does this support OneWorld with multiple UK entities? A: Yes. Each UK trading entity that needs its own FreeAgent account is scoped per subsidiary. The integration runs the right slice of transactions per FreeAgent target so groups operating multiple UK entities don't have to merge them at the integration boundary. Q: What if NetSuite is reopened for a prior period? A: Period-aware batching reads NetSuite's lock state and surfaces re-opened periods as a controlled exception. The integration doesn't blindly re-post; finance gets a notification and reviews before any backdated documents reach FreeAgent. Q: Do you support NetSuite-to-FreeAgent under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Period-close monitoring, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## WooCommerce to Xero URL: https://www.ecirql.com/integrations/woocommerce-to-xero/ Lead: WooCommerce powers a long tail of UK and ANZ ecommerce operations, and Xero is the accounting platform most of them run. The integration carries orders, customers and refunds out of WooCommerce and into Xero as proper sales invoices and credit notes, with VAT or GST treatment, tender and currency correct from the first run. Built and supported as a certified Patchworks Partner Agency, so the books stay in step with the storefront without manual reconciliation. Patchworks angle: Xero's invoice and contact model is opinionated, and a small Xero instance gets messy fast if the integration creates duplicate contacts or misclassifies tax. We build WooCommerce-to-Xero in Patchworks with a customer-resolution step that keeps the ledger clean, explicit tax rate mapping per jurisdiction, and tender-aware refund handling. Where the merchant uses Xero's tracking categories, those map onto WooCommerce order attributes rather than being applied at the end. Capabilities (3): - Order sync (WooCommerce -> Xero): Orders raised in WooCommerce flow into Xero on creation, status change and edit. The flow normalises WooCommerce's order schema into the record shape Xero expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Xero stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Customer sync (WooCommerce -> Xero): Customers created or updated in WooCommerce flow into Xero with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Xero's defaults. Where Xero is the customer system of record (CRM or ERP) we publish back into WooCommerce so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Refund sync (WooCommerce -> Xero): Refund decisions raised in WooCommerce push into Xero as the financial event they are, with original payment method, partial-versus-full handling, tax recalculation and currency intact. The flow waits on inspection outcome where the merchant policy requires it rather than firing on RMA creation. Refunds against gift cards, multi-tender orders and marketplace orders (where the marketplace owns the refund execution) each take a different path; the integration picks the right one based on the original order's tender mix rather than a single default rule. Timeline: 3 to 5 weeks for a standard delivery - Week 1: Discovery: Xero chart of accounts, tax rates, tracking categories, contact-resolution policy. - Weeks 2 to 3: Build: order, customer and refund flows in Patchworks. - Week 4: Integration testing using staged WooCommerce orders against a Xero demo organisation; UAT with finance. - Week 5: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: How are Xero tracking categories handled? A: Per-line tracking categories map from WooCommerce order metadata or product attributes onto the corresponding Xero category. Where the merchant uses two tracking categories (region and channel, typically), both apply at the line level so reporting works end to end. Q: Does the integration support both UK VAT and AU/NZ GST? A: Yes. Each jurisdiction's tax rates map to the corresponding Xero rate explicitly. The flow handles reverse-charge B2B, OSS where it's in scope, GST-free and zero-rated cases. We agree the mapping during scoping rather than relying on Xero's defaults. Q: How are refunds represented in Xero? A: Refunds post as credit notes against the original invoice, with the right account coding and tax rate. Partial refunds map to line-level credit notes; gift-card-tendered and store-credit refunds get appropriate treatment. Q: Can the integration coexist with Xero's native WooCommerce app? A: Yes, but we usually replace it. The native connection works for the simple case; we get called in when the merchant needs the integration to coordinate with other systems (warehouse, marketplace, returns platform) or where the merchant's WooCommerce setup has customisations the native app doesn't model. Q: Do you support WooCommerce-to-Xero under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Veeqo URL: https://www.ecirql.com/integrations/shopify-to-veeqo/ Lead: Veeqo is a multichannel-friendly inventory and shipping platform that a lot of growing UK ecommerce operations choose when they need more than Shopify's native fulfilment but less than a full WMS. The integration carries orders and customers out of Shopify into Veeqo for picking and shipping, and lifts stock, fulfilment and tracking back so the storefront reflects what the warehouse just did. Built and supported as a certified Patchworks Partner Agency. Patchworks angle: Veeqo's strength is in handling multiple channels and warehouses from one place; the integration's job is to make sure the Shopify channel is one well-modelled slice of that rather than a special case. We build the Shopify-to-Veeqo flows in Patchworks with explicit handling for split shipments, multi-warehouse routing, carrier service selection and the writeback that closes the loop back to the customer-facing surface in Shopify. Capabilities (5): - Order sync (Shopify -> Veeqo): Orders raised in Shopify flow into Veeqo on creation, status change and edit. The flow normalises Shopify's order schema into the record shape Veeqo expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Veeqo stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (Veeqo -> Shopify): Stock levels in Veeqo push to Shopify on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where Shopify has its own location model we map Veeqo's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with Veeqo retaining authority. - Fulfilment sync (Veeqo -> Shopify): Pick, pack and dispatch events from Veeqo push back into Shopify so the order record advances in step with the physical warehouse. Partial fulfilments, split shipments, backorders and substitutions are modelled rather than collapsed into a single 'shipped' state. Carrier, service level, tracking number and dispatched-at timestamp arrive on the same event so Shopify's customer comms can fire at the right moment. Where Shopify is a marketplace, the flow conforms to that marketplace's strict on-time-dispatch SLA rather than the storefront's looser conventions. - Tracking sync (Veeqo -> Shopify): Carrier tracking numbers and delivery events from Veeqo sync into Shopify so the customer-facing surface (order page, dispatch email, helpdesk ticket) reflects real delivery state rather than the warehouse's last known status. Updates flow through as events: in-transit, out-for-delivery, delivered, attempted, returned-to-sender. Shopify's notification rules fire against these events rather than against Veeqo's internal status codes, which means the customer experience stays consistent even when the carrier mix changes underneath. - Returns sync (Shopify -> Veeqo): Return authorisations created in Shopify flow into Veeqo with reason codes, inspection state, restocking decisions and refund eligibility carried through. Where Veeqo is the ERP or WMS, the return becomes an inbound record that affects available stock and accounts. Where Veeqo is the storefront, the order record updates so the customer-facing return state stays honest. Exchanges are handled as a paired return-plus-outbound rather than collapsed into a refund-plus-new-order, which keeps the accounting clean and the operational picture accurate. Timeline: 3 to 6 weeks for a standard delivery - Week 1: Discovery: Veeqo warehouse and channel setup, carrier mix, fulfilment rules, packaging hints. - Weeks 2 to 3: Build: order, fulfilment, inventory and tracking flows in Patchworks. - Weeks 4 to 5: Integration testing against the Veeqo sandbox using staged Shopify orders; UAT with the warehouse team. - Week 6: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: Can Veeqo own inventory while Shopify shows availability? A: Yes. Veeqo is typically the source of truth for sellable stock, with channel-aware availability rules publishing to Shopify on a fast cadence plus event-driven updates on warehouse movement. Safety stock buffers are configurable per SKU group and per warehouse. Q: How does the integration handle multi-warehouse? A: Each Veeqo warehouse is its own location with its own routing and availability rules. Orders route to the right warehouse based on inventory coverage, customer address, or merchant rules; split shipments across warehouses are first-class rather than a special case. Q: Can the same Veeqo instance serve multiple Shopify stores? A: Yes. Each Shopify store is a separate channel in Veeqo with its own inventory pool or shared availability, depending on merchant rules. The integration scopes per store cleanly so multi-store operations land in the right place. Q: What about Veeqo's own Amazon and eBay integrations? A: They can coexist. Where the merchant uses Veeqo's native marketplace integrations, our integration sits on the Shopify side without conflict. Where the merchant wants a single integration estate, we can run Shopify, Amazon and eBay through Patchworks instead. Q: Do you support Shopify-to-Veeqo under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Akeneo to BigCommerce URL: https://www.ecirql.com/integrations/akeneo-to-bigcommerce/ Lead: Akeneo holds the enriched product master data; BigCommerce is the storefront where shoppers see it. The integration carries channel-aware, locale-specific product data out of Akeneo into BigCommerce as channel-ready listings, with variants, media, custom fields and category mappings handled explicitly. We design, build and support Akeneo-to-BigCommerce publication as a certified Patchworks Partner Agency, so merchandising controls the storefront from the PIM rather than juggling two source-of-truth surfaces. Patchworks angle: BigCommerce's catalogue is well-shaped for integration, and Akeneo's channel and locale model is built for exactly this kind of publication. The work is in respecting both: channel-aware publication, locale-specific copy, category mapping onto BigCommerce's tree, and a publication gate so merchandising controls when each product goes live. We build the Akeneo-to-BigCommerce flows in Patchworks with new launches, routine updates and deprecation handled by the same pipeline. Capabilities (2): - Product sync (Akeneo -> BigCommerce): Product master data syncs from Akeneo to BigCommerce on publish, with channel-aware enrichment so BigCommerce only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where BigCommerce has channel-specific requirements that Akeneo does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Product syndication (Akeneo -> BigCommerce): Channel-ready product feeds from Akeneo push to BigCommerce respecting each channel's category taxonomy, required attributes, image requirements and compliance fields (origin country, hazmat flags, age restrictions). Locale-specific copy and pricing variants are sent through together so the channel listing is shippable on arrival rather than needing manual cleanup. New product launches and re-launches use the same flow as routine updates, with a publication-state field gating visibility until the merchandising team explicitly green-lights the listing. Timeline: 5 to 8 weeks for a standard delivery - Week 1: Discovery: Akeneo channel + locale setup, BigCommerce custom-field architecture, category mapping, media rules. - Weeks 2 to 4: Build: product, variant, media and custom-field publication flows in Patchworks. - Weeks 5 to 6: Integration testing against the BigCommerce store with a representative product set. - Week 7: UAT with merchandising; sign-off on attribute mapping, category alignment and locale handling. - Week 8: Cutover and hyper-care; transition into support retainer with monitoring and SLA. FAQs: Q: How are BigCommerce custom fields modelled in Akeneo? A: Each BigCommerce custom field maps to an Akeneo attribute with the right type and scope. The mapping is configured during scoping so merchandising sees Akeneo as the source of truth without learning two product surfaces. Q: Does the integration support BigCommerce multi-storefront? A: Yes. Each storefront maps to its own Akeneo channel with its own locale and currency scope, so multi-market merchants publish the right copy, pricing and product mix per storefront from one Akeneo source. Q: How are product variants handled? A: Akeneo's variant axes map onto BigCommerce product options. New variants flow through automatically; deprecated variants are flagged rather than hard-deleted so historical orders and reviews stay intact. Q: Can merchandising control when a product goes live? A: Yes. The integration uses Akeneo's publication state as the gate. A product only reaches BigCommerce when merchandising explicitly publishes it on the relevant channel; status changes propagate immediately. Q: Do you support Akeneo-to-BigCommerce under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Xero URL: https://www.ecirql.com/integrations/shopify-to-xero/ Lead: Shopify is where the orders come in. Xero is where the books balance. A well-built integration takes the daily reconciliation effort and reduces it to a check rather than a project. We move orders, refunds and payments out of Shopify into Xero as proper sales invoices and credit notes, with VAT codes mapped, Shopify Payments fees separated from gross revenue, and gateway payouts reconciled against the Xero bank feed. Built and supported as a Patchworks Partner Agency, with the same engineering team carrying the work through to ongoing retainer. Patchworks angle: Patchworks ships Blueprints for the Shopify-to-Xero canonical patterns; the work we add is everything Xero is opinionated about. VAT scheme alignment under MTD, multi-currency rounding to the contact's base currency, gift-card liability accounting and the difference between bank-fed and integration-fed reconciliation. Flows live in Patchworks, version against your release cadence, and the handover runbook is one your finance team can audit on its own. Capabilities (3): - Order sync (Shopify -> Xero): Orders raised in Shopify flow into Xero on creation, status change and edit. The flow normalises Shopify's order schema into the record shape Xero expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Xero stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Customer sync (Shopify -> Xero): Customers created or updated in Shopify flow into Xero with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Xero's defaults. Where Xero is the customer system of record (CRM or ERP) we publish back into Shopify so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Refund sync (Shopify -> Xero): Refund decisions raised in Shopify push into Xero as the financial event they are, with original payment method, partial-versus-full handling, tax recalculation and currency intact. The flow waits on inspection outcome where the merchant policy requires it rather than firing on RMA creation. Refunds against gift cards, multi-tender orders and marketplace orders (where the marketplace owns the refund execution) each take a different path; the integration picks the right one based on the original order's tender mix rather than a single default rule. Timeline: 4 to 6 weeks for a standard delivery - Week 1: Discovery: VAT scheme, chart of accounts, gateway payout cadence, multi-currency exposure. - Weeks 2 to 3: Build: orders, refunds, customers, payments, fee separation. - Week 4: Reconciliation: gateway payouts mapped onto Xero bank feed entries. - Weeks 5 to 6: UAT with finance, cutover, hyper-care into retainer. FAQs: Q: How does this handle Shopify Payments gateway fees? A: Each daily payout is split into the underlying order revenue and the Shopify Payments fee, posted to the right nominal codes. The Xero bank feed then matches the payout amount in a single click rather than line-by-line. Q: What about multi-currency orders? A: Orders post in the order currency where the Xero contact has that currency enabled; otherwise we convert to the contact's base currency using your defined rate source. FX gain or loss posts to a configured account so the trial balance stays honest. Q: Does this work under UK Making Tax Digital? A: Yes. Sales invoices carry the right VAT scheme codes (Standard, Reduced, Zero, EU postponed, Reverse charge) so Xero's MTD submission picks them up correctly. We map Shopify's tax-line variants to Xero VAT codes at scoping. Q: Do you support this combo under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Linnworks URL: https://www.ecirql.com/integrations/shopify-to-linnworks/ Lead: Shopify is one sales channel among many. Linnworks is the multichannel operations brain: stock, listings, orders, despatch, all under one roof. Connecting them properly means Shopify becomes a real input into the wider channel mix rather than an island. Orders flow in for fulfilment, inventory and pricing push back out, and the Linnworks side stays authoritative for stock across every channel. We design, build and support Shopify-to-Linnworks integrations as a Patchworks Partner Agency, with the SLA picking up the moment cutover lands. Patchworks angle: Linnworks has a built-in Shopify channel; what we add is the integration discipline that keeps multi-channel stock from drifting. Patchworks sits in front of Linnworks where the merchant needs deterministic event handling, retries, replay and an audit trail that survives a Linnworks outage. We build the canvases in Patchworks, version flows against the merchant's release process and hand over runbooks that cover the cases Linnworks logs alone won't tell you about. Timeline: 4 to 7 weeks for a standard delivery - Week 1: Discovery: channel inventory, SKU strategy, location model, despatch profile. - Weeks 2 to 4: Build: orders, inventory, products, fulfilment writeback. - Week 5: Integration testing under realistic multi-channel order volume. - Weeks 6 to 7: UAT with operations, cutover, hyper-care into retainer. FAQs: Q: We already use the Linnworks Shopify channel. Why add Patchworks? A: The Linnworks channel is fine for simple stores. Patchworks earns its place once you need event retries, replay, custom mapping rules, or visibility across more than one Shopify store. If the native channel works for you today, we'd tell you to leave it alone. Q: How does multi-location inventory work? A: Linnworks remains the source of truth for stock; we push availability into Shopify with location-aware rules so customers see accurate stock by ship-from location. Safety-stock buffers, in-transit qty and held stock are all handled at the integration boundary. Q: What if we sell on Amazon and eBay through Linnworks as well? A: Linnworks keeps doing that natively. The Patchworks integration is the Shopify side of the picture. Stock decrements from a Shopify sale propagate through Linnworks to every channel automatically. Q: Do you support this under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Magento to Brightpearl URL: https://www.ecirql.com/integrations/magento-to-brightpearl/ Lead: Magento (Adobe Commerce) is the storefront. Brightpearl is the retail operations spine: inventory, orders, purchasing, accounting, the lot. Connecting them well means Magento drives orders into Brightpearl as real sales documents, Brightpearl pushes the only authoritative stock number back, and the integration negotiates the long list of edge cases around B2B pricing, multi-warehouse routing and tax. We design, build and support Magento-to-Brightpearl integrations as a Patchworks Partner Agency, with SLA-backed support from go-live. Patchworks angle: Brightpearl has a Magento connector of its own, and for many merchants that's the right place to start. Patchworks earns its place where Magento's catalogue depth pushes the native connector against its limits: large attribute sets, configurable products with non-trivial variant trees, customer-group pricing, multi-source inventory. We build those flows in Patchworks, version them with the merchant's release cadence, and hand over runbooks that cover the cases the native connector glosses past. Capabilities (5): - Order sync (Magento -> Brightpearl): Orders raised in Magento flow into Brightpearl on creation, status change and edit. The flow normalises Magento's order schema into the record shape Brightpearl expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Brightpearl stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (Brightpearl -> Magento): Stock levels in Brightpearl push to Magento on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where Magento has its own location model we map Brightpearl's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with Brightpearl retaining authority. - Product sync (Brightpearl -> Magento): Product master data syncs from Brightpearl to Magento on publish, with channel-aware enrichment so Magento only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Magento has channel-specific requirements that Brightpearl does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (Brightpearl -> Magento): Price lists in Brightpearl push to Magento with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where Brightpearl runs effective-dated pricing, the flow coordinates the cutover so Magento's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Customer sync (Magento -> Brightpearl): Customers created or updated in Magento flow into Brightpearl with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Brightpearl's defaults. Where Brightpearl is the customer system of record (CRM or ERP) we publish back into Magento so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. Timeline: 6 to 9 weeks for a standard delivery - Week 1: Discovery: catalogue depth, customer groups, warehouse model, tax setup. - Weeks 2 to 4: Build: products, inventory, orders, customers, fulfilment writeback. - Weeks 5 to 6: Integration testing with real Magento and Brightpearl sandbox data. - Weeks 7 to 8: UAT with operations and finance; sign-off on edge cases. - Week 9: Cutover and hyper-care; transition into support retainer. FAQs: Q: Do you handle configurable products and their child SKUs? A: Yes. We map Magento's configurable + simple-product pattern onto Brightpearl's parent/variant model explicitly at scoping. The integration treats the simple-product SKU as authoritative for stock and pricing, with the configurable used for storefront display. Q: What about customer-group pricing in Magento? A: Customer groups map to Brightpearl price lists. Orders carry the right effective price for the customer at checkout, and Brightpearl posts the matching invoice without finance having to override anything. Q: How is multi-source inventory handled? A: Brightpearl is the source of truth for sellable stock. Magento Multi-Source Inventory receives availability by source so customer-facing stock reflects the warehouse split rather than a single aggregate number. Q: Do you support this under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Magento to Microsoft Dynamics Business Central URL: https://www.ecirql.com/integrations/magento-to-microsoft-dynamics-business-central/ Lead: Magento (Adobe Commerce) handles the storefront. Microsoft Dynamics 365 Business Central is the financial and operational system of record. Connecting them properly means orders flow into BC as proper sales documents, customers post against the right ledgers, and finance has a clean audit trail from checkout to general ledger. We design, build and support Magento-to-Business Central integrations as a Patchworks Partner Agency, with the same team carrying delivery into ongoing SLA cover. Patchworks angle: Business Central has its own opinions about how transactional data lands: customer card requirements, posting groups, dimension codes, VAT business and product groups. The Magento side has its own structures (EAV catalogue, customer groups, configurable products) that don't always have a one-to-one BC mapping. We build the translation in Patchworks, document the mappings explicitly and hand over runbooks the BC consultant can act on without calling us. Capabilities (6): - Order sync (Magento -> Microsoft Dynamics Business Central): Orders raised in Magento flow into Microsoft Dynamics Business Central on creation, status change and edit. The flow normalises Magento's order schema into the record shape Microsoft Dynamics Business Central expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Microsoft Dynamics Business Central stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (Microsoft Dynamics Business Central -> Magento): Stock levels in Microsoft Dynamics Business Central push to Magento on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where Magento has its own location model we map Microsoft Dynamics Business Central's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with Microsoft Dynamics Business Central retaining authority. - Product sync (Microsoft Dynamics Business Central -> Magento): Product master data syncs from Microsoft Dynamics Business Central to Magento on publish, with channel-aware enrichment so Magento only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Magento has channel-specific requirements that Microsoft Dynamics Business Central does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (Microsoft Dynamics Business Central -> Magento): Price lists in Microsoft Dynamics Business Central push to Magento with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where Microsoft Dynamics Business Central runs effective-dated pricing, the flow coordinates the cutover so Magento's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Customer sync (Magento -> Microsoft Dynamics Business Central): Customers created or updated in Magento flow into Microsoft Dynamics Business Central with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Microsoft Dynamics Business Central's defaults. Where Microsoft Dynamics Business Central is the customer system of record (CRM or ERP) we publish back into Magento so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Tax sync (Microsoft Dynamics Business Central -> Magento): Tax codes, tax classes and jurisdiction rules in Microsoft Dynamics Business Central push to Magento so the storefront or marketplace charges what finance will actually post. VAT groups, reverse-charge B2B handling, marketplace-of-record tax (where the channel collects on the seller's behalf) and US sales-tax nexus are each modelled explicitly. The integration validates that Magento's tax calculation matches Microsoft Dynamics Business Central's before publishing a price; mismatches are flagged loudly rather than left to surface at month-end on a VAT return. Timeline: 8 to 12 weeks for a standard delivery - Week 1: Discovery: chart of accounts, posting groups, dimension model, VAT setup. - Weeks 2 to 5: Build: customers, items, orders, inventory, invoices, fulfilment writeback. - Weeks 6 to 8: Integration testing against Magento and BC sandbox; finance review. - Weeks 9 to 10: UAT with finance and operations. - Weeks 11 to 12: Cutover and hyper-care into retainer. FAQs: Q: Do you handle BC dimensions on every transaction? A: Yes. Dimensions are mapped explicitly at scoping (typically channel, region, brand, where they exist) and applied to every posted line. Finance reporting works out of the box because the dimension data is right at source. Q: What about VAT business / product posting groups? A: Magento tax classes map onto BC VAT business and product posting groups. We define the matrix at scoping so VAT calculations match between the storefront and BC's tax engine without exception lists. Q: Do you handle BC's posting cadence (queued vs immediate)? A: Either pattern. The integration can post to BC immediately on order creation or batch into a posting queue your operations team controls. We pick the pattern at discovery based on how your finance side runs end-of-day. Q: Do you support this under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## WooCommerce to NetSuite URL: https://www.ecirql.com/integrations/woocommerce-to-netsuite/ Lead: WooCommerce keeps the storefront close to the team that owns the content. NetSuite runs the business: stock, finance, customers, fulfilment, the lot. Connecting them properly means orders land in NetSuite as real sales documents, customers post against the right subsidiaries, and inventory and pricing flow back so the storefront stays honest. We design, build and support WooCommerce-to-NetSuite integrations as a Patchworks Partner Agency, with the same engineering team carrying delivery into ongoing SLA cover. Patchworks angle: WooCommerce is a WordPress plugin first and an integration target second; its REST API behaviour varies with the host, the plugin stack and the storefront theme. Patchworks normalises that out so NetSuite sees a consistent shape regardless of which Woo extensions the merchant runs. We build the flows in Patchworks against canonical shapes, version them with the merchant's deployment process, and hand over runbooks that cover the cases Woo's own logs won't show. Capabilities (7): - Order sync (WooCommerce -> NetSuite): Orders raised in WooCommerce flow into NetSuite on creation, status change and edit. The flow normalises WooCommerce's order schema into the record shape NetSuite expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so NetSuite stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (NetSuite -> WooCommerce): Stock levels in NetSuite push to WooCommerce on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where WooCommerce has its own location model we map NetSuite's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with NetSuite retaining authority. - Product sync (NetSuite -> WooCommerce): Product master data syncs from NetSuite to WooCommerce on publish, with channel-aware enrichment so WooCommerce only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where WooCommerce has channel-specific requirements that NetSuite does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (NetSuite -> WooCommerce): Price lists in NetSuite push to WooCommerce with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where NetSuite runs effective-dated pricing, the flow coordinates the cutover so WooCommerce's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Customer sync (WooCommerce -> NetSuite): Customers created or updated in WooCommerce flow into NetSuite with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to NetSuite's defaults. Where NetSuite is the customer system of record (CRM or ERP) we publish back into WooCommerce so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Refund sync (NetSuite -> WooCommerce): Refund decisions raised in NetSuite push into WooCommerce as the financial event they are, with original payment method, partial-versus-full handling, tax recalculation and currency intact. The flow waits on inspection outcome where the merchant policy requires it rather than firing on RMA creation. Refunds against gift cards, multi-tender orders and marketplace orders (where the marketplace owns the refund execution) each take a different path; the integration picks the right one based on the original order's tender mix rather than a single default rule. - Tax sync (NetSuite -> WooCommerce): Tax codes, tax classes and jurisdiction rules in NetSuite push to WooCommerce so the storefront or marketplace charges what finance will actually post. VAT groups, reverse-charge B2B handling, marketplace-of-record tax (where the channel collects on the seller's behalf) and US sales-tax nexus are each modelled explicitly. The integration validates that WooCommerce's tax calculation matches NetSuite's before publishing a price; mismatches are flagged loudly rather than left to surface at month-end on a VAT return. Timeline: 6 to 10 weeks for a standard delivery - Week 1: Discovery: Woo plugin landscape, NetSuite record-type choice, edge cases. - Weeks 2 to 4: Build: orders, customers, inventory, pricing, fulfilment writeback. - Weeks 5 to 6: Integration testing against real Woo and NetSuite sandbox data. - Weeks 7 to 8: UAT with operations and finance teams. - Weeks 9 to 10: Cutover and hyper-care into retainer. FAQs: Q: We use a long stack of Woo extensions. Does that break this? A: Not if we know about them at scoping. Subscriptions, Memberships, Bookings, Product Add-Ons and the popular B2B extensions all have known landing patterns into NetSuite. We map them at discovery so the build doesn't surprise either side. Q: Do we need NetSuite OneWorld? A: No. The integration works with single-instance and OneWorld. OneWorld is required where you trade through multiple subsidiaries with separate ledgers; many UK Woo merchants run single-instance and that's the right call. Q: Can NetSuite be the source of truth for inventory? A: Yes; that's the standard pattern. NetSuite pushes availability into WooCommerce with location-aware rules. Where you need WooCommerce to retain inventory authority (rare), the inverse is also supportable. Q: Do you support this under SLA after go-live? A: Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## WooCommerce to Sage 200 URL: https://www.ecirql.com/integrations/woocommerce-to-sage-200/ Lead: WooCommerce keeps the storefront flexible. Sage 200 keeps the UK back office honest: nominal ledger, stock, purchase orders, VAT, the whole operational accounting stack. The integration moves orders and refunds out of Woo into Sage as proper sales documents, and pushes stock and pricing back the other way so the storefront reflects what's actually in the warehouse. Built and supported as a Patchworks Partner Agency, with SLA cover from go-live. Patchworks angle: Sage 200 is built around accounting conventions rather than ecommerce expectations; integrations that ignore that need rework within months. We build the WooCommerce-to-Sage 200 flows directly in Patchworks, mapping orders to the right Sage transaction types, respecting nominal codes, VAT groups and posting cadence. The runbook covers the edge cases Sage tends to flag loudest at month-end. Capabilities (7): - Order sync (WooCommerce -> Sage 200): Orders raised in WooCommerce flow into Sage 200 on creation, status change and edit. The flow normalises WooCommerce's order schema into the record shape Sage 200 expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Sage 200 stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (Sage 200 -> WooCommerce): Stock levels in Sage 200 push to WooCommerce on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where WooCommerce has its own location model we map Sage 200's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with Sage 200 retaining authority. - Product sync (Sage 200 -> WooCommerce): Product master data syncs from Sage 200 to WooCommerce on publish, with channel-aware enrichment so WooCommerce only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where WooCommerce has channel-specific requirements that Sage 200 does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (Sage 200 -> WooCommerce): Price lists in Sage 200 push to WooCommerce with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where Sage 200 runs effective-dated pricing, the flow coordinates the cutover so WooCommerce's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Customer sync (WooCommerce -> Sage 200): Customers created or updated in WooCommerce flow into Sage 200 with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Sage 200's defaults. Where Sage 200 is the customer system of record (CRM or ERP) we publish back into WooCommerce so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Refund sync (WooCommerce -> Sage 200): Refund decisions raised in WooCommerce push into Sage 200 as the financial event they are, with original payment method, partial-versus-full handling, tax recalculation and currency intact. The flow waits on inspection outcome where the merchant policy requires it rather than firing on RMA creation. Refunds against gift cards, multi-tender orders and marketplace orders (where the marketplace owns the refund execution) each take a different path; the integration picks the right one based on the original order's tender mix rather than a single default rule. - Tax sync (Sage 200 -> WooCommerce): Tax codes, tax classes and jurisdiction rules in Sage 200 push to WooCommerce so the storefront or marketplace charges what finance will actually post. VAT groups, reverse-charge B2B handling, marketplace-of-record tax (where the channel collects on the seller's behalf) and US sales-tax nexus are each modelled explicitly. The integration validates that WooCommerce's tax calculation matches Sage 200's before publishing a price; mismatches are flagged loudly rather than left to surface at month-end on a VAT return. Timeline: 5 to 8 weeks for a standard delivery - Week 1: Discovery: chart of accounts, VAT setup, posting cadence. - Weeks 2 to 4: Build: orders, customers, refunds, inventory, pricing. - Weeks 5 to 6: Integration testing with Sage period-end edge cases. - Weeks 7 to 8: UAT and cutover into retainer. FAQs: Q: Does this work with Sage 200 Standard, Professional and Online? A: Yes, against any Sage 200 that exposes its SData API or supports CSV-based posting. We confirm the interface at scoping. For Sage 200 Online (cloud) we use the standard API; on-premise versions can use SData or batch CSV depending on the customer's preference. Q: How does month-end work with the integration running? A: Sage 200 closes by period rather than by hour, and the integration respects that. Orders raised in a closed period either post to the next open period with a marker, or pause for finance review, depending on what you choose at discovery. Q: Can we keep Woo's inventory native, or must Sage drive it? A: Either pattern is supportable. For most merchants Sage owns purchasing and warehousing so it's the source of truth for stock, with availability pushing into Woo. For pure-DTC Woo merchants the inverse can be simpler. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## BigCommerce to Sage 200 URL: https://www.ecirql.com/integrations/bigcommerce-to-sage-200/ Lead: BigCommerce gives merchants a fast storefront without the maintenance tax. Sage 200 gives the UK back office a finance and operations spine that auditors recognise. Joining them properly means orders, customers and refunds flow into Sage as real sales documents, with VAT codes and nominal accounts correct; stock and pricing flow back out so the storefront reflects what's actually sellable. Built and supported as a Patchworks Partner Agency, with SLA-backed support from cutover. Patchworks angle: BigCommerce's order schema is generous; Sage's is opinionated. The translation is where pages of edge-case spreadsheets usually appear and where bad integrations age. We build the BigCommerce-to-Sage 200 flows in Patchworks, mapping orders to the correct Sage transaction type, nominal code and VAT group, respecting Sage's batch posting cadence where finance needs it to. Runbooks cover the cases Sage flags loudest at month-end. Capabilities (6): - Order sync (BigCommerce -> Sage 200): Orders raised in BigCommerce flow into Sage 200 on creation, status change and edit. The flow normalises BigCommerce's order schema into the record shape Sage 200 expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Sage 200 stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (Sage 200 -> BigCommerce): Stock levels in Sage 200 push to BigCommerce on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where BigCommerce has its own location model we map Sage 200's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with Sage 200 retaining authority. - Product sync (Sage 200 -> BigCommerce): Product master data syncs from Sage 200 to BigCommerce on publish, with channel-aware enrichment so BigCommerce only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where BigCommerce has channel-specific requirements that Sage 200 does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (Sage 200 -> BigCommerce): Price lists in Sage 200 push to BigCommerce with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where Sage 200 runs effective-dated pricing, the flow coordinates the cutover so BigCommerce's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Customer sync (BigCommerce -> Sage 200): Customers created or updated in BigCommerce flow into Sage 200 with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Sage 200's defaults. Where Sage 200 is the customer system of record (CRM or ERP) we publish back into BigCommerce so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Tax sync (Sage 200 -> BigCommerce): Tax codes, tax classes and jurisdiction rules in Sage 200 push to BigCommerce so the storefront or marketplace charges what finance will actually post. VAT groups, reverse-charge B2B handling, marketplace-of-record tax (where the channel collects on the seller's behalf) and US sales-tax nexus are each modelled explicitly. The integration validates that BigCommerce's tax calculation matches Sage 200's before publishing a price; mismatches are flagged loudly rather than left to surface at month-end on a VAT return. Timeline: 5 to 8 weeks for a standard delivery - Week 1: Discovery: chart of accounts, VAT, posting cadence, BC channel model. - Weeks 2 to 4: Build: orders, customers, refunds, inventory, pricing. - Weeks 5 to 6: Integration testing including period-end cases. - Weeks 7 to 8: UAT and cutover into retainer. FAQs: Q: Does this support BigCommerce Multi-Storefront? A: Yes. Each storefront can post into Sage against its own customer-account, nominal or analysis-code split so reporting separates the channels without manual work in finance. Q: How are BC's per-region storefronts handled for VAT? A: We map each storefront to the right Sage VAT-group setup at discovery (UK VAT, EU OSS, RoW zero-rated, etc.). Tax-line variants in BC translate to Sage VAT codes deterministically. Q: Can BC retain inventory authority, or must Sage drive it? A: Either pattern. Where Sage owns purchasing and warehousing the standard pattern is Sage-driven. For BC merchants without a fulfilment-side authority elsewhere, BC-led is also workable. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## BigCommerce to Brightpearl URL: https://www.ecirql.com/integrations/bigcommerce-to-brightpearl/ Lead: BigCommerce keeps the storefront clean. Brightpearl runs retail operations end to end: inventory, orders, purchasing, accounting. Connecting them properly means BigCommerce drives orders into Brightpearl as real sales documents, Brightpearl pushes the only authoritative stock and pricing back, and the integration handles B2B pricing, multi-warehouse routing and tax-class translation without anyone having to think about it day to day. Built and supported as a Patchworks Partner Agency. Patchworks angle: Brightpearl publishes a BigCommerce connector of its own; for many merchants that's the right place to start. Patchworks earns its place where the merchant runs multiple BC storefronts, custom price lists or non-trivial warehouse routing. We build those flows in Patchworks, version them with the merchant's release process and hand over runbooks that cover the cases the native connector silently glosses. Capabilities (5): - Order sync (BigCommerce -> Brightpearl): Orders raised in BigCommerce flow into Brightpearl on creation, status change and edit. The flow normalises BigCommerce's order schema into the record shape Brightpearl expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Brightpearl stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (Brightpearl -> BigCommerce): Stock levels in Brightpearl push to BigCommerce on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where BigCommerce has its own location model we map Brightpearl's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with Brightpearl retaining authority. - Product sync (Brightpearl -> BigCommerce): Product master data syncs from Brightpearl to BigCommerce on publish, with channel-aware enrichment so BigCommerce only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where BigCommerce has channel-specific requirements that Brightpearl does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (Brightpearl -> BigCommerce): Price lists in Brightpearl push to BigCommerce with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where Brightpearl runs effective-dated pricing, the flow coordinates the cutover so BigCommerce's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Customer sync (BigCommerce -> Brightpearl): Customers created or updated in BigCommerce flow into Brightpearl with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Brightpearl's defaults. Where Brightpearl is the customer system of record (CRM or ERP) we publish back into BigCommerce so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. Timeline: 5 to 9 weeks for a standard delivery - Week 1: Discovery: storefront model, customer groups, warehouse routing. - Weeks 2 to 4: Build: products, inventory, orders, customers, fulfilment. - Weeks 5 to 6: Integration testing with real BC and Brightpearl sandbox data. - Weeks 7 to 9: UAT, cutover, hyper-care into retainer. FAQs: Q: How do BC customer groups map to Brightpearl? A: Customer groups map to Brightpearl price lists at scoping. Orders carry the right effective price at checkout, and Brightpearl posts the matching invoice without finance having to intervene. Q: Does this handle multiple BC storefronts? A: Yes. Each storefront can post against its own customer-account, channel or analysis split inside Brightpearl, so reporting separates the channels without manual work. Q: How is multi-warehouse stock allocated? A: Brightpearl owns allocation logic; the integration just respects it. BC sees aggregate availability with optional channel-specific buffers, and allocation happens inside Brightpearl on order creation. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Mirakl URL: https://www.ecirql.com/integrations/shopify-to-mirakl/ Lead: Shopify is the brand storefront. Mirakl is the marketplace operator: either as a host (you're running a marketplace) or as a destination (you're listing into one of the big Mirakl-powered retailers). Connecting Shopify to Mirakl means catalogue, inventory and pricing publish onto the marketplace under the right operator rules, orders drop back into Shopify for fulfilment, and settlement data ties out against gross revenue. We design, build and support Shopify-to-Mirakl integrations as a Patchworks Partner Agency. Patchworks angle: Mirakl operators each run their own attribute requirements, categorisation trees and listing rules; what works for one operator rarely works unchanged for another. Patchworks Blueprints cover the canonical Mirakl shapes; we extend them per-operator at the boundary so the merchandising team isn't stuck reconciling spreadsheets. Flows live in Patchworks with full audit trail, and runbooks cover the cases Mirakl's exception reports flag at month-end. Timeline: 6 to 10 weeks for a standard delivery - Week 1: Discovery: operator(s), attribute requirements, category mapping, settlement model. - Weeks 2 to 4: Build: products, inventory, pricing, orders, fulfilment, settlement. - Weeks 5 to 6: Integration testing against operator UAT sandbox. - Weeks 7 to 8: Operator-side onboarding pass; sign-off. - Weeks 9 to 10: Cutover and hyper-care into retainer. FAQs: Q: We list on three Mirakl operators. Does that mean three integrations? A: One integration, three operator mappings. The Patchworks flows are operator-aware; adding a fourth is a configuration exercise, not a rebuild. The merchandising team manages per-operator overrides in one place rather than three. Q: How do orders from Mirakl land in Shopify? A: Mirakl orders create Shopify Draft Orders with the marketplace tag, full customer detail and item references, then convert on confirmation. Fulfilment events from Shopify push tracking back to Mirakl on the operator's expected cadence. Q: What about settlement reconciliation? A: Operator settlement reports import into a structured form so finance can reconcile gross sales, commission and fees against expected payouts. We don't store raw PDF statements; the integration pulls the structured feed where the operator exposes one. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to TikTok Shop URL: https://www.ecirql.com/integrations/shopify-to-tiktok-shop/ Lead: Shopify holds the brand catalogue. TikTok Shop is the social-first sales channel, with its own rules about listings, content tagging, creator attribution and very different ideas about latency. Connecting them properly means the catalogue publishes once and stays accurate, orders drop into Shopify for fulfilment, stock moves with the rest of the channel mix, and the TikTok-specific edge cases (content-driven creators, live shopping, commission attribution) don't bleed into the merchant's main ops. Built and supported as a Patchworks Partner Agency. Patchworks angle: TikTok Shop's API surface is younger than its merchant base. Patchworks isolates merchants from that volatility: when the API shape changes we update one connector and the merchant's canvases keep working. We build the publish and the order side independently so a TikTok-side incident doesn't block other channels, and the runbook tells the on-call engineer what to do when TikTok pushes rate-limit responses faster than the merchant can fulfil. Timeline: 5 to 8 weeks for a standard delivery - Week 1: Discovery: catalogue scope, TikTok Shop seller setup, fulfilment SLA model. - Weeks 2 to 4: Build: products, inventory, pricing, orders, fulfilment writeback. - Weeks 5 to 6: Integration testing under TikTok Shop sandbox. - Weeks 7 to 8: Cutover and hyper-care into retainer. FAQs: Q: Does this support TikTok's fulfilment-SLA penalties? A: Yes. Order events push fulfilment status back to TikTok within the operator's expected windows. The integration alerts on flows that miss the SLA before TikTok does, so the operations team can act before penalty notices land. Q: How do affiliate-creator orders post? A: Creator attribution comes through on the TikTok order payload; we surface it as Shopify order attributes so finance can split out commissioned vs direct sales, and so any downstream marketing integration sees the affiliate context. Q: Can we run TikTok Shop alongside other marketplace channels? A: Yes. The integration shares inventory and catalogue logic with any other marketplace flows we've built for you (Amazon, Mirakl, ChannelEngine etc.). Stock decrements once and propagates across every channel. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## NetSuite to TikTok Shop URL: https://www.ecirql.com/integrations/netsuite-to-tiktok-shop/ Lead: When NetSuite is the system of record and TikTok Shop is the channel, the integration runs ERP-first: NetSuite publishes the catalogue, owns inventory and pricing, and ingests orders for fulfilment. Settlement data flows back so finance can tie out TikTok payouts against gross sales, commission and fees. The trick is making TikTok's fast-moving operator rules and content-led merchandising fit a NetSuite item record. We design, build and support NetSuite-to-TikTok Shop integrations as a Patchworks Partner Agency. Patchworks angle: NetSuite item records carry far more than any channel needs; TikTok Shop expects a tight, channel-specific shape. Patchworks does the translation at the boundary: trimming the item record to what TikTok accepts, applying channel-specific pricing, image and category rules. Flows live in Patchworks, version with NetSuite's release cadence and hand over runbooks the on-call engineer can act on without phoning the integrator at midnight. Capabilities (5): - Order sync (TikTok Shop -> NetSuite): Orders raised in TikTok Shop flow into NetSuite on creation, status change and edit. The flow normalises TikTok Shop's order schema into the record shape NetSuite expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so NetSuite stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (NetSuite -> TikTok Shop): Stock levels in NetSuite push to TikTok Shop on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where TikTok Shop has its own location model we map NetSuite's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with NetSuite retaining authority. - Product sync (NetSuite -> TikTok Shop): Product master data syncs from NetSuite to TikTok Shop on publish, with channel-aware enrichment so TikTok Shop only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where TikTok Shop has channel-specific requirements that NetSuite does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Pricing sync (NetSuite -> TikTok Shop): Price lists in NetSuite push to TikTok Shop with currency, tax-class and customer-group awareness intact. Promotional pricing, contract pricing and tiered B2B pricing are handled as first-class concepts rather than overrides applied at the storefront. Where NetSuite runs effective-dated pricing, the flow coordinates the cutover so TikTok Shop's catalogue switches at the same instant as the finance side rather than drifting by hours. Currency rounding and display-tax rules are reconciled at the integration boundary to avoid the classic 1p / 1c off-by-one that haunts multi-currency rollouts. - Settlement reconciliation (TikTok Shop -> NetSuite): Marketplace settlement reports from TikTok Shop reconcile against the order, refund and fee records on the NetSuite side. Each line in the settlement is matched to the underlying transaction or surfaced as an unmatched item for finance review; nothing is silently dropped. Marketplace-specific concepts (chargebacks, A-to-Z claims, FBA reimbursements, listing fees, referral fees) get their own GL account mapping rather than being lumped into a single 'marketplace fees' bucket. Period close becomes tractable instead of a week of spreadsheet detective work. Timeline: 7 to 10 weeks for a standard delivery - Week 1: Discovery: NetSuite subsidiary model, item-record shape, TikTok seller setup. - Weeks 2 to 4: Build: products, inventory, pricing, orders, fulfilment, settlement. - Weeks 5 to 7: Integration testing against TikTok sandbox and NetSuite UAT. - Weeks 8 to 10: Cutover and hyper-care into retainer. FAQs: Q: How does NetSuite item structure translate to TikTok listings? A: Each NetSuite item maps to one TikTok Shop SKU. The integration enforces the channel-specific attribute, image and category rules at the boundary so merchandising doesn't have to maintain a parallel catalogue. Q: Do you handle TikTok's commission model? A: Yes. Settlement reports import as structured finance data; commission, fees and gross sales reconcile against the expected TikTok payout. NetSuite gets the cleaned-up posting; the raw operator data stays on the integration side. Q: What about NetSuite OneWorld subsidiaries? A: Orders post against the correct subsidiary based on the TikTok seller account and the shipping destination. We map the subsidiary routing at scoping so the right ledgers see the right transactions. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Zendesk URL: https://www.ecirql.com/integrations/shopify-to-zendesk/ Lead: Shopify holds the order, the customer and the fulfilment timeline. Zendesk holds the conversation, the macros and the agent workflow. Connecting them means every ticket lands with the order context already in view: status, tracking, refund history, lifetime value, last contact. Macro actions can trigger Shopify-side events without the agent switching tools. We design, build and support Shopify-to-Zendesk integrations as a Patchworks Partner Agency, with SLA-backed support from cutover. Patchworks angle: Zendesk has off-the-shelf Shopify apps; for many merchants those are the right starting point. Patchworks earns its place when the support team needs more than the app exposes: data from a second Shopify store, the ERP, the WMS or the returns platform alongside the order. We build the context flows in Patchworks, surface the result as a custom Zendesk sidebar app, and version both together. Capabilities (2): - Customer sync (Shopify -> Zendesk): Customers created or updated in Shopify flow into Zendesk with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Zendesk's defaults. Where Zendesk is the customer system of record (CRM or ERP) we publish back into Shopify so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Helpdesk context (Shopify -> Zendesk): Order, fulfilment and customer context from Shopify surfaces inside Zendesk so agents answer tickets without context-switching into a second console. The integration pushes the data agents actually use (order status, tracking, return state, lifetime value, last contact) into the ticket view, and writes ticket outcomes back where they affect downstream systems (a refund agreed in the helpdesk should land in Shopify as a real event, not a Slack message). Macro actions in Zendesk can trigger flows on the Shopify side rather than asking the agent to log into a second tool. Timeline: 4 to 6 weeks for a standard delivery - Week 1: Discovery: agent workflow, macro inventory, what context the team actually uses. - Weeks 2 to 3: Build: context flow, custom Zendesk sidebar, macro actions. - Week 4: Integration testing with the support team. - Weeks 5 to 6: UAT, cutover, hyper-care into retainer. FAQs: Q: Why not just use the official Zendesk Shopify app? A: If the official app does the job, you don't need us. We get the call when the support team needs context from more than one Shopify store, from the ERP or WMS, or from your returns platform alongside the order. That's where a custom integration earns its place. Q: Can macro actions in Zendesk trigger Shopify-side events? A: Yes. Common patterns: 'refund this order,' 'resend tracking,' 'flag as a customer-care recovery.' The macro fires a Patchworks event which executes the Shopify-side action and writes the outcome back as a private ticket comment. Q: What about data privacy? A: Customer data only flows on ticket events and only the fields the support team actually uses. We don't replicate the whole customer table into Zendesk; the agent sees fresh data pulled on demand. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Gorgias URL: https://www.ecirql.com/integrations/shopify-to-gorgias/ Lead: Gorgias is the ecommerce-native helpdesk: tickets are built around Shopify customers, orders and refunds from day one. Most merchants start with the native Shopify connector and never need more. The Patchworks integration enters the picture when the support team needs context the native connector doesn't carry: data from the ERP, WMS, returns platform or a second Shopify store, all surfaced inside the Gorgias ticket. Built and supported as a Patchworks Partner Agency. Patchworks angle: Gorgias has a strong native Shopify connector. If your support stack is single-store and single-system, you don't need us. We build Gorgias integrations where the support team needs context beyond Shopify alone: order status from NetSuite, fulfilment from the WMS, return state from ReturnGO, all surfaced in the Gorgias ticket via Patchworks. Flows live in Patchworks; runbooks cover what happens when one of the upstream systems is having a bad day. Capabilities (2): - Customer sync (Shopify -> Gorgias): Customers created or updated in Shopify flow into Gorgias with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Gorgias's defaults. Where Gorgias is the customer system of record (CRM or ERP) we publish back into Shopify so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Helpdesk context (Shopify -> Gorgias): Order, fulfilment and customer context from Shopify surfaces inside Gorgias so agents answer tickets without context-switching into a second console. The integration pushes the data agents actually use (order status, tracking, return state, lifetime value, last contact) into the ticket view, and writes ticket outcomes back where they affect downstream systems (a refund agreed in the helpdesk should land in Shopify as a real event, not a Slack message). Macro actions in Gorgias can trigger flows on the Shopify side rather than asking the agent to log into a second tool. Timeline: 3 to 5 weeks for a standard delivery - Week 1: Discovery: agent workflow, which upstream systems are needed, macro inventory. - Weeks 2 to 3: Build: context flow, custom Gorgias widget, macro actions. - Weeks 4 to 5: UAT with support team, cutover, hyper-care into retainer. FAQs: Q: Why not just use the Gorgias native Shopify connector? A: If the native connector does the job, use it. We get the call when the support team needs context that the connector doesn't carry: ERP order status, WMS dispatch info, returns state, data from a second Shopify store. Q: Can macros in Gorgias trigger upstream actions? A: Yes. The macro fires a Patchworks event which runs the action against the right system (refund in Shopify, reship request to the WMS, returns label creation) and writes the outcome back to the Gorgias ticket. Q: What if one of the upstream systems is down? A: The Gorgias sidebar gracefully degrades. The agent sees what's available and the missing system is flagged with a retry option; the rest of the ticket workflow keeps working. The runbook covers per-system outage patterns. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Mailchimp URL: https://www.ecirql.com/integrations/shopify-to-mailchimp/ Lead: Shopify generates customer records and order history. Mailchimp turns them into segmented campaigns. Native connectors handle the easy cases; the Patchworks integration enters where merchants need real control over segment logic, suppression rules and what flows when. Customers, orders and product context move into Mailchimp on a predictable cadence with consent state respected end to end. Built and supported as a Patchworks Partner Agency, with the SLA picking up at cutover. Patchworks angle: Mailchimp has a Shopify integration of its own and for most stores that's the right starting point. Patchworks earns its place where the merchant has multiple Shopify stores feeding one Mailchimp audience, custom segment logic the native sync can't express, or consent rules under GDPR/PECR that need an integration boundary to enforce. We build those flows in Patchworks, document the consent logic explicitly and hand over runbooks the marketing ops team can trust. Capabilities (1): - Customer sync (Shopify -> Mailchimp): Customers created or updated in Shopify flow into Mailchimp with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Mailchimp's defaults. Where Mailchimp is the customer system of record (CRM or ERP) we publish back into Shopify so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. Timeline: 3 to 5 weeks for a standard delivery - Week 1: Discovery: consent model, audience structure, segment logic, suppression rules. - Weeks 2 to 3: Build: customers, orders, products, consent gates. - Weeks 4 to 5: UAT with marketing ops, cutover, hyper-care into retainer. FAQs: Q: Why not use the native Mailchimp for Shopify app? A: If it works for you, use it. We get the call when merchants run multiple Shopify stores feeding one audience, need segment logic the native sync can't express, or need GDPR/PECR consent enforced at the integration boundary rather than per-platform. Q: How is marketing consent handled under PECR / GDPR? A: Consent state is the gating signal: customers only sync to Mailchimp when their Shopify record carries the relevant marketing opt-in. Withdrawal of consent suppresses the contact in Mailchimp on the next sync cycle. Q: Can we move from one Mailchimp account to another without re-onboarding? A: Yes. The integration treats Mailchimp as the destination, not the source; replacing the destination is a configuration change rather than a rebuild. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Emarsys URL: https://www.ecirql.com/integrations/shopify-to-emarsys/ Lead: Shopify holds the transactional truth: orders, customers, behaviour. Emarsys (SAP Emarsys Customer Engagement) is the enterprise engagement platform: lifecycle programmes, AI-driven segmentation, tactical content. Connecting them properly means real-time customer and order data feeds the engagement programmes; consent state is respected; product context lets recommendations reflect what's actually in the catalogue. We design, build and support Shopify-to-Emarsys integrations as a Patchworks Partner Agency. Patchworks angle: Emarsys's data model rewards integration discipline: clean contact schemas, structured order shapes, product feeds that arrive on cadence. Patchworks gives the merchant a controlled boundary between Shopify's flexible storefront and Emarsys's stricter expectations. Flows live in Patchworks with full audit trail, consent gates fire at the boundary, and the runbook documents every field that crosses the wire. Capabilities (2): - Order sync (Shopify -> Emarsys): Orders raised in Shopify flow into Emarsys on creation, status change and edit. The flow normalises Shopify's order schema into the record shape Emarsys expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Emarsys stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Customer sync (Shopify -> Emarsys): Customers created or updated in Shopify flow into Emarsys with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Emarsys's defaults. Where Emarsys is the customer system of record (CRM or ERP) we publish back into Shopify so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. Timeline: 6 to 10 weeks for a standard delivery - Week 1: Discovery: contact schema, sales-data fields, product catalogue feed, consent model. - Weeks 2 to 5: Build: contacts, orders, products, behavioural events, consent gates. - Weeks 6 to 7: UAT with marketing automation team. - Weeks 8 to 10: Cutover and hyper-care into retainer. FAQs: Q: Can Emarsys triggers fire from Shopify events? A: Yes. Patchworks normalises the Shopify event stream and pushes the relevant signals into Emarsys so lifecycle programmes fire on real customer behaviour rather than on a daily batch. Q: How is consent state handled across channels? A: Channel-level consent (email, SMS, push) is the gating signal; the integration honours each channel separately rather than treating consent as binary. Withdrawal suppresses the contact within minutes on the next cycle. Q: What about product feed depth? A: Emarsys's product feed accepts as much catalogue data as the merchant wants to push. We size the feed at discovery: enough to drive recommendations and content, not so much that maintenance becomes its own project. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Magento to Klaviyo URL: https://www.ecirql.com/integrations/magento-to-klaviyo/ Lead: Magento (Adobe Commerce) gives merchants control over the storefront and the catalogue. Klaviyo gives them control over the email and SMS channel. A well-built integration moves customers, orders, product context and behavioural events from Magento into Klaviyo with consent state respected end to end. Built and supported as a Patchworks Partner Agency, with the SLA picking up the moment cutover lands. Patchworks angle: Klaviyo has a native Magento integration; for most merchants that's the right starting point. Patchworks earns its place where merchants run multiple storefronts feeding one Klaviyo account, have GDPR consent rules to enforce at the integration boundary, or need segment logic that the native sync can't express. Flows live in Patchworks with full audit trail; runbooks document every field that crosses the wire. Capabilities (2): - Order sync (Magento -> Klaviyo): Orders raised in Magento flow into Klaviyo on creation, status change and edit. The flow normalises Magento's order schema into the record shape Klaviyo expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Klaviyo stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Customer sync (Magento -> Klaviyo): Customers created or updated in Magento flow into Klaviyo with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Klaviyo's defaults. Where Klaviyo is the customer system of record (CRM or ERP) we publish back into Magento so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. Timeline: 4 to 6 weeks for a standard delivery - Week 1: Discovery: storefront count, consent model, segment logic, event taxonomy. - Weeks 2 to 3: Build: customers, orders, products, events, consent gates. - Weeks 4 to 5: UAT with marketing automation team. - Week 6: Cutover and hyper-care into retainer. FAQs: Q: Why not use the native Klaviyo for Magento app? A: If it does what you need, use it. We get the call when merchants run multiple storefronts feeding one Klaviyo account, need consent enforced at the integration boundary, or want segment logic the native sync doesn't express. Q: How is consent handled? A: Channel-level consent (email and SMS separately) is the gating signal. Customers only sync when their Magento record carries the right channel-specific opt-in. Withdrawal suppresses the contact in Klaviyo on the next cycle. Q: What about events beyond order placed? A: We push the events Klaviyo's flows actually use: Started Checkout, Placed Order, Refunded Order, Fulfilled, Subscribed, Unsubscribed. Custom events for B2B-specific lifecycles are added at scoping. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Bloomreach URL: https://www.ecirql.com/integrations/shopify-to-bloomreach/ Lead: Shopify generates the transactional truth: orders, customers, products, behaviour. Bloomreach Engagement turns that into the personalisation, campaigns and AI-driven content the brand needs across its lifecycle. Connecting them properly means real-time events feed Bloomreach's segmentation and content engine, customer data lands in the expected schema, and consent state is respected end to end. Built and supported as a Patchworks Partner Agency. Patchworks angle: Bloomreach Engagement expects a structured event stream; Shopify's webhook surface is generous but doesn't natively match. Patchworks does the translation at the boundary: normalising events into the Bloomreach event taxonomy, batching where the rate-limits require, and applying consent gates that the merchant team can audit. Flows live in Patchworks; runbooks cover the cases where Bloomreach's segment recalculation lags behind real-world behaviour. Capabilities (2): - Order sync (Shopify -> Bloomreach): Orders raised in Shopify flow into Bloomreach on creation, status change and edit. The flow normalises Shopify's order schema into the record shape Bloomreach expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Bloomreach stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Customer sync (Shopify -> Bloomreach): Customers created or updated in Shopify flow into Bloomreach with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to Bloomreach's defaults. Where Bloomreach is the customer system of record (CRM or ERP) we publish back into Shopify so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. Timeline: 5 to 8 weeks for a standard delivery - Week 1: Discovery: event taxonomy, customer schema, consent model, catalogue feed. - Weeks 2 to 4: Build: events, customer properties, catalogue feed, consent gates. - Weeks 5 to 6: UAT with marketing automation team. - Weeks 7 to 8: Cutover and hyper-care into retainer. FAQs: Q: What events do you push by default? A: The canonical lifecycle events: View Item, Add To Cart, Started Checkout, Placed Order, Refunded, Subscribed, Unsubscribed. Custom events specific to the merchant's lifecycle programmes are added at scoping. Q: How is the catalogue feed sized? A: Bloomreach accepts a full catalogue feed; we right-size at discovery so the feed carries enough to drive recommendations and content without becoming a maintenance burden of its own. Inventory updates flow on a separate, faster cadence than catalogue master data. Q: How is consent handled? A: Channel-level consent (email, SMS, push) gates the relevant event streams. Withdrawal of consent suppresses the contact's eligibility in Bloomreach within minutes. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Algolia URL: https://www.ecirql.com/integrations/shopify-to-algolia/ Lead: Shopify's native search is competent for small catalogues. Once the catalogue grows, the merchandising team needs more: synonyms, boosting rules, per-segment ranking, faceting that reflects how shoppers actually browse. Algolia gives them that. The integration moves product, variant, inventory and merchandising data from Shopify into Algolia indices on a real-time cadence so what's ranked is what's actually sellable. Built and supported as a Patchworks Partner Agency. Patchworks angle: Algolia has an official Shopify app; many merchants run on it happily. Patchworks earns its place where the merchant indexes across multiple Shopify stores, blends catalogue data from a PIM or ERP, or needs index updates to fire on inventory and price changes rather than just product edits. Flows live in Patchworks with full audit trail; runbooks cover the cases where Algolia's reindex queue lags behind merchandising changes. Timeline: 4 to 7 weeks for a standard delivery - Week 1: Discovery: index structure, faceting, ranking signals, multi-store needs. - Weeks 2 to 3: Build: catalogue feed, inventory updates, merchandising overrides. - Weeks 4 to 5: Integration testing against staging Algolia indices. - Weeks 6 to 7: Cutover and hyper-care into retainer. FAQs: Q: Why not use the official Algolia Shopify app? A: If it does what you need, use it. We get the call when merchants index across multiple Shopify stores, blend Shopify with PIM/ERP catalogue data, or need real-time inventory-aware index updates rather than scheduled reindex. Q: How do you handle out-of-stock products in the index? A: Configurable at scoping. The two common patterns are 'hide out-of-stock' (remove from index, easy) and 'show but de-rank' (keep in index with reduced ranking signals). The integration enforces whichever the merchandising team picks. Q: Can ranking respect customer segment? A: Yes. Algolia supports per-segment ranking; the integration pushes the segment signals (B2B price tier, locale, customer group) so search ranks correctly for the logged-in shopper. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Plytix to Shopify URL: https://www.ecirql.com/integrations/plytix-to-shopify/ Lead: Plytix gives lean merchandising teams a PIM that doesn't fight them. Shopify is where the storefront lives. The integration moves product master data, channel-ready variants and media from Plytix into Shopify on publish so the storefront reflects the canonical catalogue without the merchandising team copy-pasting between tools. Built and supported as a Patchworks Partner Agency, with the SLA picking up the moment cutover lands. Patchworks angle: Plytix's channel feeds are clean but generic; Shopify has specific expectations about metafields, variant structure, image sizes and publication state. Patchworks does the translation at the boundary so merchandising stays in Plytix while the storefront receives the Shopify-ready shape. Flows version in Patchworks against the merchant's release cadence and the runbook covers the cases where Shopify rejects payloads Plytix considers valid. Capabilities (2): - Product sync (Plytix -> Shopify): Product master data syncs from Plytix to Shopify on publish, with channel-aware enrichment so Shopify only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Shopify has channel-specific requirements that Plytix does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Product syndication (Plytix -> Shopify): Channel-ready product feeds from Plytix push to Shopify respecting each channel's category taxonomy, required attributes, image requirements and compliance fields (origin country, hazmat flags, age restrictions). Locale-specific copy and pricing variants are sent through together so the channel listing is shippable on arrival rather than needing manual cleanup. New product launches and re-launches use the same flow as routine updates, with a publication-state field gating visibility until the merchandising team explicitly green-lights the listing. Timeline: 4 to 6 weeks for a standard delivery - Week 1: Discovery: catalogue depth, variant model, media strategy, metafield use. - Weeks 2 to 3: Build: products, variants, media, metafields, publication gate. - Week 4: Integration testing against staging Shopify. - Weeks 5 to 6: Cutover and hyper-care into retainer. FAQs: Q: How are variants modelled? A: Plytix's variant axes map onto Shopify's three-option variant model at scoping. Where Plytix has more axes than Shopify allows, we collapse the least-significant axes into metafields and document the trade-off explicitly. Q: What about media? A: Images publish from Plytix's media library into Shopify with the right alt text, ordering and per-variant assignment. Updates flow on republish; the integration doesn't re-upload identical media on every cycle. Q: How does publication state work? A: Plytix's channel publish state is the gate. A product reaches Shopify only when merchandising explicitly publishes it on the Shopify channel; status changes propagate immediately. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Salsify to Shopify URL: https://www.ecirql.com/integrations/salsify-to-shopify/ Lead: Salsify treats commerce experience management as a discipline: structured product data, multi-channel publishing, enrichment as a first-class workflow. Shopify is one publication destination among several. The integration moves product master data, variants and channel-ready content from Salsify into Shopify on publish so the storefront receives the canonical content without merchandising duplicating work. Built and supported as a Patchworks Partner Agency. Patchworks angle: Salsify publishes via its Channel mechanism; Shopify's data model needs careful translation around variants, metafields and media. Patchworks gives the merchant a controlled boundary: Salsify owns the master data, Shopify receives the storefront-ready shape, and merchandising never edits product data in two systems. Flows version in Patchworks against the merchant's release process and the runbook covers the cases where Shopify rejects payloads Salsify considers valid. Capabilities (2): - Product sync (Salsify -> Shopify): Product master data syncs from Salsify to Shopify on publish, with channel-aware enrichment so Shopify only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Shopify has channel-specific requirements that Salsify does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Product syndication (Salsify -> Shopify): Channel-ready product feeds from Salsify push to Shopify respecting each channel's category taxonomy, required attributes, image requirements and compliance fields (origin country, hazmat flags, age restrictions). Locale-specific copy and pricing variants are sent through together so the channel listing is shippable on arrival rather than needing manual cleanup. New product launches and re-launches use the same flow as routine updates, with a publication-state field gating visibility until the merchandising team explicitly green-lights the listing. Timeline: 5 to 8 weeks for a standard delivery - Week 1: Discovery: Salsify Channel setup, variant model, metafield use, media. - Weeks 2 to 4: Build: products, variants, media, metafields, publication gate. - Week 5: Integration testing against staging Shopify. - Weeks 6 to 8: Cutover and hyper-care into retainer. FAQs: Q: How are Salsify Channels and Shopify publications related? A: Each Shopify channel (Online Store, Point of Sale, Hydrogen, etc.) can map to a Salsify Channel if needed. Most merchants publish via a single Shopify-bound Channel; we model multi-channel at scoping where it's needed. Q: What about variants and Shopify's three-option limit? A: Where Salsify carries more variant axes than Shopify's three-option model allows, we collapse the least-significant axes into metafields. We document the trade-off explicitly so merchandising knows what's going where. Q: How does this handle Salsify enrichment workflows? A: Salsify's workflow state is the gating signal. Products only publish to Shopify when the relevant readiness state is reached, so partially-enriched records don't leak onto the storefront. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Salsify to Mirakl URL: https://www.ecirql.com/integrations/salsify-to-mirakl/ Lead: Salsify holds the canonical product master data. Mirakl operators each have their own attribute requirements, category trees and listing rules. The integration moves product data from Salsify into Mirakl operators with each operator's specific rules enforced at the boundary so the merchandising team works in one system rather than reconciling spreadsheets per operator. Built and supported as a Patchworks Partner Agency. Patchworks angle: This is one of the integrations Patchworks is best suited to: many-to-many mapping between Salsify's canonical product shape and the per-operator Mirakl requirements. We build operator-aware transforms in Patchworks, each one a versioned canvas, and the merchandising team manages overrides centrally rather than operator-by-operator. Runbooks cover the cases Mirakl's exception reports surface at month-end. Capabilities (2): - Product sync (Salsify -> Mirakl): Product master data syncs from Salsify to Mirakl on publish, with channel-aware enrichment so Mirakl only receives the attributes it can act on. Variants, option sets, media, locale-specific copy, category mappings and metafield or extension data are handled explicitly. New SKUs flow in; deprecated SKUs are flagged rather than hard-deleted so historical orders stay intact. Where Mirakl has channel-specific requirements that Salsify does not natively model (typing rules, required attributes, image dimensions), the integration enforces them at the boundary rather than asking the merchandising team to. - Product syndication (Salsify -> Mirakl): Channel-ready product feeds from Salsify push to Mirakl respecting each channel's category taxonomy, required attributes, image requirements and compliance fields (origin country, hazmat flags, age restrictions). Locale-specific copy and pricing variants are sent through together so the channel listing is shippable on arrival rather than needing manual cleanup. New product launches and re-launches use the same flow as routine updates, with a publication-state field gating visibility until the merchandising team explicitly green-lights the listing. Timeline: 6 to 10 weeks for a standard delivery - Week 1: Discovery: operator landscape, attribute mapping, category trees, media. - Weeks 2 to 4: Build: per-operator transforms, validation rules, publish flows. - Weeks 5 to 7: Integration testing against operator UAT sandboxes. - Weeks 8 to 10: Cutover and hyper-care into retainer. FAQs: Q: We list on five operators. Does that mean five integrations? A: One integration, five operator transforms. The Patchworks canvases are operator-aware; adding a sixth is a configuration exercise, not a rebuild. Q: How are operator-specific category trees handled? A: Each operator's category tree maps to Salsify's master taxonomy via per-operator translation tables. Mapping changes happen in one place; downstream operators inherit the updates. Q: What about operator-specific image and content rules? A: Enforced at the integration boundary. Image dimensions, alt-text length, attribute formatting and content-tag rules are validated before publish; rejected payloads land in a queue for merchandising review rather than blocking the rest of the catalogue. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to ChannelEngine URL: https://www.ecirql.com/integrations/shopify-to-channelengine/ Lead: Shopify is the brand storefront. ChannelEngine is the marketplace aggregator: connect once and reach dozens of marketplaces from a single dashboard. Connecting Shopify to ChannelEngine means the catalogue, inventory and pricing publish onto every chosen marketplace under ChannelEngine's operator rules, orders drop back into Shopify for fulfilment, and settlement data ties out against actual gross revenue. Built and supported as a Patchworks Partner Agency, with the SLA picking up at cutover. Patchworks angle: ChannelEngine handles the per-marketplace operator complexity; Patchworks handles the Shopify side of the boundary so merchandising and operations only deal with one source of truth. The integration publishes Shopify catalogue + inventory into ChannelEngine on change, and ingests orders back as Shopify orders with channel attribution preserved. Flows live in Patchworks; runbooks cover the cases ChannelEngine surfaces when an operator changes its rules upstream. Timeline: 5 to 8 weeks for a standard delivery - Week 1: Discovery: marketplace scope, catalogue filter, fulfilment SLA model. - Weeks 2 to 4: Build: catalogue, inventory, pricing, orders, fulfilment, settlement. - Weeks 5 to 6: Integration testing against ChannelEngine sandbox. - Weeks 7 to 8: Cutover and hyper-care into retainer. FAQs: Q: How does this differ from connecting directly to Amazon or eBay? A: ChannelEngine consolidates dozens of operators behind one connector, which is the right call when you want marketplace breadth without per-operator integration work. For a single high-volume operator (Amazon US, say), a direct integration is sometimes a better fit. We help merchants pick at scoping. Q: What about per-marketplace SLA requirements? A: ChannelEngine surfaces operator-specific SLA requirements; the integration pushes fulfilment events back within the right windows. The runbook documents what to do if any operator-side SLA looks at risk. Q: Can we restrict which products publish to which operators? A: Yes. Per-marketplace catalogue filtering happens at the integration boundary; the merchandising team controls eligibility in one place rather than in ChannelEngine and Shopify separately. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to returnless URL: https://www.ecirql.com/integrations/shopify-to-returnless/ Lead: Shopify holds the order; returnless owns the returns experience: customer-facing portal, label generation, exchange offers, refund logic. Connecting them means returnless authorises returns against real Shopify orders, refunds and exchanges write back as proper Shopify events, and the operations team sees the same return state wherever they look. We design, build and support Shopify-to-returnless integrations as a Patchworks Partner Agency. Patchworks angle: returnless has a native Shopify connector and for many merchants that's the right starting point. Patchworks earns its place when the merchant runs multiple stores into one returnless tenant, needs ERP- or WMS-side awareness of the return alongside Shopify, or has bespoke rules about which orders are returnable. We build those flows in Patchworks and hand over runbooks that cover the edge cases the native connector glosses past. Capabilities (4): - Order sync (Shopify -> returnless): Orders raised in Shopify flow into returnless on creation, status change and edit. The flow normalises Shopify's order schema into the record shape returnless expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so returnless stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Customer sync (Shopify -> returnless): Customers created or updated in Shopify flow into returnless with a stable cross-system identifier so the same shopper isn't fragmented into duplicates across the estate. Addresses, marketing preferences, B2B account hierarchies, tax exemption flags and channel attribution are mapped explicitly rather than left to returnless's defaults. Where returnless is the customer system of record (CRM or ERP) we publish back into Shopify so storefront personalisation and segmentation reflect the canonical state. GDPR deletion and rectification are propagated across the integration in both directions. - Returns sync (returnless -> Shopify): Return authorisations created in returnless flow into Shopify with reason codes, inspection state, restocking decisions and refund eligibility carried through. Where Shopify is the ERP or WMS, the return becomes an inbound record that affects available stock and accounts. Where Shopify is the storefront, the order record updates so the customer-facing return state stays honest. Exchanges are handled as a paired return-plus-outbound rather than collapsed into a refund-plus-new-order, which keeps the accounting clean and the operational picture accurate. - Refund sync (returnless -> Shopify): Refund decisions raised in returnless push into Shopify as the financial event they are, with original payment method, partial-versus-full handling, tax recalculation and currency intact. The flow waits on inspection outcome where the merchant policy requires it rather than firing on RMA creation. Refunds against gift cards, multi-tender orders and marketplace orders (where the marketplace owns the refund execution) each take a different path; the integration picks the right one based on the original order's tender mix rather than a single default rule. Timeline: 3 to 5 weeks for a standard delivery - Week 1: Discovery: returns policy, RMA workflow, refund vs exchange rules. - Weeks 2 to 3: Build: returns ingestion, Shopify writeback, refund logic. - Weeks 4 to 5: UAT with operations, cutover, hyper-care into retainer. FAQs: Q: Why not use the native returnless app? A: If it does the job, use it. We get the call when merchants run multiple Shopify stores into one returnless tenant, need ERP or WMS visibility on each return alongside Shopify, or have bespoke returnable-order rules. Q: How are exchanges handled? A: Exchange flows create a structured Shopify return + a draft order for the replacement, linked together so finance can audit the trail. The customer notification flows on returnless's standard cadence. Q: Can the integration block returns against certain orders? A: Yes. Eligibility rules (final-sale items, beyond-policy-window, gift recipient rules) fire at the integration boundary so returnless's customer-facing portal reflects the merchant's actual policy. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to Shipbob URL: https://www.ecirql.com/integrations/shopify-to-shipbob/ Lead: Shopify is the storefront. ShipBob is the 3PL: warehouses around the world, two-day delivery promises, and an API surface that rewards integration discipline. Connecting them properly means orders drop into ShipBob for despatch, inventory and tracking flow back so Shopify stays honest, and the operations team sees one fulfilment picture across every region. Built and supported as a Patchworks Partner Agency. Patchworks angle: ShipBob's native Shopify integration is a fine starting point. Patchworks earns its place where the merchant runs multiple Shopify stores into one ShipBob tenant, blends ShipBob with another fulfilment provider for non-US regions, or needs ERP-side awareness of the despatch alongside Shopify. We build those flows in Patchworks; runbooks cover the cases ShipBob's exception reports flag on busy days. Capabilities (5): - Order sync (Shopify -> Shipbob): Orders raised in Shopify flow into Shipbob on creation, status change and edit. The flow normalises Shopify's order schema into the record shape Shipbob expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so Shipbob stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (Shipbob -> Shopify): Stock levels in Shipbob push to Shopify on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where Shopify has its own location model we map Shipbob's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with Shipbob retaining authority. - Fulfilment sync (Shipbob -> Shopify): Pick, pack and dispatch events from Shipbob push back into Shopify so the order record advances in step with the physical warehouse. Partial fulfilments, split shipments, backorders and substitutions are modelled rather than collapsed into a single 'shipped' state. Carrier, service level, tracking number and dispatched-at timestamp arrive on the same event so Shopify's customer comms can fire at the right moment. Where Shopify is a marketplace, the flow conforms to that marketplace's strict on-time-dispatch SLA rather than the storefront's looser conventions. - Tracking sync (Shipbob -> Shopify): Carrier tracking numbers and delivery events from Shipbob sync into Shopify so the customer-facing surface (order page, dispatch email, helpdesk ticket) reflects real delivery state rather than the warehouse's last known status. Updates flow through as events: in-transit, out-for-delivery, delivered, attempted, returned-to-sender. Shopify's notification rules fire against these events rather than against Shipbob's internal status codes, which means the customer experience stays consistent even when the carrier mix changes underneath. - Returns sync (Shopify -> Shipbob): Return authorisations created in Shopify flow into Shipbob with reason codes, inspection state, restocking decisions and refund eligibility carried through. Where Shipbob is the ERP or WMS, the return becomes an inbound record that affects available stock and accounts. Where Shipbob is the storefront, the order record updates so the customer-facing return state stays honest. Exchanges are handled as a paired return-plus-outbound rather than collapsed into a refund-plus-new-order, which keeps the accounting clean and the operational picture accurate. Timeline: 3 to 5 weeks for a standard delivery - Week 1: Discovery: ShipBob warehouse footprint, service-level mapping, exception handling. - Weeks 2 to 3: Build: orders, inventory, tracking, returns writeback. - Weeks 4 to 5: UAT, cutover, hyper-care into retainer. FAQs: Q: Why not use the native ShipBob Shopify app? A: If it does the job, use it. We get the call when merchants run multiple stores into one ShipBob tenant, blend ShipBob with another 3PL for non-US regions, or need ERP visibility on every despatch alongside Shopify. Q: How is inventory kept honest across regions? A: ShipBob is the source of truth for sellable stock at each fulfilment centre; Shopify receives location-aware availability so the storefront reflects the regional warehouse split. Safety-stock buffers configure at scoping. Q: What happens on a missed despatch? A: ShipBob's exception report imports into the runbook; the on-call engineer sees missed orders by reason code and can act before the customer-care side does. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- ## Shopify to GXO URL: https://www.ecirql.com/integrations/shopify-to-gxo/ Lead: Shopify is the storefront. GXO is enterprise-grade contract logistics: warehouses at scale, integrated with their own WMS, with the operational rhythm a large brand expects. Connecting them properly means orders flow to GXO for despatch on the right service level, inventory and tracking writebacks keep Shopify honest, and exception handling is structured rather than ad-hoc. Built and supported as a Patchworks Partner Agency. Patchworks angle: GXO integrations are project-grade: file specifications, structured EDI or API exchanges, formal UAT cycles. Patchworks gives the merchant a controlled boundary between Shopify's event stream and GXO's batch-oriented expectations. Flows live in Patchworks with full audit trail; runbooks cover what to do when a GXO batch lags or rejects, and the on-call engineer sees the picture before customer care does. Capabilities (5): - Order sync (Shopify -> GXO): Orders raised in Shopify flow into GXO on creation, status change and edit. The flow normalises Shopify's order schema into the record shape GXO expects, including line-level discounts, taxes, gift cards, shipping methods and multi-currency. Partial cancellations and post-capture edits are handled with idempotent updates so GXO stays the system of record without double-counting. Edge cases that come up most often on this pair: backorders, pre-orders, subscription rebills and orders placed through guest checkout with no matching customer record on the destination side. - Inventory sync (GXO -> Shopify): Stock levels in GXO push to Shopify on a schedule, on movement events, or both. The flow handles multi-location and multi-warehouse split, safety stock buffers, in-transit and committed quantities, and channel-specific availability rules. Where Shopify has its own location model we map GXO's locations onto it explicitly rather than relying on default behaviour. Throttling protects both sides during bulk recalculations; deltas only during normal operation. The goal is one source of truth for sellable inventory across the estate, with GXO retaining authority. - Fulfilment sync (GXO -> Shopify): Pick, pack and dispatch events from GXO push back into Shopify so the order record advances in step with the physical warehouse. Partial fulfilments, split shipments, backorders and substitutions are modelled rather than collapsed into a single 'shipped' state. Carrier, service level, tracking number and dispatched-at timestamp arrive on the same event so Shopify's customer comms can fire at the right moment. Where Shopify is a marketplace, the flow conforms to that marketplace's strict on-time-dispatch SLA rather than the storefront's looser conventions. - Tracking sync (GXO -> Shopify): Carrier tracking numbers and delivery events from GXO sync into Shopify so the customer-facing surface (order page, dispatch email, helpdesk ticket) reflects real delivery state rather than the warehouse's last known status. Updates flow through as events: in-transit, out-for-delivery, delivered, attempted, returned-to-sender. Shopify's notification rules fire against these events rather than against GXO's internal status codes, which means the customer experience stays consistent even when the carrier mix changes underneath. - Returns sync (Shopify -> GXO): Return authorisations created in Shopify flow into GXO with reason codes, inspection state, restocking decisions and refund eligibility carried through. Where GXO is the ERP or WMS, the return becomes an inbound record that affects available stock and accounts. Where GXO is the storefront, the order record updates so the customer-facing return state stays honest. Exchanges are handled as a paired return-plus-outbound rather than collapsed into a refund-plus-new-order, which keeps the accounting clean and the operational picture accurate. Timeline: 8 to 12 weeks for a standard delivery - Week 1 to 2: Discovery: GXO spec, file formats, service-level mapping, exception model. - Weeks 3 to 6: Build: orders, inventory, despatch, tracking, returns writeback. - Weeks 7 to 9: Integration testing through GXO UAT cycles. - Weeks 10 to 12: Cutover and hyper-care into retainer. FAQs: Q: Is this API-based or file-based? A: Either, depending on GXO's contract setup. We've shipped both. The integration approach is the same; only the connector at the GXO end changes. We confirm the interface at discovery. Q: How is exception handling structured? A: GXO's exception report imports into a structured queue; missed orders, address failures and stock exceptions land in the runbook by reason code so the on-call engineer can act on them before customer care does. Q: Can we run GXO alongside another fulfilment provider? A: Yes. The Patchworks routing layer decides per-order which provider handles the despatch based on rules (region, service level, SKU eligibility) you set at discovery. Common pattern: GXO for high-volume domestic, alternative provider for outliers. Q: Do you support this under SLA after go-live? A: Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month. --- # Glossary 43 terms across AI engineering, integration / iPaaS and commerce. ## Integration & iPaaS (11) ### iPaaS (also: Integration Platform as a Service) URL: https://www.ecirql.com/glossary/#ipaas A platform for building and operating integrations between business systems, usually with a visual canvas, a connector library, a scheduler, monitoring and audit. Patchworks is the iPaaS we deliver on most often. ### Process flow URL: https://www.ecirql.com/glossary/#process-flow The unit of work in Patchworks: a directed graph of steps that moves data between systems. One process flow handles one logical job (orders Shopify-to-NetSuite, inventory NetSuite-to-Shopify). An integration estate is a portfolio of process flows, not a single canvas. ### Connector URL: https://www.ecirql.com/glossary/#connector A reusable piece of integration plumbing that knows how to talk to one specific external system (Shopify, NetSuite, Amazon, etc). Provides typed inputs and outputs to process flows above it. iPaaS platforms ship a marketplace of pre-built connectors; missing ones can be authored bespoke. ### Webhook URL: https://www.ecirql.com/glossary/#webhook An HTTP callback fired by a source system when an event occurs. Push-based, low-latency, and idempotency-sensitive. Where a source supports webhooks, integrations should use them in preference to polling. ### Polling URL: https://www.ecirql.com/glossary/#polling Periodically asking a source system for changes since a known watermark. Higher latency than webhooks and heavier on the source's rate limits, but the only option where webhooks are not available or not trustworthy. ### Idempotency URL: https://www.ecirql.com/glossary/#idempotency The property that running an operation more than once has the same effect as running it once. Critical for integrations because retries, replays and double-deliveries are routine; a flow that creates a duplicate order on a retried webhook is broken even if it works on the happy path. ### Dead-letter queue (also: DLQ) URL: https://www.ecirql.com/glossary/#dead-letter A holding area for events or messages that could not be processed successfully and have exhausted their retry budget. Lets operations review and resolve failures without blocking the rest of the queue, and turns an outage into a triage exercise rather than a silent data-loss event. ### EDI (also: Electronic Data Interchange) URL: https://www.ecirql.com/glossary/#edi A family of standards (EDIFACT, X12 and others) for exchanging business documents in fixed structured formats. Common in retail, logistics and manufacturing where two trading partners need a stable wire format that survives organisational changes on both sides. ### SFTP (also: Secure File Transfer Protocol) URL: https://www.ecirql.com/glossary/#sftp File transfer over SSH. Often the integration surface for legacy systems that cannot expose a modern API but can drop a CSV or fixed-width file on a schedule. Modern iPaaS platforms treat SFTP as a first-class source. ### Patchworks Tapestry URL: https://www.ecirql.com/glossary/#patchworks-tapestry The previous-generation Patchworks integration platform. Replaced by Patchworks Core; deprecation has been signalled by Patchworks and migration to Core is the active path for existing Tapestry estates. ### Patchworks Core URL: https://www.ecirql.com/glossary/#patchworks-core Patchworks' current-generation integration platform. The destination for estates migrating off Tapestry, and the platform where new integrations on the Patchworks stack are built today. ## AI engineering (17) ### AIiPaaS (also: AI Integration Partner as a Service) URL: https://www.ecirql.com/glossary/#aiipaas AI Integration Partner as a Service. A category of AI-native integration tooling that combines a traditional iPaaS with large language model inference, retrieval-augmented generation, function calling and agentic planning. Coined by eCirql in 2026; the first product in the category is PatchBuddy. ### Inference URL: https://www.ecirql.com/glossary/#inference The act of running a trained model against an input to produce an output. In production AI, every model call is an inference and carries cost, latency and accuracy implications that have to be reasoned about per turn rather than assumed. ### Large language model (also: LLM) URL: https://www.ecirql.com/glossary/#llm A foundation model trained on a large text corpus and capable of generating text, reasoning over context, calling tools and following instructions. Frontier LLMs from providers like Anthropic, OpenAI and Google sit at one end; smaller open-weight LLMs sit at the other; production AI typically uses both, selected per task. ### Foundation model URL: https://www.ecirql.com/glossary/#foundation-model A large pre-trained model intended as the base for many downstream tasks rather than for one purpose. Frontier LLMs are foundation models; image models, speech models and multimodal models all qualify. ### Frontier model URL: https://www.ecirql.com/glossary/#frontier-model An informal term for the most capable foundation models available at any given time, typically from providers operating at the leading edge of training compute. The frontier shifts; the engineering discipline of choosing the right model for the right task does not. ### Retrieval-augmented generation (also: RAG) URL: https://www.ecirql.com/glossary/#rag A pattern that grounds an LLM in external data by retrieving relevant passages at inference time and feeding them into the prompt. Avoids the hallucination failure mode of asking the model to recall facts from its training corpus, and lets the answer reflect data that postdates the model's training cutoff. ### Vector embedding (also: embedding) URL: https://www.ecirql.com/glossary/#vector-embedding A numerical representation of a piece of content (a paragraph, an image, a code snippet) in a high-dimensional space where semantically similar content sits close together. Generated by a dedicated embedding model and stored in a vector database for similarity search. ### Vector search URL: https://www.ecirql.com/glossary/#vector-search Similarity search over vector embeddings, returning the items closest to a query vector. The retrieval half of RAG. Production setups pair vector search with a reranker model to improve precision before the top-k candidates reach the prompt. ### Function calling (also: tool use) URL: https://www.ecirql.com/glossary/#function-calling A pattern where the LLM emits a structured call to a named function with typed arguments, and the calling environment validates, executes and returns the result. The backbone of agentic systems that take real actions; without it, the model can only describe what it would do. ### Structured output URL: https://www.ecirql.com/glossary/#structured-output Constraining a model's output to a predefined schema (JSON, a typed function call, an enumerated decision). Lets downstream code handle the response without string parsing and lets the calling environment reject and repair non-conforming outputs before they reach a system. ### Agentic URL: https://www.ecirql.com/glossary/#agentic Describes AI systems that plan, take actions, observe results and adapt, rather than producing a single response and stopping. An agentic system decomposes a goal into steps, executes those steps against tools and surfaces decisions to a human at the points that need it. ### Context window URL: https://www.ecirql.com/glossary/#context-window The maximum number of tokens an LLM can consider in a single inference call. Larger context windows allow more retrieved material, longer conversation history and more code to be in scope, at the cost of higher latency and price per call. ### Token URL: https://www.ecirql.com/glossary/#token The unit of text an LLM reads and writes. Roughly four characters of English text per token in most tokenisers. Inference is priced and budgeted in tokens, so prompt engineering and retrieval design are partly about staying inside a token budget. ### Fine-tuning URL: https://www.ecirql.com/glossary/#fine-tuning Updating the weights of a pre-trained model on a smaller, task-specific dataset so it performs better on that task. Often a substitute for very large prompts; sometimes a way to teach the model a private taxonomy or tone of voice it would not otherwise know. ### Guardrails URL: https://www.ecirql.com/glossary/#guardrails Engineered constraints that sit between a model and a real-world action: input filtering, output validation, PII redaction, content classification, rate limits, audit logging. The bridge between a model that can do anything and a system that should only do specific things. ### Multimodal URL: https://www.ecirql.com/glossary/#multimodal Operating across more than one input or output modality: text, image, audio, video. Multimodal LLMs let an agent reason over a screenshot or a PDF the same way it reasons over text. ### Evaluation harness (also: evals) URL: https://www.ecirql.com/glossary/#evaluation A test suite for an AI system: a corpus of representative inputs, expected outputs (or scoring rubrics), and automated runs that score the system. The AI-engineering equivalent of regression tests; without it, model upgrades and prompt changes ship blind. ## Commerce, ERP & marketplace (15) ### ERP (also: Enterprise Resource Planning) URL: https://www.ecirql.com/glossary/#erp The system of record for a business's financial, operational and stock data. NetSuite, Microsoft Dynamics Business Central and Sage 200 are common ERPs in the merchants we work with. Integrations typically treat the ERP as the source of truth for inventory, customers and posted finance. ### WMS (also: Warehouse Management System) URL: https://www.ecirql.com/glossary/#wms The system that runs a physical warehouse: receive, putaway, pick, pack, dispatch, count. Common WMS platforms in our estate include Descartes Peoplevox, Veeqo and ShipBob. WMS-to-ERP and WMS-to-storefront integrations are some of the most common flow shapes we ship. ### 3PL (also: Third-Party Logistics) URL: https://www.ecirql.com/glossary/#3pl A logistics provider that runs fulfilment on behalf of the merchant. May operate its own WMS or use a customer-supplied one. Integrations to a 3PL look like integrations to a WMS, with stricter SLA awareness and tighter data exchange contracts. ### OMS (also: Order Management System) URL: https://www.ecirql.com/glossary/#oms A layer that orchestrates orders across multiple channels and fulfilment locations. Decides where to source stock from, when to split a shipment, when to backorder. Sits between the storefront and the ERP / WMS in operations that need this routing as a first-class concern. ### PIM (also: Product Information Management) URL: https://www.ecirql.com/glossary/#pim The system of record for product master data, attributes, locales and channel-specific enrichment. Akeneo, Salsify and Plytix are common PIM platforms. The integration job is usually to syndicate enriched data out to storefronts and marketplaces. ### DXP (also: Digital Experience Platform) URL: https://www.ecirql.com/glossary/#dxp A broader category covering CMS, personalisation, search and commerce in one platform stack. Less precise than ERP or WMS; in our work, DXP-aligned platforms get treated like a CMS plus storefront combined. ### Settlement URL: https://www.ecirql.com/glossary/#settlement The financial reconciliation report a marketplace sends after a payout period, listing every order, refund, fee, adjustment and chargeback it has applied. Reconciling settlement against the underlying ERP or accounting record is the difference between marketplace selling that is auditable and marketplace selling that is a guess. ### Marketplace URL: https://www.ecirql.com/glossary/#marketplace A third-party sales channel where the merchant lists products and the marketplace owns the customer relationship and (often) the payment. Amazon, Mirakl operators, eBay, TikTok Shop. Marketplace integrations need explicit handling of category attributes, SLA-bound dispatch and settlement reconciliation. ### FBA (also: Fulfilled by Amazon) URL: https://www.ecirql.com/glossary/#fba Amazon's fulfilment model in which the merchant ships stock to Amazon's warehouses and Amazon handles pick, pack and dispatch. FBA inventory needs to be modelled as a distinct location in the ERP, with its own availability rules and movement events. ### Marketplace of record (also: MoR) URL: https://www.ecirql.com/glossary/#marketplace-of-record A regulatory model in which the marketplace collects and remits VAT or sales tax on the seller's behalf for orders shipped to certain jurisdictions. Changes the shape of the seller's tax obligation and how marketplace orders should post to the ERP. ### NetSuite OneWorld URL: https://www.ecirql.com/glossary/#oneworld NetSuite's multi-subsidiary edition. Required when a group trades through multiple legal entities with separate ledgers and consolidated reporting. Integrations need to be subsidiary-aware: an order from a UK storefront has to post to the UK subsidiary, not the parent. ### SuiteScript URL: https://www.ecirql.com/glossary/#suitescript NetSuite's JavaScript-based customisation language. Used for bespoke logic on records, scheduled tasks, RESTlets that expose custom HTTP endpoints, and integration callbacks. Most non-trivial NetSuite integrations involve at least some SuiteScript. ### SuiteQL URL: https://www.ecirql.com/glossary/#suiteql NetSuite's SQL dialect for querying records. The escape hatch when SuiteScript record APIs are too slow or too rigid for a reporting use case, and the language finance teams actually run their dashboards in. ### B2B commerce URL: https://www.ecirql.com/glossary/#b2b Business-to-business ecommerce: customer accounts, tiered pricing, credit balances, invoice settlement, purchase-order workflows. SparkLayer B2B, Shopify B2B and BigCommerce B2B are the platforms we see most often. B2B integration is materially different from D2C and needs its own scoping. ### D2C commerce (also: DTC) URL: https://www.ecirql.com/glossary/#d2c Direct-to-consumer ecommerce: a brand selling its own products to end customers, usually through its own storefront and marketing channels. The simpler counterpart to B2B but no less rigorous on integration discipline.