Solved

When to use phone_number attribute versus $phone_number property?

  • 5 June 2023
  • 5 replies
  • 179 views

Badge +5

I’m working on migrating to the new API and noticed that when I use the server-side profile create(POST) or update(PATCH) and put “phone_number” as an attribute, I get back “Error: Conflict” if that phone number already exists in my Klaviyo account.  However, if I instead put the phone number in the properties list as “$phone_number”, it updates the phone number just fine and allows duplicates.

I’m inclined to use the latter since the e-commerce platform I’m integrating DOES allow duplicate phone numbers, but I want to make sure I’m not missing something or this isn’t going to be “fixed” down the road to start throwing errors.

I guess broadly, what’s the difference between using attributes versus the “$” prefixed versions in properties?  There seems to be similar behavior for the “email” attribute versus “$email” property.

Edit: Actually, a bigger issue is that on the old API, I could update $email and $phone_number properties by just posting with a profile ID and nothing in the payload except those properties.  On the new API, if I try to do that, it says “A profile with id XYZ does not exist.” unless I put either “email” or “phone_number” in the attributes.  But if I do that, I run into the “Error: Conflict” if the email/phone already exists.

The scenario is that a customer has uploaded a list from some event and bob@builder.com is added to Klaviyo.  Then that customer goes to the website and registers, but accidentally types “bobb” with two b’s.  My integration happily creates his profile in Klaviyo with the typo.  He realizes he messed up, so he changes his email address, then my integration tries to update the email and gets “Error: Conflict” because that email address already exists in Klaviyo.  In the old API, as long as I sent an external ID (just called “id” in the old API), that took priority as the identifier and it would have allowed the update.

icon

Best answer by Brian Turcotte 26 June 2023, 14:24

View original

5 replies

Userlevel 7
Badge +36

Hi @Digimatic!

 

I’m going to check on this with Engineering, and I will update the thread as soon as possible!

 

Best,

Brian

Badge +5

@Brian Turcotte any luck?

Userlevel 7
Badge +36

Hi @Digimatic!

My apologies for the delay here! 

 

“$”-prefix attributes are actually deprecated versions of the new attributes.  They were required in previous APIs since everything was sent in a large bundle (top level attributes like email/phone and custom properties).

 

 So if you sent this request:

{
"email": "test"
}

 

There was no way for Klaviyo to tell if you wanted to set the profile email to "test", or to create a custom property called "email".

 

So originally, the ‘$’ was a way for Klaviyo to differentiate between custom and native properties.
 

In new APIs, we split out these properties into different data structures, so you can submit top level and custom properties separately:

{
"email": "test",
"properties": { # custom properties
"email": other"
}
}

This removes the need for these custom/exception properties with the dollar signs.
 

The answer to the second half of your question is that the V3 APIs more-strictly validate against duplicate profiles, so before there were circumstances where you could enter in duplicate profiles (usually by accident), we've closed those holes to prevent duplicate profiles in most cases (if using V3).

 

I hope this helps to clarify!

- Brian

Badge +5

Thanks @Brian Turcotte!  This is very helpful and makes total sense.  I’ll migrate away from the “$” prefix and figure out something on my end to handle errors due to duplicate profile data.  That seems reasonable.

Userlevel 7
Badge +36

Hi @Digimatic!

Glad to hear it! Thanks so much for raising this with the Community, I think it’ll be useful for other members that come across the same issue.

 

- Brian

Reply