Skip to main content

Currently, I am using API revision v2023-06-15, and everything works fine for me in this revision.

However, I want to upgrade my service to use the latest stable revision (v2024-02-15), but it seems it does not work as expected.

The functionality of the APIs (Client and API) to create new events in Klaviyo within revision v2023-06-15 is particularly advantageous. In this version, a single request can achieve the following actions:

  • Create or update a profile based on External ID, Email, and/or Phone Number.
  • Create an event and link it with the respective profile.

However, it's worth noting that with the newer API revisions, despite the request returning a successful status code 202 Accepted, the event and profile are not created or updated as expected.

 

Example using revision v2023-06-15 (working):

curl --request POST \
--url https://a.klaviyo.com/api/events/ \
--header 'Accept: application/json' \
--header 'Authorization: Klaviyo-API-Key XXXXXXXXXX' \
--header 'Content-Type: application/json' \
--header 'revision: 2023-06-15' \
--data '{
"data": {
"type": "event",
"attributes": {
"metric": {
"name": "Custom Event Name"
},
"properties": {
"custom": "Custom Event Property",
"value_currency": "USD"
},
"value": 10,
"profile": {
"$email": "email@example.com",
"$id": "ExternalProfileID",
"$first_name": "John",
"$last_name": "Doe",
"any": "Custom Profile Property"
}
}
}
}'

 

Example using the latest revision v2024-02-15 (not working):

curl --request POST \
--url https://a.klaviyo.com/api/events/ \
--header 'Accept: application/json' \
--header 'Authorization: Klaviyo-API-Key XXXXXXXXXX' \
--header 'Content-Type: application/json' \
--header 'revision: 2024-02-15' \
--data '{
"data": {
"type": "event",
"attributes": {
"metric": {
"data": {
"type": "metric",
"attributes": {
"name": "Custom Event Name"
}
}
},
"properties": {
"custom": "Custom Event Property"
},
"value": 10,
"value_currency": "USD",
"profile": {
"data": {
"type": "profile",
"attributes": {
"email": "email@example.com",
"external_id": "ExternalProfileID",
"first_name": "John",
"last_name": "Doe",
"properties": {
"any": "Custom Profile Property"
}
}
}
}
}
}
}'

API documentation:

Am I doing something wrong with the new API revisions or misunderstanding about its concepts and usages?

Please help!

Hi @an-nguyen-codeleap!

My apologies for the delay here! I’m going to check on this internally and I’ll update the thread shortly!

Best,
Brian


I can confirm that this issue still persists in v2024-05-15, for both client and api endpoints. The response is 202 OK Accepted, but the submitted profile and event do not appear in the dashboard.

I have been contacted by several merchants who were given dire warnings about updating their API calls before the end of June 2024, so per Klaviyo’s suggestion I am trying to use the latest stable API release. But this severe issue will force usage of v2023-06-15 instead, which has a planned retirement of June 15, 2025 - requiring yet again another update of the JSON data structure to be posted.

https://developers.klaviyo.com/en/v2023-07-15/docs/api_versioning_and_deprecation_policy#api-lifecycle



My apologies for the delay here! I’m going to check on this internally and I’ll update the thread shortly!

Best,
Brian

Hi Brian,
Followup please?
My dev is telling me this issue still persists in v2024-05-15

The Mechanic library task has been updated to use Klaviyo API revision v2023-06-15, as that is the latest version that does not have the event data submission bug.

Hi @Brian Turcotte ,

 

Is there any update on this issue? This took me more hours than it should have to implement for my company, and I was only successful because I found this post. Having the new Create Event endpoint so thoroughly documented, for it to not be working, is misleading and extremely frustrating. Until this issue is fixed, it’s be better for all articles regarding the migration from the legacy API, to reference the 2023-06-15 version, at least for Events. I’m thinking about these posts in particular:

As far as I’ve seen, the latest working version of the POST /event endpoint is 2023-06-15. The biggest difference that I see in the 2023-07-15 and onward releases is the use of nested “data” objects in the JSON body (see samples below). The API still returns a 202 Accepted response for the calls, but the event is not captured on the profile in Klaviyo. As per the documentation, “Successful response indicates that the event was validated and submitted for processing, but does not guarantee that processing is complete.”, so I believe this is an issue with the server’s processing of the new data structure. 

 

Revision Body Result
2023-06-15 {
  "data": {
        "type": "event",
        "attributes": {
            "profile": {
                "$email" : "rwilliams@example.com"
            },
            "metric": {
                "name": "Custom Event"
            },
            "properties" : {
                "Revision" : "2023-06-15"
            }
        }
    }
}
SUCCESS
2023-07-15 {
  "data": {
        "type": "event",
        "attributes": {
            "profile": {
                "data": {
                    "type" : "profile",
                    "attributes" : {
                        "email" : "rwilliams@example.com"
                    }
                }
            },
            "metric": {
                "data" : {
                    "type" : "metric",
                    "attributes" : {
                        "name" : "Custom Event"
                    }
                }
            },
            "properties" : {
                "Revision" : "2023-07-15"
            }
        }
    }
}
FAILED

Hey all, so sorry for the delay and apologies for this very frustrating bug.  The problem here is the “@example.com” domain, as discussed on this post: 

 

“@example.com” is being processed in revisions 2023-06-15 and prior (because it’s coming in under a field called “$email”); however it’s being skipped in revisions 2023-07-15 and after and dropped silently as it’s being processed async. As mentioned in the other post, “@example.com” and “@test.com” are not going to be used on valid emails so there isn’t a great use case for these being persisted to Klaviyo accounts. 

@wthomas @devtek @an-nguyen-codeleap can you please update your testing to use email addresses not ending in “@example.com” or “@test.com” and confirm you’re seeing the correct behavior? 


I encountered this problem with actual, live email domains. I will run a quick test to verify once again, and report back here.


@devtek, if you are able to reproduce this error with a real email domain, can you please share your 6-character public API key and an example request payload for our team to take a closer look? 


@Kim Strauch I just reran a couple of tests against 2023-07-15 and 2024-06-15, and confirm that they behave as you have stated. Emails using @example never show up and there is no error indication; however, real email domains DO generate an event.

I tried to review my automation logs from June 6th to confirm that I was indeed testing the migration on various merchant shops with live email domains, however the logs on the service I use roll off after 14 days.

Nonetheless, I am very happy that this is working as intended (barring the unexpected filter).

To help alleviate what seems like might be a common issue for developers, might I suggest doing one of the following actions:

  • Allow test email domains to appear in the data without silently tossing them. These “non-functional” domains are a long-standing mechanism for testing email-related functionality without concern for unintended emails being sent ~OR ~
  • Clearly indicate in the API docs why an event might never appear for this express reason, and list exactly which email domains this filter applies to.

Thank you for following up here and for the consideration :) 


@devtek thanks for checking. Sorry again for the trouble.

100%. We’ll look into removing the email filter. In the interim, we will update our API docs to add some troubleshooting tips for events not showing up, exactly as you’re suggesting. I’ll update this post once we’ve updated the docs!


@devtek, we just added a “Troubleshooting” section to our Events API overview here that provides details on this error scenario; we’ll make sure to add additional references to this from the API reference pages themselves. 

We appreciate your feedback!


Hello I am actually encountering this issue with regular emails as well. Im getting a 202 back from creating the event but when you view the profiles there’s no event for them


@tadpole1998 can you confirm the API-Version you’re using and provide the payload you’re sending (omitting any confidential data, but please provide the domain on any emails included, if possible)


Reply