Recipients & Providers

Understanding Recipients and Providers, advanced Prequel features

By default, Recipients (Export) and Providers (Import) are Prequel objects that are abstracted away from basic Prequel use cases. However, there are specific scenarios in which Recipients & Providers objects must be used.


Features or workflows that require the explicit use of the Recipient object:

  • Updating Product subscriptions for a given Destination
  • Adding more than one Destination for the same Recipient
  • Using schema-based tenanting
  • Using Role-Based Access Control on a Source

Updating Products for a given Destination

When adding a Destination for a given Recipient for the first time, Prequel provides a helpful shortcut to abstract away the need to create the Recipient beforehand (that is, if a Destination is created with a id_in_provider_system that has not been used, the Recipient with that id_in_provider_system is created behind the scenes).

However, when Products need to be updated for a Recipient, that update must happen on the Recipient object, using the PATCH /recipients/{recipient_id} endpoint.

Adding more than one Destination for the same Recipient

Because Prequel enforces a uniqueness constraint on the id_in_provider_system, to add more than one Destination for a given Recipient, the Destination must be created with the existing recipient_id instead of the id_in_provider_system.

Using schema-based tenanting

Prequel supports schema-based tenanting. To add a destination using schema-based tenanting, a recipient object with the correct schema identifier needs to be configured before the destination is created.

Using Role-Based Access Control on a Source

Prequel supports using specific source users for a given recipient's data. To add a specific set of credentials that should be used to access source data for a given recipient, you can use the POST /recipient-source-credentials endpoint.