Get started with a free trial today
Already have an account? Sign in
Stitch’s Yotpo integration replicates data using theYotpo Core API. Refer to theSchema section for a list of objects available for replication.
A high-level look at Stitch's Yotpo (v2) integration, including release status, useful links, and the features supported in Stitch.
| STITCH | |||
| Release status | Released on September 20, 2019 | Supported by | |
| Stitch plan | Standard | API availability | Available |
| Singer GitHub repository | |||
| REPLICATION SETTINGS | |||
| Anchor Scheduling | Supported | Advanced Scheduling | Supported |
| Table-level reset | Unsupported | Configurable Replication Methods | Unsupported |
| DATA SELECTION | |||
| Table selection | Supported | Column selection | Unsupported |
| Select all | Supported | ||
| TRANSPARENCY | |||
| Extraction Logs | Supported | Loading Reports | Supported |
To set up Yotpo in Stitch, you need:
To be the Account Administrator in Yotpo.This is required to access your Yotpo API credentials.
Locate theAPI Credentials section:

Leave this page open for now - you’ll need it to complete the next step.
On the Stitch Dashboard page, click theAdd Integration button.
Click theYotpo icon.
Enter a name for the integration. This is the name that will display on the Stitch Dashboard for the integration; it’ll also be used to create the schema in your destination.
For example, the name “Stitch Yotpo” would create a schema calledstitch_yotpo in the destination.Note: Schema names cannot be changed after you save the integration.
The Sync Historical Data setting defines the starting date for your Yotpo integration. This means that dataequal to or newer than this date will be replicated to your data warehouse.
Change this setting if you want to replicate data beyond Yotpo’s default setting of1 year. For a detailed look at historical replication jobs, check out theSyncing Historical SaaS Data guide.
In theReplication Frequency section, you’ll create the integration’sreplication schedule. An integration’s replication schedule determines how often Stitch runs a replication job, and the time that job begins.
Yotpo integrations support the following replication scheduling methods:
Advanced Scheduling using Cron (Advanced or Premium plans only)
To keep your row usage low, consider setting the integration to replicate less frequently. See theUnderstanding and Reducing Your Row Usage guide for tips on reducing your usage.
The last step is to select the tables you want to replicate.Learn about the available tables for this integration.
Note: If a replication job is currently in progress, new selections won’t be used until the next job starts.
For Yotpo integrations, you can select:
**Individual tables **
All tables and columns
Click the tabs to view instructions for each selection method.
To track a table, click thecheckbox next to the table’s name. A blue checkmark means the table is set to replicate.
Click theTables to Replicate tab.
In the menu that displays, clickTrack all Tables and Fields:

After you finish setting up Yotpo, itsSync Status may show asPending on either the Stitch Dashboard or in the Integration Details page.
For a new integration, aPending status indicates that Stitch is in the process of scheduling the initial replication job for the integration.This may take some time to complete.
Initial replication jobs with Anchor Scheduling
If using Anchor Scheduling, an initial replication job may not kick off immediately. This depends on the selected Replication Frequency and Anchor Time. Refer to theAnchor Scheduling documentation for more information.
The first seven days of replication, beginning when data is first replicated, are free. Rows replicated from the new integration during this time won’t count towards your quota. Stitch offers this as a way of testing new integrations, measuring usage, and ensuring historical data volumes don’t quickly consume your quota.
Every time Stitch runs a replication job for Yotpo, the last 30 days’ worth of data will be replicated.
This is applicable to all tables in the integration.
Stitch replicates data in this way to account for updates made to existing records within the default attribution window of 30 days, thus ensuring you won’t make decisions based on stale (or false) data.As a result, you may see a higher number of replicated rows than what’s being generated in Yotpo.
Setting the Replication Frequency to a higher frequency - like 30 minutes - can result in re-replicating recent data and contribute to greater row usage. Replicating fewer tables or selecting a lower frequency can help keep your row count low.
Refer to the documentation for each of these tables in the next section for more info.
In the tabs below are examples of attribution windows behave during historical (initial) and ongoing replication jobs.
For historical and full re-replications of Yotpo data, Stitch will query for and extract data newer than or equal to the date defined in theStart Date field in the Integration Settings page.
TheStart Date, in conjunction with theAttribution Window, defines the minimum date Stitch should query for when extracting historical data. This is calculated as:
Start Date - Attribution Window = Minimum Extraction Date
Example
During the initial set up, theStart Date field is set to06/03/2017, orJune 3, 2017.
To account for the Attribution Window, Stitch would calculate theMinimum Extraction Date value as:2017-07-03 00:00:00 - 30 days = 2017-06-03 00:00:00
If you were to write a SQL query using this date for thereviews table, it might look like this:
SELECT*FROMyotpo.reviewsWHEREcreated_at>='2017-06-03 00:00:00'/* Min. Extraction Date */ORDERBYcreated_atFor ongoing replication jobs, Stitch will query for and extract data using the last saved maximum value in the table’s Replication Key column and the Attribution Window for the table.
Note: This applies to every replication job that takes place after the historical replication job.
Example
The last maximum saved Replication Key value for thereviews table is2017-10-01 00:00:00.
To account for the Attribution Window of 30 days, we’d subtract this from the last maximum saved Replication Key value:
2017-10-01 00:00:00 - 30 days = 2017-09-01 00:00:00
In this case, Stitch would query for and extract data that is newer than or equal to2017-09-01 00:00:00 and older than or equal to2017-10-01 00:00:00.
If this were a SQL query, it might look like this:
SELECT*FROMreviewsWHEREcreated_at>='2017-09-01 00:00:00'/* max Replication Key value - Attribution Window */ANDcreated_at<='2017-10-01 00:00:00'/* max Replication Key value from previous job */ORDERBYcreated_atSchemas and versioning
Schemas and naming conventions can change from version to version, so we recommend verifying your integration’s version before continuing.
The schema and info displayed below is forversion 2 of this integration.
This is the latest version of the Yotpo integration.
Table and column names in your destination
Depending on your destination, table and column names may not appear as they are outlined below.
For example: Object names are lowercased in Redshift (CusTomERs >customers), while case is maintained in PostgreSQL destinations (CusTomERs >CusTomERs). Refer to theLoading Guide for your destination for more info.
Thecollections table contains data about your store’s product groupings - collections - in your Yotpo account.
Key-based Incremental | |
Primary Key | yotpo_id |
Replication Key | updated_at |
| Useful links |
created_at DATE-TIME |
external_id STRING |
name STRING |
updated_at DATE-TIME |
yotpo_id INTEGER |
Theemails table contains data about every email sent from Yotpo.
When Stitch replicates data for this table, it will use an attribution window of 30 days to fetch updated email statistics such as opens, clicks, etc. This means that every time a replication job runs, the last 30 days’ worth of data will be replicated for this table.
Refer to theReplication section for more info and examples of how the attribution window is used to query for data.
Key-based Incremental | |
Primary Keys | email_address email_sent_timestamp |
Replication Key | email_sent_timestamp |
| Useful links |
| Join emails with | on |
|---|---|
| unsubscribers | emails.email_address = unsubscribers.user_email |
arrived_early_timestamp DATE-TIME |
clicked_through_timestamp DATE-TIME |
content_creation_timestamp DATE-TIME |
coupon_code STRING |
email_address STRING |
email_sent_timestamp DATE-TIME |
email_type STRING |
failed_timestamp DATE-TIME |
invalid_address_timestamp DATE-TIME |
marked_spam_timestamp DATE-TIME |
opened_timestamp DATE-TIME |
order_id STRING |
order_timestamp DATE-TIME |
platform STRING |
product_id STRING |
reminder_num NUMBER |
review_form STRING |
review_type STRING |
sku STRING |
trr_bundle_id STRING |
trr_bundle_subject STRING |
unsubscribed_timestamp DATE-TIME |
Theorder_fulfillments table contains data about fulfilled store orders in your Yotpo account.
Key-based Incremental | |
Primary Key | id |
Replication Key | updated_at |
| Useful links |
created_at DATE-TIME | ||||
external_id STRING | ||||
fulfilled_items ARRAY
| ||||
fulfillment_date DATE-TIME | ||||
id INTEGER | ||||
order_id STRING | ||||
shipment_info OBJECT
| ||||
status STRING | ||||
updated_at DATE-TIME |
Theorders table contains data about orders in your Yotpo account.
Key-based Incremental | |
Primary Key | yotpo_id |
Replication Key | order_date |
| Useful links |
billing_address OBJECT
| |||||||||||
cancellation OBJECT
| |||||||||||
checkout_token STRING | |||||||||||
created_at DATE-TIME | |||||||||||
currency STRING | |||||||||||
custom_properties OBJECT | |||||||||||
customer OBJECT
| |||||||||||
external_id STRING | |||||||||||
fulfillments ARRAY
| |||||||||||
landing_site_url STRING | |||||||||||
line_items ARRAY
| |||||||||||
order_date DATE-TIME | |||||||||||
order_name STRING | |||||||||||
payment_method STRING | |||||||||||
payment_status STRING | |||||||||||
shipping_address OBJECT
| |||||||||||
source STRING | |||||||||||
subtotal_price NUMBER | |||||||||||
total_price NUMBER | |||||||||||
updated_at DATE-TIME | |||||||||||
yotpo_id INTEGER |
Theproduct_reviews table contains data about reviews for a certain product.
Note: This table is similar to thereviews table, but also contains custom fields. If you don’t have or need custom product fields, you may only want to replicate thereviews table to prevent redundant data.
Key-based Incremental | |
Primary Key | id |
Replication Key | created_at |
| Useful links |
comment OBJECT
| |||||
content STRING | |||||
created_at DATE-TIME | |||||
custom_fields OBJECT | |||||
deleted BOOLEAN | |||||
domain_key STRING | |||||
id INTEGER | |||||
images_data ARRAY
| |||||
name STRING | |||||
product_id INTEGER | |||||
product_yotpo_id STRING | |||||
score NUMBER | |||||
sentiment NUMBER | |||||
source_review_id NUMBER | |||||
title STRING | |||||
user OBJECT
| |||||
verified_buyer BOOLEAN | |||||
votes_down INTEGER | |||||
votes_up INTEGER |
Theproduct_variants table contains data about product variations in your Yotpo account.
Key-based Incremental | |
Primary Key | yotpo_id |
Replication Key | updated_at |
| Useful links |
compare_at_price NUMBER | ||
created_at DATE-TIME | ||
currency STRING | ||
description STRING | ||
external_id STRING | ||
gtins ARRAY
| ||
image_url STRING | ||
inventory_quantity INTEGER | ||
is_discontinued BOOLEAN | ||
is_valid_url_format BOOLEAN | ||
name STRING | ||
options ARRAY
| ||
price NUMBER | ||
sku STRING | ||
updated_at DATE-TIME | ||
url STRING | ||
yotpo_id INTEGER | ||
yotpo_product_id INTEGER |
Theproducts table contains data about products in your Yotpo account.
Full Table | |
Primary Key | yotpo_id |
| Useful links |
| Join products with | on |
|---|---|
| product_reviews | products.yotpo_id = product_reviews.product_id |
brand STRING | |||
compare_at_price NUMBER | |||
created_at DATE-TIME | |||
currency STRING | |||
custom_properties OBJECT | |||
description STRING | |||
external_created_at DATE-TIME | |||
external_id STRING | |||
external_updated_at DATE-TIME | |||
group_name STRING | |||
gtins ARRAY
| |||
handle STRING | |||
image_url STRING | |||
inventory_quantity INTEGER | |||
is_discontinued BOOLEAN | |||
is_valid_url_format BOOLEAN | |||
mpn STRING | |||
name STRING | |||
price NUMBER | |||
sku STRING | |||
status STRING | |||
updated_at DATE-TIME | |||
url STRING | |||
yotpo_id INTEGER |
Thereviews table contains data about reviews.
Note: This table is similar to theproduct_reviews table, but doesn’t contain custom fields. If you have or need custom fields, you may want to only replicate theproduct_reviews table to prevent redundant data.
When Stitch replicates data for this table, it will use an attribution window of 30 days to fetch updated (or deleted) reviews. This means that every time a replication job runs, the last 30 days’ worth of data will be replicated for this table.
Refer to theReplication section for more info and examples of how the attribution window is used to query for data.
Key-based Incremental | |
Primary Key | id |
Replication Key | updated_at |
| Useful links |
| Join reviews with | on |
|---|---|
| product_reviews | reviews.id = product_reviews.source_review_id |
archived BOOLEAN |
content STRING |
created_at DATE-TIME |
deleted BOOLEAN |
STRING |
escalated BOOLEAN |
id INTEGER |
name STRING |
reviewer_type STRING |
score NUMBER |
sentiment NUMBER |
sku STRING |
title STRING |
updated_at DATE-TIME |
user_reference STRING |
votes_down NUMBER |
votes_up NUMBER |
Theunsubscribers table contains data about customers who unsubscribed from one of Yotpo’s emails.
Full Table | |
Primary Key | id |
| Useful links |
| Join unsubscribers with | on |
|---|---|
| emails | unsubscribers.user_email = emails.email_address |
email_type_id NUMBER |
id INTEGER |
unsubscirbed_by_name STRING |
user_email STRING |
| Related | Troubleshooting |
Did this article help? If you have questions or feedback, feel free tosubmit a pull request with your suggestions,open an issue on GitHub, orreach out to us.