Recipients & Providers

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.