Skip to main content

A few days ago we started getting 400’s in response to list subscribe calls where we weren’t in the past. I’ve scrubbed these examples of PII

On August 27, we sent:

POST https://a.klaviyo.com/api/v2/list/list_identifer/subscribe?api_key=:censored:

{
  "profiles": l{
    "email": "first.last@gmail.com",
    "$first_name": "First",
    "$last_name": "Last",
    "$phone_number": "5191234567",
    "$city": "Kincardine",
    "$region": "Ontario",
    "$country": "Canada",
    "$zip": "N2Z 3A8"
  }]
}

which returned a 200 and subscribed the user to the list.

However, now, as of August 31, we send

POST https://a.klaviyo.com/api/v2/list/list_identifier/subscribe?api_key=:censored:

{
  "profiles": l{
    "email": "first_last@hotmail.com",
    "$first_name": "first",
    "$last_name": "last",
    "$phone_number": "5192345678",
    "$city": "Windsor",
    "$region": "Ontario",
    "$country": "Canada",
    "$zip": "N9H 2L3"
  }]
}

And we get back a 400 with the detail "+5199199294 is not a valid phone number.”
 

It seems like on Wednesday you changed the API and/or backend to not add a “+” instead of a “+1” when seeing Canada. It would be great to go back to the old behavior where supplying the Country field was sufficient to get the phone number into the database.

Hi @Zintegrations,

I don’t have any solid answers for you, but I wanted to chime in and express my frustration with the phone number validation on Klaviyo.

I posted this topic a few weeks ago: 

 

I didn’t get any concrete responses other than the following:

 

I see that you had reached out through our Community recently about an issue you were seeing with bulk loads that encountered errors due to a bad email/phone number. I've had a chance to touch base with my team about this, and we don't exactly have a list of values that aren't accepted. With that being said, Phone Numbers synced must be in E.164 format, and Emails must contain an @ to be considered valid.
 
There isn't any pre-built logic we have to exclude those invalid email/phone numbers. One suggestion would be to either build out, or work with your developers to build, conditional logic that will remove any profiles who don't have the accepted formatting I mentioned above. So long as this occurs prior to the bulk API request, then this should mitigate issues where the entire request fails for one bad value.

 

You might want to look into the E.164 format documentation. It’s not easy to read, but it seems relevant to your situation at least.

Hi,

I am facing exactly the same issue now. Below is my code. Any ideas what is the issue?

[
    'email' => $customerData['email'],
    'first_name' => $customerData['first_name'],
    'last_name' => $customerData['last_name'],
    'phone_number' => "+14155552671",
]

 

Hi @newday,

For you, the issue is definitely the `555` after the area code. Any number with XXX-555-XXXX is not considered a valid phone number (not just by Klaviyo).

Cheers,

Kevin.

Hi @newday,

For you, the issue is definitely the `555` after the area code. Any number with XXX-555-XXXX is not considered a valid phone number (not just by Klaviyo).

Cheers,

Kevin.

I have tried numbers without the 555 and yet not being accepted. What is your recommendation?

Oh okay! What’s the error you’re receiving? Do you have an error message?

Oh okay! What’s the error you’re receiving? Do you have an error message?

 

Here is the error:

 

{"errors":r
    {
       "id":"e277358a-30e8-4f3a-a1c7-fe88e7759eeb",
       "status":400,
       "code":"invalid",
       "title":"Invalid input.",
       "detail":"Invalid or unsupported phone number",
       "source":{
                    "pointer":"/data/attributes/phone_number"
       },
       "meta":{}}
]}

 

Having the same issue above.  Made a post here.  We have users typically adding a fake number on sign-up then fixing it later.  Wondering how to determine that when I create the profile.  Right now I’m not adding the phone at all but that’s a little frustrating, some are correct.
 

Hey though I would chime in here, I managed to get a reply on my post here.  Your number needs to not only be E.164 compliant but also a valid phone number.  Fake numbers will be reject with the message above.  So your workflow is going to have to include phone number verification as well, probably Twillio or something else.  Bit of a pain since we have a tonne of phone numbers unverified in our system now. 

Reply


Terms & Conditions