Markets deprecation

Functions
1

Hey folks,

I’ve received an email stating that we need to migrate off ‘deprecated single-market APIs’.

The documentation points here (Target buyers by country instead of market ID)

A feedback form is provided, but does not work (you can’t get passed the email input field).

I wanted to raise this as a big issue for functions specifically. We will have thousands of configurations that use market.handle - in production - used by real merchants.

The guide suggests that we start using ‘country code’ instead. In addition, it suggests storing a market → country code field in our own metafield.

We have updated our discount function(s) to allow for targeting by market at the API level in addition to targeting the market handle.

Writing script to go through thousands of function configurations (metafields), belonging to hundreds+ merchants is a crazy expectation. The risk involved is big.

Why can’t the suggested ‘store regions per market’, be handled Shopify side to ensure backwards compatibility of function configurations?

2

Hello,

Thanks for the response, the feedback form had been fixed.

Wanted to get some clarifications on the concern raised.

Writing script to go through thousands of function configurations (metafields), belonging to hundreds+ merchants is a crazy expectation. The risk involved is big.

I might be reading this wrong, so correct me if the concern is elsewhere. I’m reading this as a concern of needing to iterate and writing over over many function configurations per shop.

I believe you don’t need to update metafields on a per function basis. You can store a single markets => regions mapping on a app global metafield once per shop, and update it as need be when market merchants update their market configurations with market webhooks.

This way the per function metafield that stores the list of market ids can be the same as before [NA: 1, MX: 2 …]. The difference is fetching the country set from the global markets ==> regions mapping and checking the buyer’s country against that set.

Why can’t the suggested ‘store regions per market’, be handled Shopify side to ensure backwards compatibility of function configurations?

Unfortunately how apps store their data may vary between apps for their metafields. Some apps store their market handle/ID data in their own database. It’s not feasible to do the migration on the app’s behalf.

But any feedback we can receive on making the migration smoother, clarifications or exploring ways to do the migration more safely is greatly appreciated.

3

@bkspace For apps on API version 2026-07+, I believe the discountAutomaticAppCreate mutation accepts markets in the context input to target discounts to specific markets.

This was discussed in the change log here: Target discounts to specific markets - Shopify developer changelog

4

Hey @Raymond_Zeng, thanks for getting back to me :slight_smile:

  • You can store a single markets => regions mapping on a app global metafield once per shop

In order to access an additional shop metafield, it would cost 3 input query points, which is not viable for any of our discounts (out the gate) - unless we can get an exception to the 30 query point rule?

Secondly, it relies on a webhook → update metafield process. It’s likely that there will be missed webhooks, delayed webhooks etc. This can lead to incorrect discounts being applied.

  • It’s not feasible to do the migration on the app’s behalf.

My suggestion here was not that Shopify update the configurations belonging to live functions, but rather market.handle should represent the inverse of the relationship you proposed above - kept up to date by Shopify. This means backwards compatibility for existing function configurations.

  • For apps on API version 2026-07+, I believe the discountAutomaticAppCreate mutation accepts markets in the context input to target discounts to specific markets.

That’s correct, and we offer that to merchants today. But there are also a few problems with this. Firstly, we still have existing functions that target market.handle - rather than targeting market at the top level. Secondly, we have plenty of configurations that target different market(s) (inclusions, exclusions), per discount proposal - so multiple per function - one top level market does not cover those existing configurations.

We can change ‘update’ discount configurations to target ‘countries’, but on multiple discount functions, we are already at the 30 input query limit, so we could never add both the market.handle AND localisation.country at the same time.

What we would likely have to do - is update every existing function configuration metafield to change market handle → list of associated country codes.

We can do this with an expand & contract approach to be as careful as possible. The truth is though, some likelihood/possibility of something going wrong exists.

I don’t think this is a responsible requirement/approach and it’s not fair to merchants (who may have incorrect/invalid discounts as a result), or the work + risk put on partners. If something goes wrong - 1* reviews galore!

5

Hi @bkspace ,

These are valid concerns raised. We don’t want to force app partners to take risks and costs if you don’t need to. We have raised these concerns internally and exploring solutions to mitigate them.

Once we have internal alignment we’ll reach back out to you to continue the feedback loop.

Again, thanks for raising these concerns, these feedback are valuable to us.

6

To be clear, your recommendation is for Shopify to provide the market => regions mapping on behalf of the app to reduce risks and input query complexity cost. Something along the lines of input: [market_ids or handles] -->(API) → output: Regions. Would that work for you?

7

Yes, I think something like that would work - without having the issue of either additional input query points, or having to change live configurations (metafield values)