Shopify Integration with AWS

Why connect Shopify to AWS at all

Shopify runs the storefront well, and for a large set of questions its own reporting is the right answer. Building an AWS pipeline to reproduce a number Shopify already shows you is a genuine waste, and we will say so before quoting for it.

The integration earns its cost in one specific situation: when the question spans systems Shopify cannot join. What should we reorder today needs order velocity from Shopify, on-hand counts from a warehouse system, lead times from a vendor record, and landed cost from finance. Which SKU is quietly losing money needs three of those four. No amount of storefront reporting answers those, and this is exactly the class of question AI agents are useful for.

The webhook path most teams get wrong

The default instinct is to host an HTTPS endpoint, verify the HMAC signature, and process the payload. That works, and it means you now own a public endpoint, its TLS certificate, its authentication, its retry behaviour and its availability during your busiest hour.

Shopify supports Amazon EventBridge as a native webhook destination. Events arrive on a partner event bus in your account. There is no endpoint to host, EventBridge handles retries and gives you archive and replay, and multiple consumers can subscribe to the same event without you building a fan-out.

Use the bus unless you have a specific reason not to.

Idempotency is not optional

Shopify webhook delivery is at-least-once. Duplicates are a normal operating condition, not an incident — a slow acknowledgement during a flash sale is enough to trigger a redelivery.

The pattern is a conditional write against DynamoDB keyed on the webhook event id, executed before any side effect:

# Assumes DynamoDB table `shopify_webhook_events` with PK `event_id` and a TTL attribute.
put_item(
  Item={'event_id': event_id, 'ttl': now + 30d},
  ConditionExpression='attribute_not_exists(event_id)'
)
# ConditionalCheckFailedException -> already processed. Acknowledge and stop.

Get this wrong and the symptoms are duplicate fulfilment and double refunds, both of which cost real money and both of which surface first at peak.

Webhooks are not a complete record

Webhooks tell you what changed. They do not guarantee you saw everything — a consumer outage, a misconfigured topic, or an event that predates your integration all leave gaps.

Run a scheduled reconciliation against the Admin GraphQL API, using bulk operations for catalog-scale reads. Compare counts against what you have landed and alarm on drift. Teams that skip this discover the gap months later, usually when an agent produces an answer that does not match what someone can see in the Shopify admin.

Note the rate-limiting model: the GraphQL Admin API charges by query complexity, not request count. A deeply nested query pulling orders with line items, variants and metafields consumes the bucket much faster than the request count suggests. Inspect the returned cost extensions in development so the expensive query is found in staging rather than during a sale.

The identifier decision is the whole project

Every failure we see in agent-over-Shopify work traces back to the same root: the systems disagree about what a product is.

Shopify has products and variants. Your warehouse system has SKUs. Your vendor has part numbers. Your finance system has cost records keyed on something else again. While humans interpret the reports, the mismatch is absorbed by judgement. An agent has no judgement — it joins what it is given and answers fluently.

Pick one identifier that resolves across all of them and enforce it at ingest. This is unglamorous, it is usually the largest piece of work, and it is what separates an agent that is useful from one that is dangerous. See why your eCommerce data is not ready for AI agents.

Reference shape

Shopify  --(EventBridge partner bus)-->  EventBridge
                                            |
                        +-------------------+-------------------+
                        |                                       |
                Lambda (idempotent)                     Firehose -> S3
                        |                                       |
                DynamoDB / Aurora                        Glue + Athena
                        |
              AgentCore Gateway (Cedar on writes)
                        |
                  Agent tools: get_order_status,
                  check_stock, propose_refund

The agent never holds a Shopify Admin API token. It calls narrow, verb-shaped tools through the Gateway, every write is a Cedar policy decision evaluated outside the model, and anything that moves money lands in a human approval queue. That boundary is described in full in the agentic commerce on AWS pattern.

When not to build this

• One number, one dashboard. If Shopify Analytics answers it, use Shopify Analytics.
• No cross-system join. If the question lives entirely inside Shopify, the pipeline adds cost and latency and buys nothing.
• Identifiers do not resolve yet. Building the pipeline first means faithfully delivering bad joins at higher speed. Fix that first — run the readiness checker.