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.
Updated 4 months ago