Some fulfillment workflows need more than an order record. Warehouse teams also need the right visual identifier and document attached to the order at the moment the work reaches them.
The operating problem
Orders originated in Shopify, while fulfillment work happened in Packiyo. The handoff also required generated QR codes and PDFs to be available from the fulfillment record rather than through a separate manual process.
What the system did
A Node.js service extracted orders through the Shopify Admin API and stored working state in MongoDB. A separate loader transformed and sent eligible orders to the Packiyo API.
After order creation, the workflow generated QR codes and PDFs using QR and PDFKit tooling, uploaded the documents through a protected file service, and patched Packiyo order notes or attributes so the fulfillment team could access the generated material from the order context. Scheduled jobs, structured logging, input validation, rate limiting, and replayable state supported the handoff.
The integration did not stop at record transfer: it prepared the fulfillment artifact and placed its reference where the warehouse team already worked.
Why the historical qualifier matters
The source establishes the architecture and intended workflow, but not its present production status or current business outcome. We include it because the design pattern remains useful, while keeping the distinction between verified implementation and active operation explicit.
Reusable pattern: treat generated documents as part of order orchestration, with their own state, upload controls, and link back to the operational record.