@Dominik_Klein @John_Borelli
The Slovakia issue should be resolved now. Let us know if you continue to experience problems with this.
1 Like
The list of states is useful for those living in America, I assume anything in this repository is usable, for other countries?
Sorry to revive an old thread but it seems a relevant place.
What would cause the following address to be invalid when it provides a valid postcode, region, and country-code?
{
"country_code": "GBR",
"line1": "Queen Street",
"region": "GB-KHL",
"locality": "Hull",
"zip_code": "HU11UU"
}
The API response messages can often vague and not very helpful
{
"message": "Address Field is invalid"
}
If I add line2 I get a response code of 400 with error message
{
"message": "Input could not be converted to a valid request"
}
However it’s not that the rest of the request has an error in it, as if I remove the addresses field, the PUT request goes through fine with a 201.
The request looks as follows, with some of the values swapped out.
{
"addresses": [
{
"country_code": "GBR",
"line1": "Queen Street",
"line2"; "test",
"region": "GB-KHL",
"locality": "Hull",
"zip_code": "HU11UU"
}
],
"email_addresses": [
{
"email": "foo@bar.com",
"field": "EMAIL1"
}
],
"duplicate_option": "Email",
"family_name": "Bar",
"given_name": "Foo",
"lead_source_id": 0,
"middle_name": "Fooba",
"owner_id": 0,
"phone_numbers": [
{
"extension": "",
"field": "PHONE1",
"number": "12345678912",
"type": ""
}
],
"source_type": "API"
}
Hi @Adam_King1, there’s a bug in our documentation right now that is omitting the field property from the address object. I believe adding "field": "BILLING" to your address object will do the trick. The other valid values are SHIPPING and OTHER.
Ah, I did wonder why the address type wasn’t required.
No worries, though, that seems to have done it; thanks for the help @Nicholas_Trecina
I am wondering if its possible to add the option for all caps country names to be recognized in the billing address country field? We have an integration with netFORUM and the countries are all caps but when they get sent to IS its not recognizing them and marking them as (invalid) which causes the timezone field to not work. You can see in this image for one of our Australia members .
it does somehow still recognize the country even though its marked as invalid because if I go into Contacts>search by address> choose Australia> I get 3k results and Jacqui is listed in the results
i fixed this problem send it mostly the same structure but I put “field”: BILLING insted of “field”: “BILLING”. i hope it does work to you or somebody else.
It’s really frustrating that you adopted ISO3 over ISO2 like the rest of the world.
However, if anybody needs to convert like I do, then this might be helpful for you: http://country.io/iso3.json
Is there any documentation on which Countries on the list have regions forced to a specific format? i.e. we’re parsing out the Region/State for US, but we want to make sure we’re also including any proper formatting for countries that also have specific formats that are validated for their regions.
Hello, we are using Keap and Woocommerce - our plugin sends over the contact and order details. We are running into issues with some orders (eg. New Zealand) will not import. I can see there is a discrepancy as WooCommerce sends over a 2 digit Country Code (Alpha 2) and Keap rejects this as it is expecting a 3 digit code (Alpha 3) for country. Has Keap not been updated to accept both codes? I am not a developer but hoping this is a bug and should be updated by Keap. Any feedback? Thanks!