Shopify Order Import
Import Shopify orders into the app with money, fulfilment, and later edits accurately kept.
What it adds
A resumable import of the connected store's orders, mirroring line items, discounts, taxes, and fulfilment state locally.
What your agent is told to do
5
What your agent is told to do
5-
1
Separate the initial backfill from the ongoing feed. The backfill walks history in a stable order behind a resumable cursor; the feed applies live updates as they arrive.
-
2
Key every imported order on the shop identifier together with the store's own order identifier, so re-running the import updates existing rows instead of duplicating them.
-
3
Store money as an exact decimal with its currency alongside it, and keep both the shop currency and the presented currency where they differ. Do not convert to a single display currency on the way in, because the original amounts cannot be recovered afterwards.
-
4
Treat an order as a state machine rather than a snapshot. Edits, cancellations, refunds, and partial fulfilments all arrive later as new versions of a record you already hold.
-
5
Customer identity and marketing consent are owned by Shopify Customer Sync. Link to the customer record that brief maintains rather than writing customer fields from an order payload.
Edge cases it handles
8
Edge cases it handles
8- A backfill interrupted halfway must resume from its cursor without re-importing what it already wrote. Restarting from the beginning is acceptable only if every write is keyed and idempotent.
- External identifiers are unique per store, not globally. Two connected shops will eventually produce the same order number, and an unscoped key silently overwrites one with the other.
- Test orders placed while a store was in a sandbox or test payment mode must be flagged or excluded, or they will inflate every revenue figure the app reports.
- An order can be edited after the fact, cancelled, refunded in part, and fulfilled across several shipments. Each of those is a later version of the same order and must replace the local state rather than add a second row.
- Money must never pass through a floating-point value. Multi-currency stores also present two amounts for the same order, and the app has to record which is which.
- Updates arrive for an order while the backfill is still running, sometimes before that order has been imported at all. Queue them and apply them by version or timestamp so older backfill data cannot overwrite a newer change.
- Orders reference products and variants that may since have been deleted. Keep the title, price, and identifier the line item captured at the time rather than depending on a live product lookup.
- A store with years of history will hit the provider's rate limits during a backfill. Pace the import and back off when refused rather than retrying in a tight loop.
Definition of done
8
Definition of done
8- A backfill can be interrupted and resumed, and re-running it produces no duplicate orders.
- Order keys include the shop, so two connected stores cannot collide.
- Cancelled, refunded, edited, test, and partially fulfilled orders each land in a distinct, queryable local state.
- Money is stored as exact decimals with explicit currency, and multi-currency orders retain both amounts.
- Updates arriving mid-backfill are applied in the correct order and are never overwritten by older data.
- Customer records are linked from Shopify Customer Sync rather than created here.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Lemon Squeezy License Sync
Lemon Squeezy License Sync
Sync Lemon Squeezy orders and license keys into the app's entitlement state.
What it does
A verified event pipeline mapping Lemon Squeezy orders, subscriptions, and license keys onto local entitlements, with activation limits and revocation handled.
How it works
- 1 Verify the authenticity of every incoming provider event before it changes anything. An unverified purchase notification is a request from the internet to give away your product.
- 2 Keep an explicit server-side table mapping each purchasable variant to the entitlement it grants. Do not infer the plan from a product name, because names get edited for marketing reasons and entitlements should not move when they do.
- 3 Bind each license key to a single account on first activation and refuse to activate it against a different one afterwards, with a documented path for an operator to release a key that genuinely needs to move.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/lemon-squeezy-license-sync
Stripe Customer and Subscription Sync
Stripe Customer and Subscription Sync
Keep local billing state matching Stripe as subscriptions, invoices, and plans change.
What it does
A verified event pipeline that projects Stripe customer, subscription, and invoice state onto the app's own access records, with reconciliation for anything the pipeline missed.
How it works
- 1 Define one local projection of billing state per account: which plan, which status, which period it runs to, and whether access is currently allowed. Every entitlement check in the app reads that projection and nothing else.
- 2 Verify every incoming event as genuinely from the provider before acting on it, and record its identifier so a replay is recognised and ignored. Providers retry on any non-success response, so handlers must be safe to run repeatedly.
- 3 Store a timestamp or version with the projection and refuse to apply an event that is older than what has already been written. Events arrive out of order, and a stale cancellation overwriting a fresh renewal locks a paying customer out.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/stripe-customer-and-subscription-sync
Paddle Subscription Checkout
Paddle Subscription Checkout
Sell subscriptions through Paddle with entitlements granted only by verified events.
What it does
A Paddle-backed subscription purchase and lifecycle flow where local access follows verified server events and prices stay under server control.
How it works
- 1 Hold the catalogue mapping on the server: which local plan corresponds to which provider offering, at which price and currency. The client passes a plan identifier and nothing about money.
- 2 Carry an account or workspace reference into the checkout so the subscription that comes back can be attached to the right tenant without matching on email address.
- 3 Grant access only from verified server-side events, and store the event identifier so a retried delivery changes nothing a second time.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/paddle-subscription-checkout
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.