> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prequel.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Recipients

> Understanding Recipients

**Recipients** represent a unique entity you are exporting data to with Prequel. Recipients most often represent a customer, but there may be use cases to represent a recipient as a unique tenant within a customer account, such as a project. For more on tenanting strategy with Recipients, continue reading below.

Every Prequel Destination is required to have a Recipient, which defines what data models and product(s) a customer should receive.

<Frame>
  ![](https://storage.googleapis.com/prequel_docs/images/prequel-recipients-and-products.png)
</Frame>

### What is `id_in_provider_system`

`id_in_provider_system` refers to the recipient's identifier by which data will be filtered per organization. In other words, it is the link between a Prequel Recipient and the corresponding identifier in the data source. The value assigned to this key will be matched against the values under the `organization_id` column provided for every table.

### Resolving multiple recipients and destinations

Prequel enforces a key rules on uniqueness of Recipients and Destinations:

* Multiple Recipients cannot point to the same Destination. Prequel's [change detection](/export/features/change-detection) logic relies on guarantees of a destination's state on any given transfer, such that writing multiple recipients' data to the same table can cause non-deterministic transfer behavior.
  * To write data from multiple recipients to the same database or warehouse, it is required that one Prequel Destination is defined for each Recipient, where **each Destination must have a unique schema** to avoid collisions.
* Each `id_in_provider_system` must be unique.

### 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. Read more about multi-tenancy in Prequel here: [Multi-tenancy](/export/concepts/multi-tenancy).

### 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.

### 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](/export/api-reference/recipient-source-credentials/create-source-credential-for-a-recipient).