Konimbo API: Syncing Orders, Inventory and Invoices With Your Other Systems

The Konimbo API is a REST interface at https://api.konimbo.co.il/v1 that lets another system read a store's orders, create and update products and inventory, and add statuses to orders. Every call carries a token parameter issued by the store owner. Most integrations run the same loop: a webhook announces a new order, your code fetches it, pushes it to an invoicing system, ERP or courier, and writes a status back to the order.

Konimbo is an Israeli ecommerce platform, and its documentation is published in Hebrew on GitHub. This guide is for business owners and developers planning that connection, and it focuses on the details that decide whether the integration holds up once real orders arrive.

What can you connect to Konimbo through the API?

The v1 API has separate modules for products, orders, customers, carts, an in-admin integration system and file uploads. In practice, these are the connections businesses ask for:

• Orders to invoicing - each paid order produces an invoice-receipt in Morning, iCount, Invoice4U or the accounting system.
• Orders to an ERP - Priority, SAP Business One or Hashavshevet receive the order with its SKUs.
• Inventory from the ERP - stock levels flow back into the store so it never sells what the warehouse does not have.
• Orders to a courier - a delivery is created with the customer's address and phone, and the tracking status returns to the order.
• Products from a supplier catalogue - items are created or updated by SKU in bulk.

The endpoints that matter

Times are ISO-8601 (YYYY-MM-DDTHH:MM:SSZ), request bodies are JSON, and responses are JSON by default. Lists return 20 records per page, with the totals in the X-Pagination-Total header and the page links in X-Pagination-Links.

How the order flow works, step by step

1. The store owner enables "Api" in the store's advanced settings, creates an API user under "משתמשי API" and grants it only the endpoints the integration needs.
2. You register a webhook with POST /v1/webhooks, an event of order_created and your callback_url.
3. When an order is created, Konimbo POSTs to that URL with the order id - not the full order.
4. Your code calls GET /v1/orders/{id} with an attributes list of the fields you actually need.
5. You create the document or shipment in the other system and store its id against the Konimbo order id, so a repeated webhook does not create it twice.
6. You add a status to the order with PUT /v1/orders/{id}, for example "invoice issued" with the document number in comment.
7. A scheduled job lists orders by created_at_min once an hour, to catch anything a missed webhook skipped.

Konimbo also has an integration system inside the store admin, where a script runs on a trigger URL without a server of your own. It suits a small, single-purpose connection. For anything with retries, logging and more than one destination, a small service of your own is easier to debug.

Why does the API return 401 when the token is correct?

Konimbo answers 401 Unauthorized in two different cases: an invalid token, and a token that has exceeded its rate limit. The default is 100 calls per token per 10 minutes, and the count resets every 10 minutes. An integration that treats every 401 as "the key is wrong" alerts on the wrong problem and often retries straight into a longer block.

Read the rate headers on every response: X-Rate-Limit-Current, X-Rate-Limit-Maximum and X-Rate-Limit-Reset. Before an initial import or a full inventory sync, ask the store owner to raise the API user's call and record limits - the integration documentation says to set them to the maximum while you test. A separate message, "You have reached the maximum amount of items", means the token hit its record limit and needs a higher one.

Order statuses and complex inventory: the two traps

Statuses are append-only. Through the API you add statuses to an order, up to five per call, each with status_option_title, an optional username and a comment. The order's state changes only if that exact title already exists in the admin under הזמנות > מצבי הזמנה. A title that does not exist is recorded as a note and the state stays as it was, which is useful for logging ("customer did not answer") and confusing when you expected the order to move to "shipped".

Complex inventory must exist first. A product with variants - colour, size - has an inventory array per variant SKU with code, price and free (units in stock). The docs say this field is update-only: the inventory upgrade has to be set up in the admin before the API can change it, and up to 30 variants go in one call. A simple product with one option uses the plain quantity field instead.

What goes wrong in a Konimbo integration

• Prices arrive as strings ("799.0"). Parse them as decimals, never as floats, before they reach an invoice.
• Shipping is not a line item by default. If the invoicing system needs it as one, give the shipping method a SKU in the admin, and it then appears in the product list.
• The order carries card details in credit_card_details, including the cardholder ID number and a card token. Ask only for the fields you need with attributes, and never write that block to your own logs.
• A webhook without a reconciliation job loses orders on the day your endpoint is down.
• Deleting products by SKU is possible (DELETE /v1/items/0?code=), so a sync bug can remove items from the live store. Keep delete out of the first version.

Connecting the order to an invoice is covered in connecting invoicing software to your other systems, and a similar store-to-ERP sync in syncing Priority ERP with Shopify. For the courier side, see automating shipping labels in Israel.

What to have ready before you start

• An API user with only the permissions the integration needs, and its token.
• The list of order states in the admin, with the exact titles the integration will set.
• A SKU for every product and variant - the SKU is how the store and the ERP recognise the same item.
• The invoicing or ERP system's own API access, tested separately.
• A decision on which system owns stock levels, so the two never overwrite each other.

Sources

• Konimbo API documentation (GitHub) - authentication, pagination, rate limits
• Konimbo API - orders
• Konimbo API - integration system and webhooks