Default Phone Formats

David Lacey

We are in Auistralia using SKYAPI to enter constituent data. When we enter Australian telephone numbers, it all works fine. In RE database view, all our phone types are set to Type as Telephone Number, and format as <None>. We have seen that unformatted numbers such as 0212345678 entered over the API appear as a formatted number (02)1234 5678 in the database despite no format being defined in the Phone Type. This has not been problematic, a nice bonus even. And we also see that numbers entered by hand in the database view are not validated. But  now we are extending our operations to New Zealand, and their number formats are different, and even have varying lengths. All these are rejected by the API. How can we turn off what appears to be a built-in default Australian validation within the API so we can handle non-Aus numbers? Thanks

Steven Cinquegrana

Hi David,


I got your PM but thought I'd reply here as this question has come up before and probably will again.


If you set your phone number format to <None> (Database View/Config/Tables/Phone Types) and also provide a phone number via the API with a country code prefix - eg +44, +62 - you should be ok.


I added these two test numbers and it worked fine (Mexico and Australia with our sample database set up for US defaults):



Disclaimer: I used our SKYLib.NET library to make the calls via the API rather than use Postman or Curl:

    SkyLib.Api.Constituent.CreateConstituentPhone(New Constituent.Model.PhoneAdd(ConstituentId:="12345", Type:="Business", Number:="+5214423182343"))


NOTE: Using this setup means that you lose your preset phone format but this is the only way I've got it to work. (Also, if you include a country code and it is the same as your configuration - eg +61/Australia - then the number will have the country code stripped off and it will be locally formated.)


I hope that helps.


Cheers,

Steve Cinquegrana | CEO and Principal Developer | Protégé Solutions

 

David Lacey

Thanks Steve - that r4eally makes it clear, and solves our problem