Handling Post/Zip Codes

Sometimes, zipcode and postal code lists may be very large (>10,000 codes), causing issues in API performance.  You may pass in an optional query string parameter in the GET calls, "&postcoderef=1" which will substitute the "condition_codes" array of zipcodes, with an array containing one postal code list reference id.

Usage

Targeting Criteria Snippet Without Query String Parameter:

GET /suppliers/v2/surveys/:survey_id
{
	"qualification_code":229,
	"condition_codes":[
		"01234",
		"01235",
		"01236"
	]
}

Targeting Criteria Snippet With Query String Parameter:
GET /suppliers/v2/surveys/:survey_id?post_code_ref=1
{
	"qualification_code":229,
	"condition_codes":[
		"a1bc0a0aa322ca"
	]
}

GET /suppliers/v2/postcodes/a1bc0a0aa322ca
{
	"01234",
	"01235",
	"01236"
}

Considerations

Postcodes and zipcodes are strings.  They will always use the qualification code "229", regardless of country.  Variations like "FSA" may exist with different qualification codes, but they will again use the same mechanism for reference codes.

We have chosen to reuse the key "condition_codes" in order to minimize the amount of effort necessary to update existing integrations.

The condition codes array will only contain one condition code if the query string parameter is invoked.

You should check the mod_on date of a quota to determine if the targeting has changed.  If the mod_on date has changed, you should check that the value of the post_code_ref has not changed.

The values in the "post_code_ref" list will not change - in the event of a change in targeting, this value will change.