SubscriptionContract.originOrder only set for Shop Pay contracts created via API

GraphQL Admin API Troubleshooting
1

We migrated a handful of existing subscriptions into native SubscriptionContracts and noticed originOrder is populated on some but not others despite all being created the same way.

How we create them (no checkout, 2025-10): subscriptionContractCreate → subscriptionDraftCommit. No order ID passed, no atomic create. Payment methods are attached beforehand, some Shop Pay, others cards/PayPal vaulted directly.

Our observation: the contracts backed by a Shop Pay agreement (CustomerShopPayAgreement) automatically get an originOrder pointing to a real store order, while the card and PayPal ones get none. This holds even though none of them have billed yet (0 billing attempts, 0 generated orders), so it’s not coming from a billing cycle — it correlates purely with the payment method. My guess is that originOrder is only set when the payment method comes from an order-generating Shop Pay flow, and stays null when the method is vaulted directly.

Questions:

1. Is this intended — originOrder only set via a Shop Pay flow, null otherwise for API-created contracts?

2. Will the null ones ever be backfilled?

3. I checked the 2026-04 schema — none of SubscriptionContractCreateInput, SubscriptionDraftInput, SubscriptionContractAtomicCreateInput, or SubscriptionAtomicLineInput expose an origin-order field. So there’s no way to set it on an API-created contract, correct? Any plans to add one for migrations?

4. Is this behavior expected to change in a future API version?

We rely on originOrder for some lookups, so knowing whether null is permanent for migrated card/PayPal contracts would help a lot. Thanks!

3

Hi @mgtmn! You’ve got the mechanism right -originOrder is auto-populated for Shop Pay contracts because Shop Pay billing agreements are created through checkout, which produces the order the contract originates from. Card and PayPal methods vaulted directly have no originating order, so originOrder stays null. This is expected behavior.

You’re also correct that there’s no API input to set it. originOrder is a read-only field on SubscriptionContract, and none of the create inputs expose an origin-order field. I checked subscriptionContractCreate, SubscriptionContractAtomicCreateInput, and SubscriptionDraftInput in both 2025-10 and 2026-04, so migrated card/PayPal contracts will have a null originOrder with no API workaround today.

The orders connection on a contract returns the recurring billing orders generated after it’s created, not the originating or migration order. If you need to preserve that link, you can store the originating order reference in custom attributes on the contract, though that won’t populate the native originOrder field.

I’ve captured points 3 and 4 as feedback for the product team to consider. I can’t speak to timelines or confirm a future API change, but the feedback is logged so the team can see the demand. Thanks for raising this here!