Platform

Solutions

Resources

Pricing

Start Free

Integration

{ }

API on every plan

Connecting Kōbō to your ERP

Native connectors for some systems, an open API for everything else, and a straight answer about which is which.

Book a Discovery Call Start Free Trial

API / v1

GET /v1/styles

?include=components,poms

200

GET /v1/suppliers

With certifications

200

GET /v1/purchase-orders

Lines and costs

200

GET /v1/inventory

By location

200

Included, Not Extra

API access comes with every plan. Competitors routinely charge a few hundred a month for the same thing.

Three Native, Rest Open

Odoo, Shopify and Xero are built in. Everything else connects by API, middleware or a scheduled file.

We Will Tell You Which

You should hear during evaluation whether your ERP is a connector or a project, not during implementation.

The mapping

What connects, and how honestly.

Three routes, in order of how much work they take. We would rather tell you which one applies before you buy than after.

In Kōbō	How it connects	Notes
Odoo	Native connector	First-party, running in production. Styles, variants, SKUs, barcodes, suppliers, purchase orders and price lists.
Shopify	Native connector	Products, variants, barcodes, images, landed cost and stock by location.
Xero	Native connector	Purchase orders and supplier contacts.
Microsoft Dynamics 365	Open API or middleware	No native connector today. Brands reach it through the REST API directly or via middleware such as Boomi.
Sage	Open API or scheduled export	No native connector today. Style and SKU data goes across by API or a scheduled file export.
NetSuite	Open API or middleware	No native connector today. The API covers the product, supplier and purchase order data a NetSuite import needs.
SAP and in-house systems	Open API	If it can call a REST endpoint or read a file, it can be fed from Kōbō.
Anything with a Zapier app	Zapier	For lighter workflows that don't justify an integration project.

How it works

An open API, and a file for systems that prefer one.

The API is the foundation, and it's included on every plan. Not an enterprise add-on, not a per-call charge. That matters more than it sounds: competitors routinely quote several hundred dollars a month for API access, which turns a cheap-looking licence into an expensive one the moment you need your data somewhere else.

It's a versioned REST API covering roughly thirty endpoints: styles, components, suppliers and their certifications, purchase orders, inventory, customers, colours, points of measure and production batches among them. It does authentication, pagination, filtering and structured errors the way you would expect, and it supports including related records in a single request so you aren't making eighty calls to build one view.

Where a live API is more than you need, there are scheduled exports. Plenty of older ERPs would rather collect a file on a schedule than hold a conversation over HTTP, and that's a perfectly good answer.

REST, versioned

Around thirty endpoints covering styles, components, suppliers, purchase orders, inventory, customers and more.

Include related records

Pull a style with its components and points of measure in one request rather than eighty.

Or schedule a file

Plenty of older ERPs would rather collect an export on a timetable. That's a perfectly good answer.

Middleware welcome

Boomi, Patchworks and similar layers sit happily in the middle if you already run one.

Getting connected

How an ERP connection actually goes.

How an ERP connection actually goes, in the order it happens.

Draw the boundary first

Before anything technical, agree which system owns what. Product development, specs, BOMs and supplier collaboration in Kōbō. Stock, purchasing, invoicing and accounts in the ERP. Most integration pain is really an ownership argument.

Name the records that have to match

Usually style, SKU, barcode and supplier. Get the SKU pattern right in Kōbō first, because it's the key everything else joins on.

Pick the route

Native connector if one exists, REST API if your team or your middleware can call it, scheduled export if the ERP prefers files.

Start with one season, one way

Push a single season in one direction and reconcile it by hand before you automate. Two-way sync on day one is how brands end up with two wrong systems.

Hand it your API docs

Send your ERP partner the Kōbō API documentation early. Their feasibility answer usually arrives faster than anyone expects.

Good fit

For brands with an ERP that's staying put.

You already run an ERP that finance won't be replacing

You need product and SKU data to reach it without anyone hand-keying styles

You have an internal IT team, an ERP partner or middleware such as Boomi or Patchworks

You're replacing a PLM whose API didn't work, which is a more common reason for switching than most vendors admit

You would rather scope the integration honestly during evaluation than discover it later

Limits, honestly

Being straight about it.

Native means three systems today

Odoo, Shopify and Xero. Everything else is API, middleware or export. We would rather say that plainly than imply a connector exists.

An API isn't an integration

The API is the road. Somebody still has to drive it, whether that's your team, your ERP partner or a middleware platform. Budget for that.

Two-way sync needs a conversation

Most brands are better served by one-way product data out of Kōbō and stock staying in the ERP. If you genuinely need two-way, it's a scoping exercise, not a toggle.

Old ERPs have weak APIs

If your incumbent system exposes very little, the answer is usually a scheduled file rather than a live connection. That's normal, and it works.

Common questions

Before you scope an integration.

Does Kōbō integrate with my ERP?

There are native connectors for Odoo, Shopify and Xero. Everything else, including Dynamics 365, Sage, NetSuite and SAP, connects through the open REST API, through middleware such as Boomi or Patchworks, or through scheduled file exports. We will tell you which applies to your system before you buy.

Does Kōbō have an open API?

Yes, a versioned REST API covering around thirty endpoints: styles, components, suppliers, supplier certifications, purchase orders, inventory, customers, colours, points of measure and production batches. It handles authentication, pagination, filtering, structured errors and including related records in one request.

Does API access cost extra?

No. It's included on every plan. Several competitors charge a few hundred dollars a month for API access, which is worth checking when you compare headline prices.

How do I get style and SKU data from Kōbō into my ERP?

Three ways: a native connector if you run Odoo, Shopify or Xero; the REST API, called by your team or your middleware; or a scheduled export your ERP collects on a timetable. The record that matters is usually the SKU, so set your SKU pattern before the first push.

Can Kōbō connect to Microsoft Dynamics 365?

Not with a native connector today. Brands running D365 connect through the REST API directly or through middleware such as Boomi, which is a common pattern where an integration layer already exists.

Can Kōbō connect to Sage or NetSuite?

Through the API or a scheduled export rather than a native connector. The API exposes the product, supplier and purchase order data those systems need on import.

Do I need PLM and ERP, or can one do both?

Kōbō covers product development plus the operational layer many brands expect from an ERP: purchasing, inventory and wholesale. Whether that replaces your ERP depends on whether finance needs it for accounting and reporting. Growing brands often run Kōbō alone; established brands usually keep the ERP and connect to it.

Our last PLM had an API that did not really work. How is this different?

Fair question, and it's one of the most common reasons brands switch. Ask us for the documentation during evaluation and give it to whoever owns your ERP. A feasibility answer from your own technical people beats any promise we could make.