TL;DR — Shopify retired two of the ugliest hacks in a 3PL integration in a single week: fake partial fulfillments for progress updates and generic error banners on B2B checkouts. Anthropic shipped Claude Opus 4.6 with an Excel add-in that actually builds pivot tables instead of describing them.
The theme
Three updates, one pattern: the platform ate the workaround. Every shop with a warehouse integration had a progress_state metafield and a function that faked a partial fulfillment to trigger a notification. Every B2B Checkout Validation Function had a comment apologizing for dumping billing errors into a generic banner. Every Excel user who asked Claude to build a pivot table got a tutorial instead of a pivot table. This week, all three got replaced with a first-class call.
The lesson is not "new API, go use it." It is that your custom glue code has a half-life, and the week a vendor ships the native version is the week your glue becomes a liability. Pin to the new API version, delete the hack, and take the diff as a gift. The teams that benefit most here are the ones who wrote the ugliest workarounds two years ago — and who have the discipline to retire them now instead of leaving the duct tape in place because it still works.
1. fulfillmentOrderReportProgress Lands for 3PLs in 2026-04 (original)
Overview
If you have ever wired a 3PL into Shopify, you know the hack: there was no native way to tell a merchant "this order is packed but not shipped." Apps faked it with custom order statuses, metafields, or the worst of the three — creating a partial fulfillment on a single line item just to fire a notification. The merchant saw half-fulfilled orders in their admin. The buyer got a bogus shipment email. Admin API 2026-04 fixes this with fulfillmentOrderReportProgress, a native mutation for in-flight progress. It does not create a fulfillment. It attaches a status event to the fulfillment order and fires a webhook.
Technical
The mutation takes a fulfillmentOrderId, a status from the FulfillmentOrderProgressStatus enum, and an optional note. The enum covers RECEIVED, PROCESSING, PICKED, PACKED, LABELED, HANDED_OFF, and EXCEPTION. Progress events land in fulfillmentOrder.progressEvents as an additive log. The fulfillment order does not transition to CLOSED, and no Fulfillment is created — when the carrier actually takes the box, you still call fulfillmentCreate with tracking as you always did. That separation is the right call. Existing automation on fulfillmentCreate keeps working, and opting into mid-stream visibility is additive.
Two gotchas worth calling out. Rate limiting is one progress event per fulfillment order per status per minute — ten PACKED calls in a row produce one event and nine THROTTLED errors, so coalesce at the source. And EXCEPTION is not terminal. It records a recoverable hiccup; you can flip back to PROCESSING on the next call. If you actually need to fail the order, use fulfillmentOrderRescheduleFulfillment or close it. On the receiver side, subscribe to the new FULFILLMENT_ORDERS_PROGRESS_UPDATED webhook topic via webhookSubscriptionCreate and you get a payload with previous_status, current_status, the note, and the reporting app's ID — enough to feed a merchant ops dashboard without polling.
Takeaway
If you maintain a warehouse integration, this is the call to retire your metafield-based progress tracking this week. Pin to Admin API 2026-04, swap the fake partial fulfillments for fulfillmentOrderReportProgress, and subscribe merchants to the new webhook topic so they can pipe states into their own dashboards. Keep fulfillmentCreate for the actual shipment. The mutation is purpose-built for everything that happens before the carrier shows up, and it is the first time Shopify has given 3PL developers a clean surface for it.
2. Cart and Checkout Validation Adds Billing and PO Number Targets (original)
Overview
Cart and Checkout Validation Functions could always block a checkout. The problem was the targeting. You could fail the whole cart, you could attach an error to a line item, you could attach to a shipping address field — and if your validation actually cared about the billing address or the PO number on a B2B order, your message ended up as a generic banner with no inline highlight. Buyers had to guess which field was wrong. API 2026-04 adds two new JSONPath target roots: $.cart.buyerIdentity.billingAddress.* and $.cart.poNumber. Checkout UI now renders the error inline under the matching input, same shape as a native field error. For B2B stores this is the change that makes Validation Functions usable on enforced-PO workflows and billing-tied fraud rules.
Technical
The function input shape has not changed. Your input.graphql already pulls cart.poNumber and cart.buyerIdentity.billingAddress. The change is in the output: the target field on a FunctionError now accepts the new JSONPath strings alongside the existing ones. Valid targets as of 2026-04 are $.cart, $.cart.poNumber, $.cart.lines[<index>], $.cart.deliveryGroups[<index>].deliveryAddress.<field>, and $.cart.buyerIdentity.billingAddress.<field>. Valid field names on either address are address1, address2, city, province, zip, countryCode, firstName, lastName, company, and phone.
One sharp edge: if you target a field that does not exist — typo, wrong casing, wrong path root — the function still returns successfully and the Checkout UI silently falls back to the generic banner. There is no platform-level validation telling you your target string is wrong. Verify in a real checkout against a development store before you ship. The other thing worth knowing: custom themes built on Checkout Extensibility get inline rendering for free. Liquid checkouts do not. If you have customers split across both, write your localized_message strings so they read correctly either as inline helper text ("ZIP code is required for US billing addresses") or as a standalone banner. Same string, both modes.
Takeaway
If you ship a Cart or Checkout Validation Function for a B2B store, audit your error targets this week. Anywhere you are returning a generic $.cart target for what is really a billing field or PO issue, swap in the specific JSONPath. Pin to API 2026-04 in shopify.extension.toml, deploy to a development store, and walk through a real checkout in both Extensibility and the legacy renderer to confirm the error attaches to the right input. The per-field targeting is the difference between "your order has an issue" and "fix this one field." Buyers convert on the second one.
3. Claude Opus 4.6 Launch: Smarter Coding, Native Excel (original)
Overview
On February 5, 2026, Anthropic shipped Claude Opus 4.6 alongside a new Claude for PowerPoint add-in and a Claude for Excel upgrade with native Excel operations. The model is the headline, but the Office work is the more interesting story for anyone running a real business. Opus 4.6 is what you reach for when the work has to be right the first time. The add-ins are how Anthropic gets that capability in front of people who do not live in a chat window. Both halves matter, and they landed in the same release for a reason.
Technical
The model ships as claude-opus-4-6-20260205, positioned as the new top-of-stack frontier model replacing Opus 4.5. Improvements concentrate in coding — Anthropic's benchmarks show double-digit gains on multi-step refactor tasks and better code-review outputs. In day-to-day use the change I notice is fewer "almost right" patches. Opus 4.5 would sometimes generate code that looked correct, ran, and was subtly wrong in a way that cost ten minutes to debug. Opus 4.6 does this less often. Pricing is unchanged from 4.5 at the same input/output tier. Tool use, vision, prompt caching, and the rest of the API surface work without changes — an existing Opus integration migrates with a model string swap. Bedrock and Vertex will pick up the model shortly after the direct-API release.
The Excel upgrade is the one to pay attention to. The v4.6 add-in adds native operations support, which means Claude can invoke real Excel functions — pivot tables, formulas, charts, data validation, conditional formatting — through the add-in API instead of typing them as text and hoping. Ask it to "build a pivot table that summarizes revenue by region, then add a clustered column chart below it," and the add-in builds the pivot table and adds the chart, formatted reasonably. Previous versions would walk you through the clicks. A few practical notes: PowerPoint and Excel add-ins require Microsoft 365 with add-in installation enabled, so locked-down IT setups need an admin-center allowance. The Excel add-in's native operations are scoped to the active workbook's permissions — it cannot reach across to other open workbooks unless they're explicitly shared. And the Opus 4.6 swap inside the Excel add-in happens automatically; there is no version pinning surface, so you cannot fall back to 4.5 behavior if you preferred it.
Takeaway
Two moves this week. First, if you have an Opus integration in production, swap to claude-opus-4-6-20260205 and re-run your eval set. The coding improvements are real and the migration is a one-line change. Second, if your team uses Excel or PowerPoint daily and you have not installed the Claude add-ins, install them. The Office surface is where Anthropic is putting their non-developer workflow investment, and the gap between "use Claude in a chat" and "use Claude where you actually work" just got meaningfully smaller. The pivot-table demo alone is worth the install for anyone who builds reports from CSVs on a weekly cadence.
Original sources
- fulfillmentOrderReportProgress Lands for 3PLs in 2026-04 — originally published 2026-01-22
- Cart and Checkout Validation Adds Billing and PO Number Targets — originally published 2026-02-03
- Claude Opus 4.6 Launch: Smarter Coding, Native Excel — originally published 2026-02-05
