Custom CloudSuite integration development
CloudSuite is a Dutch e-commerce platform for wholesalers and brand manufacturers, built around a headless API. Appfront builds the integration between that platform and the systems where your source of truth lives: your ERP for prices and stock, your PIM for product information, and your business customers' procurement systems. That way your customer sees what is actually in stock and what they pay, rather than a catalogue price from last week's export.
What is a CloudSuite integration?
A CloudSuite integration connects your webshop to the systems around it via the platform's API. CloudSuite works API-first: the platform is designed to make its data available through a headless API, rather than keeping everything inside one closed environment. That makes integration possible, but it doesn't decide what needs integrating. That question starts with knowing which system owns what.
In B2B that's harder than in B2C. A consumer sees one price; a business customer has its own price tiers, a contract agreement or a discount per product group. That same customer wants to know whether something can still ship today, wants to order against a purchase order number its own procurement system recognises, and wants to see its order history. All of that data lives in your ERP, not in your webshop. The integration is therefore not a side issue of your e-commerce, but the place where it stands or falls.
CloudSuite itself lists proven integrations with, among others, AFAS, Exact Globe and Exact Online, Infor M3, Kerridge CS, Microsoft Dynamics 365 Business Central and Finance & Operations, Oracle NetSuite and JD Edwards, SAP S/4HANA and Business One, ASPOS by Valk Solutions, ReflexSystems and Odoo. That a route exists doesn't mean it fits your setup without work: your article structure, your discount logic and your order types are yours. That's where the custom work lies.
How we build your CloudSuite integration
We start by settling which system is the boss of what. Without that decision you end up building two sides that overwrite each other, and that isn't a technical problem but an agreement that is missing.
We map out which system holds the source of truth for each type of data: where articles live, where prices and volume discounts live, where stock lives, and where the customer contract lives. Then we establish which direction each piece of data should flow and how fresh it needs to be. Stock that is an hour old is fine for one business and a problem for another.
CloudSuite doesn't publish public developer documentation, so we work with you and your CloudSuite contact to establish what the platform actually offers in your environment: which entities, which directions, and how changes flow through. We don't promise an interface until we've seen it.
We work in sprints and start with the flow causing the most pain, usually stock and prices. Each sprint delivers something that runs in acceptance testing with real articles from your ERP, because an integration tested on invented data hides exactly the edge cases where it later breaks down.
An integration nobody can see running fails silently. We deliver monitoring, a recovery route for failed messages and a handover to your team, with an agreement on who checks when something gets stuck.
What we integrate
Six flows that come up in almost every B2B project. We determine which you need and in what order during the discovery phase.
Articles and product information
Articles from your ERP or PIM into CloudSuite, with the mapping that goes with them: your internal article numbers, variants, packaging units, and the question of which field takes precedence when both systems hold information. If you work with a separate PIM portal, that is the source and the ERP remains the source for commercial data.
Stock with an agreed freshness
Real-time lookups or periodic updates, varying by article group where that makes sense. For fast-moving items you want the current position; for a range that is ordered to order, that would be unnecessary load. We agree that freshness per group rather than applying one rule to everything.
Customer-specific prices and volume discounts
The component that typically makes B2B integrations hardest. Contract prices, quantity-based price tiers, discounts per product group and time-limited promotions. We pull that logic from your ERP rather than rebuilding it in the webshop, because a second place where prices are calculated is a second place where they can drift apart.
Orders in and status back
The order goes into your ERP as one your staff recognise, with the correct order type, reference and delivery address. Back comes what your customer wants to know: confirmed, being processed, partially delivered, dispatched with track-and-trace. Without that return route, your customer will still phone you.
OCI and PunchOut for procurement systems
Larger business customers order from their own procurement systems. With OCI or PunchOut, the buyer enters your catalogue from that system, fills their basket and returns with the lines in their own purchase requisition. CloudSuite supports this; setting it up for each customer is the work.
Monitoring and recovery
We show, per message, whether it arrived and what came back, with retries that don't create duplicate orders. We build this into the integration from the start rather than adding it later, because the first failure usually happens in the first month.
Who we build for
Four situations with a different centre of gravity. The difference lies mainly in who your customer is and how many pricing agreements sit beneath them.
Wholesalers
A broad range, customers with their own price agreements, and a warehouse where stock moves all day. Here the gain lies in prices and stock that are correct, more than in the design of the webshop.
Brand manufacturers
You sell to the trade and direct, with different prices and sometimes different ranges per channel. The integration needs to carry that distinction without you having to maintain two item files.
Multichannel retail
The shop, webshop and marketplaces draw from the same stock. The question then isn't whether you can integrate but who reserves, and what happens when two channels sell the last unit at the same time.
Dealer and customer portals
Alongside ordering, your customer wants to view invoices, contract prices and order history. That's a web application alongside the webshop, drawing from the same integration rather than from its own copy.
Technology and integrations
What we use follows from what is available on both sides. CloudSuite doesn't publish public developer documentation, so we define the interface together with you and your CloudSuite contact before we commit to anything.
Why Appfront
We build the layer in between
Your ERP remains your ERP, and CloudSuite remains your webshop. We build the middleware layer that connects them, so you are not locked into either side if something changes.
Edge cases first, not last
The integration that works in the demo is the easy half. What matters is the item without a price, the order with a delivery address the ERP doesn't recognise, and the customer who has two contracts. We surface those cases early.
Honest about what we do not yet know
CloudSuite does not publish public API documentation. We therefore make no claims about the technical approach until we have seen what your environment offers, and we would rather say so now than halfway through the project.
Customer data stays customer data
A B2B integration moves names, addresses and ordering behaviour. We keep the data flow as tight as possible and record what goes where, so your record of processing activities stays accurate.
Security and privacy
An integration between webshop and ERP moves buyer contact details, delivery addresses and order history. That's personal data, even in a business context, and the GDPR applies in full. We keep the flow as tight as possible: only the fields the receiving side actually needs, and no full customer export just because that happened to be easier.
Technically, that means encrypted traffic, keys held in a vault rather than in the code, and a separate set of permissions per direction, so that a breach on the webshop side does not immediately grant write access to your ERP. Messages are logged without their content being retained longer than necessary, with a retention period you determine yourself. How we handle security internally is set out in our information security policy; reports from outside reach us through our CVD policy.
Frequently asked questions about the CloudSuite integration
A CloudSuite integration connects the CloudSuite e-commerce platform with the systems where your data actually lives, usually your ERP and sometimes a separate PIM. Items, stock and customer-specific prices then come from the source rather than from a periodic export, and orders flow the other way into your ERP, with status information flowing back. In B2B that isn't an extra; it's the core. Without it, your customer sees catalogue prices and stock levels that aren't right.
CloudSuite itself lists proven integrations with, among others, AFAS, Exact Globe and Exact Online, Infor M3, Kerridge CS, Microsoft Dynamics 365 Business Central and Finance & Operations, Oracle NetSuite and Oracle JD Edwards, SAP S/4HANA and SAP Business One, ASPOS by Valk Solutions, ReflexSystems and Odoo. That a route exists doesn't mean it fits yours without work, as your item structure and discount logic are your own. If you run something not on that list, integration is usually still possible via the API on both sides.
That varies by data type, and we make that choice deliberately. Fast-moving stock you want as fresh as possible, because a wrongly picked order costs a customer. Item texts and images can be updated periodically. Prices fall in between: contract prices rarely change but must be correct the moment they do. We agree the update frequency per data type rather than applying one rule across the whole integration.
They are standards that allow a buyer to enter your catalogue from their own procurement system, fill their basket and return those lines to their own purchase request. You need them as soon as you supply organisations that have centralised their purchasing; they do not want to order outside their system. If you mainly supply smaller businesses who simply log in, you can happily leave this until later.
Through idempotent processing: every order gets a key that the ERP recognises, so a second submission of the same message does not produce a second order. That sounds obvious and isn't, because retries are exactly what happens during an outage. We also build a queue with visible failed messages, so retrying becomes a deliberate action taken by someone, rather than something that happens unnoticed.
That depends on the number of flows, on how your pricing logic is structured and on what interface your ERP offers. The pricing side is almost always the heaviest part and the item side the lightest. We give a reasoned estimate after the discovery phase, once we have the data flows on the table. Naming a figure before then would be guesswork.
Often, yes. We start by establishing what is running, where it goes wrong, and whether the problem lies in the integration or in the assumptions beneath it. In practice it is regularly the latter: nobody has agreed which system is the authority for a given piece of data, so both sides keep overwriting it. You won't solve that with better technology; it takes a decision.
The same approach applies there too: the integration layer is separate from the platform. We build integrations to multiple webshop platforms and to ERP packages such as King. If you are still undecided about the platform itself, our knowledge base page on ERP integrations is a good place to start.
Ready to build a CloudSuite integration?
Tell us which ERP you run and where things go wrong between your webshop and back office, and we'll help you work out the data flows, the freshness required for each type of data, and the order in which to start. We build this as a standalone integration or as part of a broader custom software or e-commerce development project.