> ## 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.
# Kiwify as a data source
> Bring data from Kiwify to your Lakehouse.
Kiwify is a Brazilian platform for selling digital products — online courses, memberships, ebooks and events — covering the checkout, payments, affiliate program and payouts. Nekt extracts this data through the Kiwify public API.
## Configuring Kiwify 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 Kiwify option from the list of connectors.
Click **Next** and you'll be prompted to add your access.
### 1. Add account access
API access is created inside Kiwify, under **Apps > API**. Create a credential there and copy its values before leaving the screen — the client secret is displayed only once, at creation time.
The following configurations are required:
* **Client ID**: The client ID of the API credential.
* **Client Secret**: The client secret of the API credential. It is shown only once, when the credential is created.
* **Account ID**: The Kiwify account (store) ID shown next to the API credential. It identifies which store the extraction reads from.
Optionally, under advanced settings:
* **Start Date**: The earliest date from which records will be synced. Sales are swept from this date in 85-day windows, so an unnecessarily old date makes every sync slower. Defaults to two years ago.
* **Full Sale Details**: Whether sales are fetched with the payment breakdown, UTM tracking, revenue splits and affiliate commission. Enabled by default; turn it off to fetch only the summary fields.
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.
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**: you can choose between INCREMENTAL and FULL\_TABLE.
* Incremental: every time the extraction happens, we'll get only the new data - which is good if, for example, you want to keep every record ever fetched.
* Full table: every time the extraction happens, we'll get the current state of the data - which is good if, for example, you don't want to have deleted data in your catalog.
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).
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.
Monetary values are returned by Kiwify as integers in the smallest unit of the currency. An amount of `8853` means R\$ 88,53.
# Streams and Fields
Below you'll find all available data streams from Kiwify and their corresponding fields. Sales, daily statistics and event participants sync incrementally; the remaining streams are extracted as full tables. Product details, event participants and balances are fetched per parent record, so they cost one extra request per product or legal entity.
Orders placed on the store's checkout, incrementally synced by their last-change date. Because Kiwify filters orders by creation date in windows of at most 90 days, the connector sweeps the whole configured history on every run and asks only for the orders changed since the last sync — so refunds and chargebacks of older orders are picked up as well.
**Key Fields:**
* `id` - Unique identifier of the sale
* `reference` - Short order reference shown to the buyer
* `status` - Current status (paid, waiting\_payment, refunded, chargedback, refused, and so on)
* `payment_method` - How the order was paid: credit\_card, boleto or pix
* `net_amount` - Amount credited to the producer after fees, in cents
* `currency` - Currency the order was charged in
* `sale_type` - Role of this account in the sale (producer, affiliate or co-producer)
* `created_at` / `updated_at` - Order placement and last-change timestamps
* `approved_date` / `refunded_at` - Payment approval and refund timestamps
* `product_id` / `product_name` - Product that was sold
* `customer_id`, `customer_name`, `customer_email`, `customer_cpf`, `customer_cnpj`, `customer_mobile`, `customer_instagram`, `customer_country` - Buyer identification
* `customer_address_street`, `customer_address_number`, `customer_address_city`, `customer_address_state`, `customer_address_zipcode` - Buyer address
* `installments`, `card_type`, `card_last_digits`, `card_rejection_reason`, `two_cards`, `is_one_click` - Payment attempt details
* `payment_charge_amount`, `payment_net_amount`, `payment_fee`, `payment_product_base_price`, `payment_settlement_amount`, `payment_sale_tax_rate`, `payment_sale_tax_amount` - Full payment breakdown, with the matching currency fields
* `tracking_utm_source`, `tracking_utm_medium`, `tracking_utm_campaign`, `tracking_utm_content`, `tracking_utm_term`, `tracking_src`, `tracking_sck`, `tracking_s1`, `tracking_s2`, `tracking_s3` - Attribution parameters captured at the checkout
* `affiliate_commission_name`, `affiliate_commission_email`, `affiliate_commission_document`, `affiliate_commission_amount` - Affiliate credited for the sale
* `shipping_id`, `shipping_name`, `shipping_price` - Shipping option chosen for physical products
* `revenue_partners` - Co-producers who shared the revenue of the order (JSON)
* `parent_order_id` - Originating order, for renewals and upsells
Checkout performance metrics aggregated by day, incrementally synced. Useful for tracking approval and refund quality over time without recomputing it from the orders.
**Key Fields:**
* `date` - Day the metrics refer to
* `total_sales` - Number of sales approved on the day
* `total_net_amount` - Net revenue credited on the day, in cents
* `credit_card_approval_rate` - Share of credit card attempts approved, as a percentage
* `refund_rate` - Share of the day's sales that were refunded, as a percentage
* `chargeback_rate` - Share of the day's sales that were charged back, as a percentage
* `total_boleto_generated` / `total_boleto_paid` - Boletos issued and paid on the day
* `boleto_rate` - Share of the issued boletos that were paid, as a percentage
Products sold by the store, extracted as a full table.
**Key Fields:**
* `id` - Unique identifier of the product
* `name` - Name of the product as shown on the checkout
* `type` - Kind of product being sold (for example membership, course or event)
* `status` - Current status of the product
* `payment_type` - Whether the product is a one-off charge or a recurring subscription
* `price` - Price in cents, when the product has a base price
* `currency` - Currency the product is priced in
* `affiliate_enabled` - Whether the product accepts affiliates
* `created_at` - Product creation timestamp
Full checkout configuration of each product, extracted as a full table. Complements the Products stream with the data returned only by the per-product endpoint, so it costs one request per product on every run.
**Key Fields:**
* `id` - Unique identifier of the product
* `store_id` - Kiwify store that owns the product
* `offers` - Alternative price offers of the product (JSON)
* `links` - Checkout links of the product (JSON)
* `bumps` - Order bumps configured on the checkout (JSON)
* `subscriptions` - Subscription plans, for recurring products (JSON)
* `shipping_options` - Shipping options offered for physical products (JSON)
* `event_settings` - Event address, check-in options and sale window, for event products (JSON)
* `event_batches` - Ticket batches with prices and ticket counters, for event products (JSON)
* `revenue_partners` - Co-producers sharing the revenue of the product (JSON)
Affiliates approved to promote the store's products, extracted as a full table. The API returns one record per affiliate and product, so the same person appears once for each product they promote.
**Key Fields:**
* `affiliate_id` - Unique identifier of the affiliate
* `product_id` / `product_name` - Product the affiliate promotes
* `name` - Full name of the affiliate
* `email` - Email address of the affiliate
* `company_name`, `director_cpf`, `company_cnpj` - Registration data of the affiliate
* `commission` - Commission the affiliate earns on the product, in cents
* `status` - Current status of the affiliation
* `created_at` - Affiliation creation timestamp
Ticket holders of the store's event products, incrementally synced by their last-change date. Products that are not events simply return no participants.
**Key Fields:**
* `id` - Unique identifier of the participant
* `product_id` - Event product the ticket belongs to
* `external_id` - Ticket code used for check-in at the event
* `batch_id` / `batch_name` - Ticket batch the ticket was sold in
* `name`, `email`, `cpf`, `phone` - Participant identification
* `order_id` - Sale that issued the ticket
* `checkin_at` - Check-in timestamp at the event
* `created_at` / `updated_at` - Ticket issue and last-change timestamps
Withdrawals requested from the account's balance, extracted as a full table.
**Key Fields:**
* `id` - Unique identifier of the payout
* `amount` - Amount withdrawn, in cents
* `status` - Current status of the payout (for example pending\_review or paid)
* `legal_entity_id` - Legal entity that received the payout
* `created_at` / `updated_at` - Request and last-change timestamps
Current balance of each legal entity of the account, extracted as a full table snapshot.
**Key Fields:**
* `legal_entity_id` - Legal entity the balance belongs to
* `available` - Balance already released for withdrawal, in cents
* `pending` - Balance still held by the platform's settlement period, in cents
Registration data of the connected Kiwify account, extracted as a full table.
**Key Fields:**
* `id` - Unique identifier of the account (store)
* `company_name` - Registered company name of the account
* `director_cpf` / `company_cnpj` - Tax identification of the account
* `legal_entities` - Legal entities that can receive payouts, with their company data and pix key (JSON)
Webhooks configured on the account, extracted as a full table.
**Key Fields:**
* `id` - Unique identifier of the webhook
* `name` - Name given to the webhook
* `url` - Endpoint Kiwify posts the events to
* `products` - Product the webhook listens to, or "all" when it covers every product
* `triggers` - Events that fire the webhook (compra\_aprovada, compra\_reembolsada, chargeback, and so on)
* `created_at` / `updated_at` - Creation and last-change timestamps