Solved

API - Back in Stock "Open" Events

  • 15 April 2021
  • 5 replies
  • 36 views

Badge

Hi,

 

Is it possible, via the API to get any Back in Stock notifications, which are still waiting to be sent? I know I can get the individual events, but there is nothing within the event datas to indicate whether the notification has actually been processed.

I am looking to build an internal report which, for each SKU in out catalogue, lists the number of people awaiting a notification.

 

Cheers,

Rob

icon

Best answer by dov.derin 16 April 2021, 22:37

Hi @TORRO,

Thank you for sharing your question with our Klaviyo Community.

We do not currently have a way to directly pull this information through the API. However, you can refer to our documentation here outlining how to gather these users via a segment. From there, you can export them to a .csv file.

Thanks and have a great weekend.

View original

5 replies

Userlevel 4
Badge +3

Hi @TORRO,

Thank you for sharing your question with our Klaviyo Community.

We do not currently have a way to directly pull this information through the API. However, you can refer to our documentation here outlining how to gather these users via a segment. From there, you can export them to a .csv file.

Thanks and have a great weekend.

Badge

Thank you for the suggestion but unfortunately that doesn’t suit our needs. We were wanting to create a report in our own internal dashboard system which shows the current state of BIS notifications for our product catalogue.

 

our warehouse team do not have access to Klaviyo so wanted to extract the data at set intervals so they can use this information for stock allocation.

ideally, events such as BIS notifications would have a state (active/inactive, open/closed) which is updated when the notification is actually sent. Could this be a possible future feature?

Badge

Wew have a similar use-case for back in stock notifications, so I’ve thought about this a bit…

I understand that your internal system tracks back-in-stock notification requests, but you are trying to determine if customers on this list have received an email.

Can’t this work?

  1. Customer signs up for BIS notification which internal system tracks
  2. Send klaviyo event via API
  3. Add user to “Pending Product Notification” (or some such) list either by using list API or flow
  4. Use flow to email customer with BIS and remove customer from pending notification list
  5. On your backend match internal customers against Klaviyo lists using list API call

*sort* of falls apart for customers with multiple back in stock notifications...but...some more thinking you might be able to get around that…

FWIW we do all this internally until the final event call which triggers the email flow.  So if the event is triggered we assume the email has been delivered.

Badge

Hi, 

 

Thanks for the suggestion. The BIS function is provided using the Klaviyo integration code for Shopify we our internal system is never involved. I could get the events from the API and possibly some flow stats and match on customer email but as you say a customer might have multiple notifications scheduled.

My other method was to simply grab all BIS events and then in my report the team would have to use a date to show number of people who have signed up “since” the data selected (which could be based on the last date of purchase) but the report would then be much less robust as it would have to be done at individual product level rather than an full catalogue overview.

I’ll keep thinking and see if there is a workable solution.

Cheers,
Rob

Userlevel 6
Badge +5

Hi Rob @TORRO

Ah, it makes sense that you’d want to extract data for stocking allocation if your warehouse team doesn’t have access to Klaviyo data. As @dov.derin mentioned, this isn’t something that is capable today, but I can certainly include this as a feature request to our teams for consideration. I was also thinking that the method you mentioned above re: using a report that pulls in a date to show the number of people who have signed up since could work, but it does feel clunkier, especially having to do that from a product level. 

If there’s an update from my team with this feature request, I’ll share it to this thread. Additionally, if there are any other solutions my team (or others in the Community!) think of, I’ll be sure to include here. Thanks @cdetdi for sharing your thoughts on a potential solution! 

Cheers, 
-Cass.

Reply