Overview
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.
...
Code Block |
---|
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
...
- condition_
...
- codes has not changed.
- The values in
...
- a list will not change - in the event of a change in zip/postcode targeting,
...
- the reference list id will change.