Executive summary
What: Shopify Functions API version 2026-10 adds a createdAt field to the Customer object, returning when the customer account was created.
Why: Tenure-based logic can now be evaluated inside the Function at runtime, with no external lookup and no synced metafield to go stale.
Who: Merchants running discount, shipping or payment customizations that need to distinguish new customers from long standing ones.
What changed
The Customer object exposed to Shopify Functions now carries createdAt. You request it from the customer on cart.buyerIdentity in the Function input query, nested as cart, then buyerIdentity, then customer, then createdAt. The change is additive: earlier API versions behave exactly as before and existing Functions require no action. One constraint carries real weight. The customer is present only when the buyer is signed in, so on guest checkouts buyerIdentity or customer may be null or omitted entirely. Your Function has to handle that path deliberately rather than assume a value is there.
Why it matters
Until now, tenure logic at checkout meant one of two compromises. Either you wrote a customer metafield from an external job and accepted a staleness window, or you leaned on discount codes and accepted that they leak. The metafield route also adds a sync dependency: another job to monitor, another failure mode during peak. Reading createdAt directly from the Function input removes both. The value is evaluated at request time against the actual account, inside the checkout execution budget, with no network call. Practically, that unlocks anniversary offers, tenure-banded loyalty benefits, welcome offers that genuinely resist abuse, and shipping or payment ordering that rewards long standing accounts. Teams already running layered checkout rules will recognise the pattern from our work on complex discount logic at enterprise scale, where the hard part is usually precedence between rules rather than any single rule.
Role-specific impact
Marketers: account tenure becomes a targeting input at checkout, not just an email segmentation attribute. Anniversary and win-back mechanics can be enforced at the cart instead of relying on a code that spreads.
Developers: upgrade the Function to API version 2026-10, add createdAt to the input query, and treat buyerIdentity and customer as nullable. Decide the guest fallback explicitly and cover it with a test.
Store admins: expect offer behaviour to differ between signed-in and guest checkouts. Update support macros so agents can explain why a benefit did not apply to someone shopping logged out.
Use-case example
Real-world scenario
A subscription coffee brand wants to give customers past their first year free shipping, without publishing a code that ends up on deal aggregators. The previous build synced a tenure metafield nightly, which meant a customer crossing the twelve month mark on a Tuesday morning did not see the benefit until Wednesday, and support absorbed the difference one ticket at a time. With createdAt available in the Function input, the shipping discount Function compares account creation date to the current date at checkout and the benefit applies the moment it is earned. If roughly 18 percent of the active base sits past twelve months, finance can size the shipping subsidy against a real number, and the nightly sync job retires along with its alerting.
Implementation checklist
Identify which Functions would benefit: discount, shipping and payment customizations are the usual candidates.
Update the target Function to API version 2026-10.
Add createdAt under cart.buyerIdentity.customer in the Function input query.
Handle null buyerIdentity and null customer explicitly, and decide what guests should receive.
Define the tenure boundary in one place, and state the time zone assumption rather than inheriting it accidentally.
Test signed-in buyers, guest buyers and a freshly created account before release.
Roll out to a limited audience and watch discount application rates for unexpected movement.
Retire any metafield or sync job that existed only to carry account age into checkout.
FAQ
Q: Do we need to change our existing Functions?
A: No. This is an additive change and earlier Shopify Functions API versions are unchanged. You only take action when you want the field, which means the upgrade can wait for your next planned release rather than forcing one.
Q: What happens on guest checkouts?
A: The customer is unavailable, so createdAt cannot be read. Decide deliberately whether guests fall into the new customer branch or are excluded from tenure logic entirely, and make sure the Function does not error when the value is absent.
Resources
Shopify Functions API reference
Need guidance? Talk to Makro.