> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nekt.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Venda Válida as a data source
> Bring data from Venda Válida to your Lakehouse.
Venda Válida is a Brazilian sales-recovery platform that e-commerce operations use to confirm, retain and recover orders: it reaches customers by call, SMS and e-mail after a checkout is abandoned or a payment is not identified, and records every interaction in its CRM. The connector extracts the customer base of your business together with the campaign events and the orders registered for each customer, so you can measure recovery in your Lakehouse.
Venda Válida does not issue credentials on its own platform — your Venda Válida account manager provides both the API key and the Business ID.
## Configuring Venda Válida as a Source
In the [Sources](https://app.nekt.ai/sources) tab, click on the "Add source" button located on the top right of your screen. Then, select the Venda Válida option from the list of connectors.
Click **Next** and you'll be prompted to add your access.
### 1. Add account access
Venda Válida authenticates with an **API key** sent in the `API-KEY` header, always accompanied by the **Business ID** of the account the data belongs to.
Both values are issued by your Venda Válida account manager — there is no screen in the platform to generate them. Request them by e-mail at `suporte@vendavalida.com.br` or through your usual contact, asking for access to the **API pública de clientes** (`customer-api.vendavalida.com.br`). The same key is used by Venda Válida's own CRM integration, so you may already have it.
A key only reads the business it was issued for. If your operation has more than one business registered in Venda Válida, create one source per Business ID.
The following configurations are available:
* **API Key**: the key issued by your account manager. Required.
* **Business ID**: the identifier of your business inside Venda Válida, issued together with the key. It looks like `9aebf798-3daf-3c8b-802e-01bc7abd3e54`. Required.
* **Initial sync date**: the earliest date from which records will be synced. Leave it empty to extract the full history.
* **Tags**: a comma-separated list of Venda Válida tags, such as `promocao_de_aniversario,schedule_checkout_abandonment`. When filled, only customers carrying one of these tags are extracted. Leave it empty to extract every customer.
* **Window days**: the size, in days, of each date range requested from Venda Válida. The API requires a start and an end date on every call, so the connector walks the history in slices of this size. The default of 30 fits every account we know of.
* **Lookback days**: how many days are re-read before the last sync point on every run, so a customer changed right after a sync is still picked up. The default is 30; lowering it increases the risk of missing a late change.
* **Requests per second**: how fast the connector may call Venda Válida. The default of 5 is deliberately conservative — raise it only if Venda Válida confirms a higher ceiling.
Once you're done, click **Next**.
### 2. Select streams
Choose which data streams you want to sync. For faster extractions, select only the streams that are relevant to your analysis. You can select entire groups of streams or pick specific ones.
> Tip: The stream can be found more easily by typing its name.
All three streams come from the same request, so selecting Customer Orders and Customer Events costs no extra extraction time. Orders and Events are also available as JSON columns inside Customers — the dedicated streams simply expand them into one row per order or event, ready to query.
Select the streams and click **Next**.
### 3. Configure data streams
Customize how you want your data to appear in your catalog. Select the desired layer where the data will be placed, a folder to organize it inside the layer, a name for each table (which will effectively contain the fetched data) and the type of sync.
* **Layer**: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
* **Folder**: a folder can be created inside the selected layer to group all tables being created from this new data source.
* **Table name**: we suggest a name, but feel free to customize it. You have the option to add a **prefix** to all tables at once and make this process faster!
* **Sync Type**: all three streams support INCREMENTAL. Read more about Sync Types [here](https://docs.nekt.com/get-started/core-concepts/types-of-sync).
Once you are done configuring, click **Next**.
### 4. Configure data source
Describe your data source for easy identification within your organization, not exceeding 140 characters.
To define your [Trigger](https://docs.nekt.com/get-started/core-concepts/triggers), consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times).
Optionally, you can define some additional settings:
* Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource [here](https://docs.nekt.com/get-started/core-concepts/resource-control).
* Determine when to execute an **Additional [Full Sync](https://docs.nekt.com/get-started/core-concepts/types-of-sync#additional-full-sync)**. This will complement the incremental data extractions, ensuring that your data is completely synchronized with your source every once in a while.
Venda Válida does not document which date its filter applies to, so the connector re-reads the last 30 days on every run and the Lakehouse deduplicates the overlap. Scheduling an occasional additional full sync is still the safest way to guarantee that an old customer edited long after being created is up to date.
Once you are ready, click **Next** to finalize the setup.
### 5. Check your new source
You can view your new source on the [Sources](https://app.nekt.ai/sources) page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.
For you to be able to see it on your [Catalog](https://app.nekt.ai/catalog), you need at least one successful source run.
# Streams and Fields
Below you'll find all available data streams from Venda Válida and their corresponding fields. API reference: [Integração do CRM via API da Venda Valida](https://vendavalida.zendesk.com/hc/pt-br/articles/26608266242587-Integra%C3%A7%C3%A3o-do-CRM-via-API-da-Venda-Valida).
Every contact Venda Válida holds for your business (`GET /api/v1/customer`), with the campaign journey and the orders recorded for them.
Primary key: `customer_id` · Replication key: `last_modified`
| Field | Type | Description |
| :------------------ | :-------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `customer_id` | String | Unique identifier of the customer, composed by Venda Válida as the business id and the customer's phone number separated by a semicolon. |
| `customer_name` | String | Name of the customer as registered in Venda Válida. |
| `customer_document` | String | Brazilian taxpayer registration (CPF) of the customer, digits only. Integrations that do not have it send a placeholder, so the same value can repeat across customers. |
| `email` | String | Email address of the customer. |
| `phone` | String | Mobile phone of the customer, area code and number without punctuation. It is also the second half of the customer id. |
| `origin` | String | Source that first brought the customer into Venda Válida, such as the campaign tag or the integration that created them. |
| `tags` | Array of String | Tags applied to the customer. Venda Válida uses them to group customers into campaigns and journeys. |
| `created_at` | Datetime | Timestamp when the customer was created in Venda Válida. |
| `last_modified` | Datetime | Timestamp of the last change to the customer, used as the incremental replication key. When the API does not return it, the creation timestamp is used instead. |
| `events` | String | Campaign events recorded for the customer, as a JSON array of objects. The Customer Events stream exposes the same data as one row per event. |
| `orders` | String | Orders recorded for the customer, as a JSON array of objects. The Customer Orders stream exposes the same data as one row per order. |
One row per order Venda Válida holds for a customer, expanded from the customer payload — no extra extraction time.
Primary key: `customer_id`, `order_id` · Replication key: `customer_last_modified`
| Field | Type | Description |
| :----------------------- | :------- | :------------------------------------------------------------------------------------------------------------------------------- |
| `customer_id` | String | Identifier of the customer the order belongs to, matching `customers.customer_id`. |
| `order_id` | String | Identifier of the order in the store or ERP that sent it to Venda Válida. |
| `created_at` | Datetime | Timestamp when the order was placed. |
| `amount` | Number | Total value of the order, in the store's currency. |
| `status` | String | Payment status of the order as reported to Venda Válida, such as `pending` or `paid`. |
| `payment_method` | String | Payment method of the order (for example `pix` or credit card). Only filled when the integration that created the order sent it. |
| `payment_link` | String | Checkout link sent to the customer to complete the payment, when the integration provided one. |
| `order_code` | String | Store's own code for the order, when the integration provided one alongside the identifier. |
| `products` | String | Products of the order as a JSON array of objects (sku, name, quantity, amount, image, category), when the integration sent them. |
| `customer_document` | String | CPF of the customer, repeated here so the row joins on its own. |
| `phone` | String | Mobile phone of the customer, repeated here for convenience. |
| `customer_last_modified` | Datetime | Timestamp of the last change to the parent customer, used as the incremental replication key of this stream. |
One row per campaign event recorded for a customer — the tag of the campaign that reached them, when it happened and the products it carried.
Primary key: `customer_id`, `event_name`, `created_at` · Replication key: `customer_last_modified`
| Field | Type | Description |
| :----------------------- | :------- | :------------------------------------------------------------------------------------------------------------------ |
| `customer_id` | String | Identifier of the customer the event belongs to, matching `customers.customer_id`. |
| `event_name` | String | Name of the event, which is the tag of the campaign or journey that produced it, such as `promocao_de_aniversario`. |
| `created_at` | Datetime | Timestamp when the event was recorded for the customer. |
| `products` | String | Products carried by the event, as a JSON array of objects (id, name, quantity, amount, image, category). |
| `customer_document` | String | CPF of the customer, repeated here so the row joins on its own. |
| `phone` | String | Mobile phone of the customer, repeated here for convenience. |
| `customer_last_modified` | Datetime | Timestamp of the last change to the parent customer, used as the incremental replication key of this stream. |