0

In Journey Builder, I can select a Data Extension as my entry source, or an API event. I'm comfortable using Data Extensions. I just choose the DE I want and set up any contact filtering. But when I set up an API event, I do the exact same thing: select a Data Extension and apply contact filtering.

So my question is, what's the difference? Why would I use an API Event as my entry source instead of using an API (or a sql query or file import) to add data to a DE and then use that DE as my entry source? It seems like using an API event just limits my flexibility.

Improve this question

1 Answer 1

Reset to default
4

The crucial difference here is about the scheduling of the journey entry. When working with Data Extension entry event, you have these options for scheduling your journey: enter image description here

As you can see, none of them are "real time". I personally prefer the Automation link, as I mostly populate my journey data extensions in a Query Activity in an automation. E.g. the automation is scheduled for 7:30 every morning. The query fetches all subscribers who have birthday today, and appends them to the journey data extension. As soon as the query finishes, the journey gets triggered, and all the new contacts are injected into the journey. You can say it is "data before triggering".

When it comes to API entry event, you also create a data extension, but the contacts are not fetched from it according to schedule, but an API call sends all the journey data to a journey specific endpoint. These values are stored as a new record in this data extension, and contact gets injected into a journey.

Another key difference is, how many contacts get injected simultaneously into the journey. With data extension entry event, you inject all the new records since the last execution of the entry event. While with API event, you can only inject a single contact at a time.

It is important to observe the high water mark in data extension entry event,as described here: Journey Builder Entry Data Extension - this is also why you shouldn't use same data extension as entry for multiple journeys.

Improve this answer
2
  • Thank you! The scheduling aspect makes a lot of sense. About the high watermark issue: are you saying that it wouldn't apply to an API Entry event? Does that mean that new data is appended to the target data extension by the API, not updated? And if that's the case, is it safe to say that the DE for the journey can't have a primary key? If it did have one, adding a subscriber to the data more than once would violate the duplicate key rule. So the subscriber's existing record would need to be updated, which would cause the high watermark issue. Do I have all that right?
    – K K
    Commented Jun 4, 2020 at 20:23
  • You are entirely correct @KK
    – Lukas Lunow
    Commented Jun 4, 2020 at 20:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .