Integrate a food and beverage platform
Learn how to integrate a food and beverage platform with Klaviyo.
Overview
This resource will help you as you build an integration between a food and beverage platform and Klaviyo. It will walk you through understanding the basics of the Klaviyo data model and run through important profile and event data use cases. Where relevant, there will be links to associated resources for deeper understanding.
Since Klaviyo allows data to come in all formats with our schema-less data architecture, it's important to follow best practices, such as creating top-level fields for segmentation. Check out our integration FAQ for more information.
Building an integration with Klaviyo
If you are a partner interested in building a Klaviyo app, explore our guide to joining the Klaviyo ecosystem.
Understanding Klaviyo
Data categories
Klaviyo separates information into three broad primary data categories — events, profiles, and objects. (This is a non-exhaustive list of data types in Klaviyo, but highlighting the most common use cases for hotel and travel brands)
Events
Events are extremely versatile, since they can be used to record any type of timestamped action and can include associated information. Metrics are events grouped by type.
Profiles
Profiles are people. You can use either an email, phone number, or (not recommended) a specified guest ID as a primary identifier. Klaviyo supports custom profile properties with the following data types: strings, integers, floats, dates, booleans, arrays/lists, or JSON (e.g., Birthday, Preferred Location, Dietary Restrictions).
Objects
Objects are stateful representations of your data. Objects enable you to map diverse data concepts into Klaviyo with a many-to-one relationship, like reservations.
Additional Data Categories
In Klaviyo, you can also use catalogs, web feeds, lists & segments, campaigns, and templates. Catalogs are supported through the Catalogs API or via a JSON feed. Web feeds are supported either through a JSON or XML endpoint. For an MVP (minimum viable product), we have not found these categories to be necessary, but can add value to your integration.
Since Klaviyo allows data to come in all formats with our schema-less data architecture, it's important to follow best practices, such as creating top-level fields for segmentation.
Data use cases
Data pushed into Klaviyo is used to personalize both the types of messages and the content within those messages that a profile receives. You can send messages through Klaviyo's supported channels (Email, Text Messaging, and Mobile Push) through Campaigns and Flows. Outside of messaging, profile and event information can be used for segmentation, personalized/dynamic content in messages, flow filtering, and personalized on-site content like forms.
Necessary events for integration
Below are all of the events restaurant integrations are using for success. We recommended all of the events in each relevant category to build an integration.
Profile and Consent Data
Profile Properties
Regardless of your use case, these are the most common profile properties that you'll want to pass into Klaviyo. Note that only email (recommended identifier), phone number, or external ID (not recommended identifier) are required.
Resources:
| Profile Property | Description |
|---|---|
| Email (Recommended as primary identifier) | The profile's valid email address (must be <= 100 characters) |
| First Name | First name |
| Last Name | Last name |
| Phone Number | Klaviyo's APIs only accepts the E.164 format (e.g., +15005550006) |
Example Profile Properties:
- First name
- Last name
- Phone number
- Street address
- City
- Organization
- Country
- State/Region
- External ID
- Tags
- Birthday
- Title
- Locale
- Gender
- PreferredLocation
Consent Data
Consent allows messages to be sent via the Klaviyo platform. Without syncing consent via your integration, consent will need to be captured outside the integration (either uploaded manually or gathered for all contacts in the list again). It is crucial that this connection be built if your platform collects consent in a compliant way.
If possible, it's important to collect both email and text message consent:
- At checkout
- On your website (via onsite forms)
- At the restaurant
Resources:
Collect email and text message consent via API
Bulk Subscribe Profiles
Create Client Subscription
| Consent Type | Description | Notes |
|---|---|---|
| Email consent (marketing) | Whether or not someone is consented to receive email marketing communication. | We highly encourage passing consent to Klaviyo. Please review the regulations for where your customers are located to ensure that you're staying compliant. |
| Text message consent (transactional and/or marketing) | Whether or not someone is consented to receive text message communication. Consent can be granted separately for marketing and transactional purposes. | This consent must be explicit and include disclosure language to be compliant with text message regulations. |
User Onsite Activity
These often come from injected Klaviyo javascript on ordering pages but could be webhooks/APIs as well. Historic sync is optional, but helpful.
Resources:
JavaScript Track API for onsite metrics
Use Cases:
- Trigger browse abandonment automation sequences based on guest behavior on your site
- Trigger abandoned checkout automation sequences when a guest does not complete an order
| Event | Description |
|---|---|
| Active on Site | This event occurs when a guest visits your website. |
| Viewed Menu | This event occurs when a guest views the menu. |
| Added to Cart | This event occurs when a guest adds an item to their cart. |
| Started Checkout | This event occurs when a guest begins the checkout process. |
Example Event Properties:
- MenuItem
- ItemPrice
- ItemURL
- ItemImage
- Tags
- RestaurantName
- RestaurantID
- PartySize
- CreatedDate
Online Ordering
Below are examples of the most common events coming from our Online Ordering integrations. Note that not all of these events are necessary and you can add additional ones for your use case.
Resources:
Integrate a business with brick-and-mortar locations
Event API Overview
Use Cases:
- Trigger post purchase transactional sequences (e.g. order confirmation)
- Trigger post purchase marketing automation sequences (e.g., upsell, winback)
- Filter marketing automation sequences based on items guests have ordered
- Analyzing and segmenting purchase behavior for individual line items within an order
- Factored into models for order prediction and customer lifetime value (CLV)
| Event | Description |
|---|---|
| Placed Order (most important) | This event is tracked when an order was placed and includes all of the product information about the items purchased, store information, and order details that can be used in messages. |
| Ordered Product | This event is tracked when a customer places an order, but a separate event is tracked for each item someone purchases. For example, if someone buys a coffee and a sandwich, 1 Placed Order event will be tracked along with 2 Ordered Product events; 1 Placed Order event for the purchase as a whole, and then 1 Ordered Product event for the coffee and 1 Ordered Product event for the sandwich. This is useful when creating behavioral segments based on product variant options and other detailed information that's not available in the Placed Order event. |
| Fulfilled Order | This event is tracked when an order is marked as "fulfilled" in your restaurant. The event Klaviyo tracks includes all product information regarding the items someone purchased including product names and images so you can use that information in purchase follow up emails. |
| Refunded Order | This event is tracked when a customer completes the checkout process in your restaurant and a payment is made, but the customer requests the payment to be returned. The event Klaviyo tracks includes all of the product information about the items someone purchased including product names, images, and variant information. |
| Closed Order | This event is tracked when an order is considered complete. |
| Adjusted Order | This event is tracked when an order has been fully or partially adjusted or refunded. |
| Cancelled Order | This event is tracked when an order was canceled by a user or the system. |
Example Event Properties:
- Value
- Timestamp
- Items
- ItemCount
- ItemCategories
- FulfillmentMethod
- OrderID
- DiscountApplied
- OrderingProvider
- RestaurantName
- RestaurantNumber
- NumberOfGuests
- PaymentType
- URL
- RefundAmount
- AdjustmentType
- AdjustmentReason
- CanceledReason
Reservations
Below are examples of the most common events coming from our Reservations integrations. Note that not all of these events are necessary and you can add additional ones for your use case. We recommend using events to capture critical points in the Reservation journey while using objects to store persistent data about a guest's reservation(s).
Resources:
Event API Overview
Custom Objects API Overview
Sync Reservations as Objects
Use Cases:
- Trigger post purchase transactional sequences (e.g. reservation confirmation)
- Trigger post purchase marketing automation sequences (e.g., upsell, winback)
- Analyzing and segmenting reservation behavior for guests
| Event | Description |
|---|---|
| Created Reservation (most important) | This event occurs when a guest starts the reservation process. |
| Confirmed Reservation | This event occurs when a guest confirms the reservation. |
| Completed Reservation | This event occurs when a guest is checked into the restaurant after arriving for their reservation. |
| Cancelled Reservation | This event occurs when a guest cancels a reservation. |
| No Showed Reservation | This event occurs when a guest is not checked in for their reservation at the restaurant after the specified reservation time. |
| Object | Description |
| Reservation | This object is used to store data about a guest's reservation(s). |
Example Event Properties:
- CreatedDate
- ScheduledTime
- TableNumber
- PartySize
- Tags
- ReservationSource
- ReservationNotes
- RestaurantID
- RestaurantName
- ReservationID
- CanceledDate
Example Object Properties:
- ScheduledTime
- PartySize
- RestaurantID
- RestaurantName
- ReservationSource
- ReservationNotes
- TableNumber
- Status
- Tags
Loyalty
Out of all of the apps for food and beverage businesses, loyalty apps differ the most based on how the structure is set up. Below are the most common loyalty events, but feel free to customize based on what's important to your application.
Resources:
Use Cases:
- Trigger post redemption transactional sequences (e.g. order confirmation, new tier welcome)
- Trigger post welcome marketing automation sequences (e.g., encouraging loyalty sign up)
| Event | Description |
|---|---|
| Signed Up (most important) | This event occurs when a customer signs up for your loyalty program. |
| Created Redemption | These events happen when a customer updates a redemption. |
| Updated Redemption | These events happen when a customer updates a redemption. |
| Applied Redemption | This event is generated when a redemption gets applied. |
| Checked-In | These events happen when a user checks in to the loyalty program or for a specific gift. |
| Earned Reward | This includes user rewards gifted/issued events triggered as they happen. |
| Converted Points to Reward | This event is triggered when the points earned by a customer are turned into rewards. |
| Completed Card | This event is generated when a guest's loyalty card gets completed. |
Example Event Properties:
- LocationID
- LocationName
- CreatedDate
- ExpirationDate
- Barcode
- RedemptionCode
- RewardID
- DiscountAmount
- RewardType
- RewardName
- PointsSpent
- PointsEarned
- AdditionalProperties
- UpdatedDate
- RedeemedPoints
- RedemptionType
Common gotchas
The primary gotchas are:
- Using the wrong naming convention so dynamic content does not populate correctly
- Nesting data so it is unreachable using segmentation
Follow this Identify common gotchas article to optimize your integration.
Updated about 7 hours ago