Required Action For New Service Area Field

Developer_Update_Service_Areas
Due to Google product changes, Yext has introduced a new way for businesses to define service areas. This post describes both the new serviceAreaPlaces field, and outlines the actions developers need to take in order to migrate API integrations to use the new field.

What’s changing

Currently, our customers can use the Knowledge API to define their service area as a list of postal codes or cities in the serviceArea field. With Yext’s Fall ‘19 Release, we now support additional service area types, in addition to postal code and city, that give businesses more flexibility with the areas that they service:
  • State/Region
  • County
  • Sublocality
We have also introduced the ability to explicitly specify a type for each of your service areas so that we can more accurately provide your service area information to Google. To accommodate this change, we have introduced a new field in the API called serviceAreaPlaces that is available today. The serviceAreaPlaces field has the following format:
"serviceAreaPlaces": [
      {
        "name": "02670",
        "type": "POSTAL_CODE"
      },
      {
        "name": "Massachusetts"
      }
    ]
The name subfield defines your service area and the optional type subfield defines the service area type (one of POSTAL_CODE, REGION, COUNTY, CITY or SUBLOCALITY). Any data you currently store in the serviceArea field has been migrated to the serviceAreaPlaces field and will be kept in sync until the serviceArea field is deprecated on February 1, 2020.

What you need to do

Between now and February 1, 2020, update your integration to use the new serviceAreaPlaces field. Updates made to the legacy serviceArea field after February 1, 2020 will fail and the field will not be returned in any API responses.

Questions?

If you have any questions about this change or need help migrating your serviceArea field to serviceAreaPlaces field, please contact our API support team.