commercetools API integration, scoped and built

An API extension is a synchronous call commercetools makes out to your service while a cart or order is being written, so the response can change the result before it is saved. Tax and fraud checks are the common cases. It is the right pattern when the answer has to be correct at that instant, and the wrong one when a few seconds of delay would be acceptable.

Somebody has already decided, usually by accident. Until one system is named as the owner of each field, both write and the last one wins, which is why the symptom shows up as intermittent wrong prices rather than a failure. We name an owner per field in the data map, then make every other system read that value rather than compete with it.

Against production-scale data, including the paths that fail. We exercise each flow at real order volumes, then deliberately break it: time out the receiving system, send a malformed payload, replay a duplicate event. Retry and alerting behavior is proven before customers depend on it, because integration defects surface as wrong data rather than error pages.

The count of custom services sets the number, not the count of systems. An estate served by ready connectors costs a fraction of one needing three bespoke services with their own reconciliation rules. We price after the systems audit, never before it. Vendor connector licenses and your commercetools plan are billed to you directly and are separate from our invoice.

Latency and ownership decide it. If the answer must land before the order is saved, it is an API extension. If the receiving system only needs to know shortly afterwards, a subscription carries the event without holding up checkout. A custom microservice earns its place when the logic is yours rather than either system's, such as reconciliation rules no vendor connector models.

Often, and it is usually cheaper than replacing it. Many teams fork a vendor connector to add one field and then cannot take upstream updates. We look at whether your changes can move into an API extension or a subscription alongside the stock connector, which puts you back on the vendor's release path and keeps your logic separate from theirs.

Yes. We start by reading what exists: which flows are live, which are silently failing, and how much lives in forked connector code outside version control. You get a written assessment naming what to keep, what to rewrite, and what to retire, with an estimate against each item. That assessment is yours whether or not we do the work.

The engineers who wrote them. Alerting is configured per flow, and support covers the two things that break working integrations over time: commercetools platform releases, and vendor API changes at the other end. Both arrive on someone else's schedule, so upkeep is a standing commitment rather than a warranty period.