Product and Sales Order API Automation
Every sales order was re-typed by hand from the order system into fulfillment. The double entry caused delays, SKU and quantity typos, and orders that shipped wrong or late.
Industry
Product distribution business selling through multiple sales channels
Role
Systems consultant — API integration design, automation build, error handling, documentation
Impact
Order handoff went from a daily re-typing chore waiting on someone's attention to an automated flow where the team only touches the exceptions.
01 - Problem
The problem
Two systems didn't talk to each other: one took sales orders, one handled fulfillment. Every order was re-typed by hand between them. On a busy day that was the bottleneck — orders sat until someone copied them over, and the copying introduced errors. A transposed quantity or wrong SKU usually surfaced after the order had already shipped wrong or missed the cut-off.
Nobody trusted the handoff, so the team double-checked each other's entry — processing the same order two or three times. Before automating, I mapped which fields fulfillment actually required, where the two systems disagreed on formats, and which errors the team kept fixing by hand. That structure-first pass made the API integration reliable, not just fast.
02 - System Flow
How the system moves
Order placed
source system fires webhook
Webhook received
Make scenario triggers instantly
Data validated
required fields and SKU checks
Payload transformed
mapped to fulfillment API format
Order posted
REST API call with retry
Failures logged
Google Sheets error log
Team alerted
plain-language error notification
03 - Build
What I built
Webhook intake and validation layer
The source system fires a webhook the moment an order is placed, triggering a Make scenario — no polling. Before anything moves downstream, the order passes validation I built from the team's actual failure history: required fields present, SKUs matched against the product list, quantities in range, shipping details complete. Bad data gets caught at the door, not at the warehouse.
Transformation and posting to the fulfillment API
The two systems named fields, formatted addresses, and structured line items differently. A transformation step maps the incoming payload to exactly what the fulfillment REST API expects, then posts it. Each order carries its original reference through the integration, so the same order can never post twice even if the webhook fires again.
Error log, alerts, and handover documentation
Any order that fails validation or posting lands as a row in a Google Sheets error log: timestamp, order reference, and a plain-language reason a non-technical person can act on, plus a team alert. I documented the workflow automation — field mappings, validation rules, error messages — so the team can run and troubleshoot it without me on call.
04 - Impact
Business impact
Re-typing orders left the daily routine — what used to eat every afternoon now takes a few minutes reviewing exceptions.
SKU and quantity typos stopped reaching fulfillment, caught at validation instead of after an order ships wrong.
Orders reach fulfillment moments after being placed instead of waiting on someone, so daily cut-offs stopped being a scramble.
The error log gave the team one place to see what failed and why, turning mystery shipping mistakes into a short, fixable list.
05 - Edge Cases
What had to be handled
Duplicate webhooks — the source occasionally fires the same event twice, so the integration checks each order reference against what's already posted and drops repeats.
Fulfillment API downtime — transient failures retry after a delay; if the order still won't post, it's logged as a system issue, not a data issue, so the team knows it's safe to resubmit as-is.
Missing fields — an order missing a required field is held and logged with the exact field named, instead of posting half-complete and failing somewhere harder to see.
Unknown SKUs — items that don't match the fulfillment catalog go to human review instead of being guessed, which also surfaced catalog mismatches the team didn't know existed.
06 - Improvements
What I would improve next
Add one-click resubmit for orders that failed on transient API errors, so the team doesn't re-trigger them manually from the log.
Build a small reporting dashboard on the error log to spot recurring validation failures and fix them upstream in the source system, not just downstream.
Extend the pattern the other way — pushing stock levels and fulfillment status back into the sales system — for a two-way sync instead of a one-way handoff.
Related capabilities