Skip to main content
Solved

Create Event API does not work as expected since revision v2023-07-15


Forum|alt.badge.img

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!

Best answer by Kim Strauch

@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!

View original
Did this topic or the replies in the thread help you find an answer to your question?

12 replies

Brian Turcotte
Forum|alt.badge.img+37

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


  • Contributor I
  • 3 replies
  • June 6, 2024

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


jeremyroberts
Contributor IV
Forum|alt.badge.img+4
Brian Turcotte wrote:


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.

  • Contributor I
  • 2 replies
  • June 27, 2024

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

Kim Strauch
Klaviyo Employee
Forum|alt.badge.img+9
  • Klaviyo Employee
  • 91 replies
  • June 28, 2024

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? 


  • Contributor I
  • 3 replies
  • June 28, 2024

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


Kim Strauch
Klaviyo Employee
Forum|alt.badge.img+9
  • Klaviyo Employee
  • 91 replies
  • June 28, 2024

@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? 


  • Contributor I
  • 3 replies
  • June 28, 2024

@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 :) 


Kim Strauch
Klaviyo Employee
Forum|alt.badge.img+9
  • Klaviyo Employee
  • 91 replies
  • Answer
  • July 1, 2024

@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!


Kim Strauch
Klaviyo Employee
Forum|alt.badge.img+9
  • Klaviyo Employee
  • 91 replies
  • July 1, 2024

@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!


Forum|alt.badge.img
  • Contributor I
  • 1 reply
  • July 25, 2024

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


  • Contributor I
  • 2 replies
  • July 25, 2024

@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)


Did this topic or the replies in the thread help you find an answer to your question?