Challenge
Find out why the external API rejected some orders, fix it and detect these failures quickly.
Case study
Magento 2 order integration with an external API
Magento 2 order integration with an external API
Diagnosis and fix of the integration between a Magento 2 store and an external system: rejected orders, structured logging, contextual alerts and a corrected data mapping.
Magento 2APIEcommerce
When an order fails and nobody knows why
The store sent its orders to an external system through an API. Some were rejected with HTTP 400 errors, and the alerts did not say enough to know what had failed or for which order.
Approach
The alert system was extended with structured logging including each order’s context, and the request sent was compared with what the API expected.
Outcome
The shipping address was sent as a nested object when the API expected flat fields. The mapping was fixed and orders are now sent in the right format.
Technology
A stack chosen for the problem
A stack chosen for the problem
The work was done on the store’s own integration module: contextual logging through Magento’s logger, a review of each order payload and a comparison with the external API contract.
Magento 2PHPREST API
Errors that can be explained
An integration does not only fail when it goes down: it also fails when it rejects data and nobody notices. The value of the work was making those failures and their cause visible.
Contextual alerts
Contextual alerts
Every alert includes the affected order data.
Root cause fixed
Root cause fixed
The shipping address mapping now matches the format the API expects.
Faster diagnosis
Faster diagnosis
Structured logs make it possible to find a problem without blind reproduction.
A sturdier integration
A sturdier integration
The data contract with the API is clear for future changes.
What changed in the store’s operations
This case is anonymised, so we do not publish client figures. These are the changes the work brought.
Visibility
Visibility
Before: generic alerts. Now: alerts with order data.
Orders accepted
Orders accepted
Before: rejections with a 400 error. Now: orders are sent in the format the API expects.
Less diagnosis time
Less diagnosis time
Before: checking orders one by one. Now: structured logs pinpoint any failure.
Easier maintenance
Easier maintenance
Before: implicit data format. Now: API contract reflected in the code.
Do you have a similar challenge?
Do you have a similar challenge?
We can review it without assumptions and define a realistic first phase.