Recharge (Edge)

Configure Recharge as a Source in your Pipeline

Perform the following steps to configure your Recharge Source:

1. Click Pipelines in the Navigation Bar.

2. Click + Create Pipeline in the Pipelines List View.

3. On the Select Source Type page, select Recharge.

4. On the Select Destination Type page, select the type of Destination you want to use.

5. On the Select Pipeline Type page, click Edge, and then click Continue.

   This page appears only if the selected Destination type is supported in Edge and your Team has an existing Recharge Pipeline with the same Destination type. Otherwise, you can proceed to create an Edge Pipeline.

6. In the Configure Source screen, specify the following:

   

   • Source Name: A unique name for your Source, not exceeding 255 characters. For example, Recharge Source.

   • In the Connect to your Recharge account section, specify the following:

     • API Token: The API token that you obtained from your Recharge account. Hevo uses this token to authenticate requests to the Recharge Merchant API and to automatically register the webhooks it needs to capture deleted records, Payment Method changes, and Checkout data.

7. Click Test & Continue to test the connection to your Recharge Source. Once the test is successful, you can proceed to set up your Destination.

   Note: If the API token does not have the scope for some objects, the test succeeds with a warning, and those objects are shown as inaccessible on the Configure Objects page. If the token has none of the required scopes, the test fails.

Data Replication

Hevo replicates data for all the objects selected on the Configure Objects page during Pipeline creation. By default, all supported objects and their available fields are selected. However, you can modify this selection while creating or editing the Pipeline.

Selecting a parent object automatically includes all its associated child objects for replication. However, you can select or deselect the child objects individually.

Hevo ingests the following types of data from your Source objects:

• Historical Data: The first run of the Pipeline ingests all available historical data for the selected objects and loads it into the Destination.

• Incremental Data: Once the historical load is complete, new and updated records for objects are ingested as per the sync frequency.

For the following objects, Hevo ingests the entire data during each Pipeline run:

• Collection

• Collection Product

• Credit Account

• Metafield

• Product

For all other objects, Hevo ingests only the incremental data in subsequent Pipeline runs.

Note:

• For the Payment Method object, incremental data is captured through Recharge webhooks. Hevo registers these webhooks automatically when the Pipeline runs. After Hevo registers a webhook, it sends a test event from Recharge to confirm that the webhook can reach Hevo. If the test event does not reach Hevo within 240 seconds, the Pipeline run fails, and Hevo tries again in the next run.

• For the Checkout object, Hevo ingests data only through Recharge webhooks, because Recharge does not provide an API to list checkouts. As a result, Hevo does not ingest historical data for this object. It ingests only the checkouts that are created or updated after it registers the webhooks. If Hevo does not read a checkout event within 24 hours, for example, because the Pipeline is paused, the event is lost, and a resync cannot recover it.

• For the Charge and Customer objects, Hevo also ingests the data of the previous day once every 24 hours, to capture updates that Recharge makes with a delay.

• For the Customer Delivery Schedule Order and Customer Delivery Schedule Order Line Item objects, Hevo ingests the delivery schedules of all customers once every 24 hours. In the other Pipeline runs, Hevo ingests the delivery schedules of only the customers whose data has changed.

• Hevo ingests the Subscription, Subscription History, and Subscription UTM Tag objects using the same API call. As a result, if the ingestion of one of these objects fails, for example, because of a rate limit or server error that persists after retries, all three objects fail in that run. The other objects continue to be ingested, and the next Pipeline run ingests these objects from their last saved offset.

Recharge enforces a rate limit on the number of requests that can be made to its API in a given period of time. A store can make up to 40 requests at once, after which requests are allowed at a rate of 2 per second. This limit is shared by all the Pipelines and apps that use the store. Hevo paces its requests to stay within the limit and leaves room for the requests of other apps. As a result, a large sync proceeds at about 2 requests per second, and more slowly when other apps or Pipelines use the same store. If the limit is exceeded, a rate limit exception occurs. To understand how Hevo handles such scenarios, read Handling Rate Limit Exceptions.

Note: You can create a Pipeline with this Source using either the Merge or the Append load mode. Merge is the default load mode, and you can change the load mode for each object. If an object uses the Append load mode, its Destination table can contain duplicate records because of the following:

• Each incremental Pipeline run starts 5 minutes before the end of the previous run, so the records updated in those 5 minutes are ingested again. For the objects ingested based on the update or creation time of records, the records with the latest timestamp of the previous run, and their child records, are also ingested again in each run.

• For the Charge and Customer objects, the data of the previous day is ingested again once every 24 hours.

• For the Collection, Collection Product, Credit Account, Metafield, and Product objects, and the child objects of Product, the entire data is ingested in each Pipeline run.

• For the Customer Delivery Schedule Order and Customer Delivery Schedule Order Line Item objects, the delivery schedules of all customers are ingested again at least once every 24 hours.

• Recharge can send a webhook event more than once. Each event is added as a separate record. For example, a deleted record can have two or more delete records.

• Each resync of an object ingests its data again. For the Event object, a resync ingests the events of the last 7 days again.

If you change an object from Append to Merge, resync the object with Drop and Load to remove the duplicate records. However, you cannot do this for the Checkout object and the Charge object and its child objects, because the Checkout object cannot be resynced, and a resync of the Charge object permanently removes the charges older than 90 days. For these objects, remove the duplicate records in the Destination instead. For the Checkout object, keep the latest record of each checkout token. For the child objects of the Charge object, keep the records of the latest load of each charge. Read Source Considerations.

Schema and Primary Keys

Hevo uses the following schema to upload the records to the Destination. For a detailed view of the objects, fields, and relationships, click the ERD.

Click to view ERD

Data Model

The following is the list of tables (objects) that are created at the Destination when you run the Pipeline: