Transferring orders from OpenCart to KeyCRM is a basic integration scenario, but it is where product options, payment method, shipping department, or status history are most often lost. The official keyCRM manual describes a basic connection, but in practice a reliable exchange should not just create a card in CRM, but retain enough data to process the order and safely survive a repeat event.
What does the order flow look like?
- The buyer confirms the order in OpenCart.
- The module receives an event after the actual creation of a record in the database.
- Data is normalized: contacts, positions, options, amounts, delivery, payment and source.
- The module checks if this order is already linked to KeyCRM.
- An order card is created or updated in CRM through the API.
- The relationship between the OpenCart ID, the source and the KeyCRM UUID/ID is stored locally.
- Subsequent status changes are processed according to the configured direction.
It is best to start the exchange immediately after the order is created, but not to block the successful checkout page with a long API request. If CRM is temporarily unavailable, the operation must remain in the log or queue for rerun.
What data to transfer from OpenCart to KeyCRM
| Group | Minimum set | What to pay attention to |
|---|---|---|
| Identification | Order ID, source, date | The ID must be unique within a particular store. |
| The client | Name, phone, email | Normalize the phone to one format, do not create duplicate clients. |
| Goods | SKU, name, quantity, price | Transfer options separately; the amount must correspond to the actual currency of the order. |
| Delivery | Method, cost, address/department | OpenCart custom fields require explicit mapping. |
| Payment | Method and current status | Method name and payment confirmation are different data. |
| Marketing | UTM, referrer, promo code | The default connector may not pass custom marketing fields. |
Rule of thumb: anything a manager uses for confirmation, picking, shipping or analytics should either be passed to a standard KeyCRM field or have a documented custom field.
OpenCart and KeyCRM status mapping
In OpenCart, the status is part of the order history, and in KeyCRM it can correspond to the stage of the funnel. It's dangerous to automatically equate names: "Processing" in one store may mean a new order, and in another - a package that has already been collected.
Make a table of directions before starting:
| event | OpenCart | KeyCRM | direction |
|---|---|---|---|
| New order | Pending | New | OpenCart → KeyCRM |
| Confirmed by the manager | Processing | Confirmed | KeyCRM → OpenCart |
| Delivered | Shipped | sent | KeyCRM → OpenCart |
| Cancelled | Canceled | Cancelled | One main direction is chosen |
For each pair, determine who is the source of the truth. If you allow simultaneous mutual updates without rules, the two systems can endlessly roll back statuses or return the old value.
How integration protects against duplicates
A repeat webhook, page refresh, response timeout, or manual trigger should not create a second order. For this, the operation must be idempotent: the module searches for an already saved connection by store ID and UUID/source ID and performs an update instead of re-creating.
The advanced Build Zone module stores order links, finds them by UUID, does not create duplicates, and keeps a history of status changes. In the admin panel, tools for checking and cleaning service connections are available - they are used during diagnostics, and not as a regular "optimization".
Events, webhook, CRON and manual trigger
New OpenCart orders should be sent immediately. Changes from KeyCRM can come via outgoing webhooks: status change, order update or other supported event. Mass revalidation and maintenance is more convenient via CRON.
- OpenCart event - quickly sends a new order.
- Webhook KeyCRM — the store informs about changes from the CRM side.
- CRON — performs scheduled operations and resynchronization.
- Manual start — required for control test and maintenance.
Pre-launch control script
- One order with a simple product.
- One order with a mandatory option and a discount.
- Delivery with address or branch and non-zero cost.
- Online payment and Postpaid as different scenarios.
- Resubmitting the same event without a duplicate.
- Status change in the permitted direction.
- Temporary API error and reprocessing after recovery.
What to watch if the order is not transferred
Start with the module log: request time, endpoint, HTTP code and error text. 401 usually means an API key problem; 422 — incorrect or incomplete field; 429 — excess keyCRM API limit; 5xx — temporary service or server error. The production log should not display the full Bearer token or personal data of the buyer unnecessarily.
Next, check that the OpenCart event has fired, that the correct KeyCRM source is active, that the shipping method mapping matches, and that there is no conflict with the checkout modifier. Step-by-step initial setup is described in the manual "How to connect KeyCRM to OpenCart".
Do you need a stable transfer of orders?
The Build Zone module supports automatic transfer and import of orders, two-way statuses, KeyCRM sources, UUIDs, history and duplicate protection.