Technical
WooCommerce Integration Patterns for Serverless Backends
Clients running WooCommerce often want to add bespoke workflows that WooCommerce itself cannot do well. A serverless backend is a great companion: let Woo handle the storefront, let Lambda handle the smart parts. Here is the pattern I have shipped a few times, and the gotchas that took me longest to figure out.
The Basic Shape
WooCommerce has webhooks, a REST API, and hooks (actions/filters) inside PHP. A serverless backend can use all three:
- Webhooks out: WooCommerce notifies Lambda when events happen (order placed, product updated)
- REST API in: Lambda reads and writes Woo data via the WooCommerce REST API
- Custom endpoints: a small Woo plugin exposes project-specific endpoints backed by Lambda
The rule I follow is: WooCommerce owns the shop data. Lambda owns the smarts. Data round-trips between them.
Webhook Receivers
Woo webhooks are JSON POSTs with a signature header. The Lambda receiver validates the signature, parses the body, and drops the event on SQS for async processing:
def handler(event, _):
sig = event['headers'].get('x-wc-webhook-signature')
if not verify_sig(event['body'], sig):
return {'statusCode': 401}
sqs.send_message(
QueueUrl=QUEUE_URL,
MessageBody=event['body'],
)
return {'statusCode': 202}Returning 202 fast keeps Woo happy. The real work happens in a worker that reads the queue. If the worker fails, Woo never retries and you lose data. Always use a queue, never do the work inline.
REST API Auth
Woo's REST API supports OAuth1 or basic auth with app passwords. For server-to-server use, app passwords are simpler. Store them in AWS Secrets Manager, rotate quarterly, never in the repo.
The Sync Loop Trap
The worst bug I hit was a sync loop. Order updates triggered a webhook, the webhook wrote back to Woo, the write triggered another webhook, and so on. Infinite loop, thousands of events per minute.
The fix is idempotency keys. Every write Lambda sends to Woo includes a custom metadata field with an origin tag. The webhook receiver checks that tag and skips events it generated itself.
When Not to Use This Pattern
If the only thing you need is "show a different checkout page," use a Woo plugin and skip the serverless piece. This pattern earns its keep when the smarts are genuinely custom (AI-assisted recommendations, complex inventory calculations, multi-tenant logic). For cosmetic changes, it is overkill.
The WooCommerce REST API documentation has the full reference.
RELATED READING
The Consulting Shift I Am Making In Year Two
After a year of writing and building, my consulting practice is changing shape. Shorter engagements. Sharper outcomes.
ReadThe Frontend Shift: Shipping Less JavaScript In Year Two
A year ago I reached for Next.js for everything. This year I often reach for nothing.
ReadThe Serverless Lesson I Would Write On A Sticky Note
After a year of shipping serverless projects, one rule explains most of the wins and all of the losses.
Read