The connector only reads data. It never creates, changes or deletes anything in WK Radar.
Configuring WK Radar as a Source
In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the WK Radar option from the list of connectors. Click Next and you’ll be prompted to add your access.1. Add account access
The connector signs in to the Radar.API, the WK Radar module for integrations. Before you start, make sure that:- Your company has the Radar.API module enabled. Its availability depends on your WK Radar license; talk to WK Sistemas if you don’t have it.
- The Radar.API is published on an HTTPS address reachable from the internet (for example
https://radar.yourcompany.com.br/radar.api). Each company publishes its own; your WK Radar administrator or WK support can tell you the address. If a firewall protects it, allow Nekt’s public IP, shown in the Helpful resources section when you connect the source. - You have a WK Radar system user (Usuario de Sistema) for Nekt, with permission to the read routes of the data you want to extract (see the table of routes below).
- Radar.API URL: The HTTPS address of your company’s Radar.API. Paste the base address only; if you paste the Swagger or token address, the connector removes the extra path.
- Company: The company (empresa) you type on the WK Radar sign-in screen.
- Username: The system user created for Nekt.
- Password: The password of that user.
- Start Date: The earliest document date to extract on the first sync: invoices, orders, purchase documents, bills, settlements, journal entries and stock movements dated from this day on. Bills are also read when they are due from this day on, and every bill still open is read whatever its dates, so open and overdue installments of older sales and purchases are included. Registries (products, customers, suppliers, charts of accounts and branches) are always read in full.
-
API time zone: (Default:
America/Sao_Paulo) Time zone of the dates and times WK Radar sends without a time zone. Nekt converts them to UTC. Change it only if your WK Radar server runs in another time zone. - Settlements Lookback (days): (Default: 35) How many days of settlement dates every sync reads again, so settlements registered late (for example at month-end reconciliation) are picked up.
- Journal Entries Lookback (days): (Default: 60) How many days of entry dates every sync reads again, so closing entries posted weeks after the month they belong to are picked up.
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.
Keep the item streams (Invoice Items, Sales Order Items, Purchase Order Items and Incoming Invoice Items) as INCREMENTAL. If one of them is set to FULL_TABLE, its document stream reads every document since the Start Date on every sync, which is slower.
4. Configure data source
Describe your data source for easy identification within your organization, not exceeding 140 characters. To define your Trigger, 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.
- Determine when to execute an Additional Full Sync. We recommend a weekly or monthly full sync for this source: incremental syncs do not remove records deleted in WK Radar, and invoices, settlements and journal entries changed long after their date (beyond the windows described below) are only refreshed by a full sync. A full sync reads everything again since the Start Date.
5. Check your new source
You can view your new source on the Sources page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.Streams and Fields
Available streams
The table below lists every stream, its slug (the exact identifier to pass when creating the source via API) and a short description.Fields by stream
Sales
Invoices
Invoices
Invoices (notas fiscais) issued in the Commercial module, outgoing and incoming, with totals, taxes, NF-e/NFS-e status and billing. Incremental by issue date: each sync re-reads the last 7 days of issue dates, and invoices still waiting for SEFAZ or the city hall are re-read until their status is final.Table:
invoices · Primary key: id · Sync: Incremental (data_emissao)Invoice Items
Invoice Items
One row per item of each invoice. Read together with its invoice, with no extra request. Invoice items have no number in the API, so
item_key is the position of the item (pos1, pos2, …); keep only rows whose extracted_at equals the invoice’s.Table: invoice_items · Primary key: nota_fiscal_id, item_key · Sync: Incremental (extracted_at)Sales Orders
Sales Orders
Sales orders (pedidos). After the first sync, each sync reads the orders changed since the previous one.Table:
sales_orders · Primary key: id · Sync: Incremental (extracted_at)Sales Order Items
Sales Order Items
One row per item of each sales order, read together with its order.
item_key is the item number.Table: sales_order_items · Primary key: pedido_id, item_key · Sync: Incremental (extracted_at)Purchasing
Purchase Orders
Purchase Orders
Purchase orders (ordens de compra). After the first sync, each sync reads the orders changed since the previous one.Table:
purchase_orders · Primary key: id · Sync: Incremental (extracted_at)Purchase Order Items
Purchase Order Items
One row per item of each purchase order, read together with its order.Table:
purchase_order_items · Primary key: ordem_compra_id, item_key · Sync: Incremental (extracted_at)Incoming Invoices
Incoming Invoices
Incoming invoices registered in Purchasing (registros de entrada): supplier invoices, utility bills and freight bills. The first sync reads them by entry date; later syncs read the ones changed since the previous sync.Table:
incoming_invoices · Primary key: id · Sync: Incremental (extracted_at)Incoming Invoice Items
Incoming Invoice Items
One row per item of each incoming invoice, read together with it.Table:
incoming_invoice_items · Primary key: registro_entrada_id, item_key · Sync: Incremental (extracted_at)Financial
Accounts Payable
Accounts Payable
Bills payable (títulos a pagar). The first sync reads the bills issued or due since the Start Date and every bill still open; later syncs read every bill changed since the previous sync, so payments, extensions and cancellations of old bills are picked up.Table:
accounts_payable · Primary key: id · Sync: Incremental (extracted_at)Accounts Receivable
Accounts Receivable
Bills receivable (títulos a receber), read like Accounts Payable.Table:
accounts_receivable · Primary key: id · Sync: Incremental (extracted_at)Accounts Payable Settlements
Accounts Payable Settlements
Settlements (baixas) of bills payable, by settlement date. Each sync re-reads the last 35 days of settlement dates (configurable).Table:
accounts_payable_settlements · Primary key: id · Sync: Incremental (data_baixa)Accounts Receivable Settlements
Accounts Receivable Settlements
Settlements (baixas) of bills receivable, by settlement date. Each sync re-reads the last 35 days of settlement dates (configurable).Table:
accounts_receivable_settlements · Primary key: id · Sync: Incremental (data_baixa)Accounting
Journal Entries
Journal Entries
Accounting journal entries (lançamentos contábeis) with debit and credit accounts and their cost center apportionment, by entry date. Each sync re-reads the last 60 days of entry dates (configurable).Table:
journal_entries · Primary key: id · Sync: Incremental (data)Chart of Accounts
Chart of Accounts
Ledger accounts (plano de contas contábil), group and posting accounts, active and inactive. Read in full on every sync.Table:
chart_of_accounts · Primary key: id · Sync: Full tableManagement Accounts
Management Accounts
Managerial accounts (plano de contas gerencial), which WK Radar uses as cost centers. Read in full on every sync.Table:
management_accounts · Primary key: id · Sync: Full tableInventory and registries
Stock Movements
Stock Movements
Stock movements (entries, exits, transfers, adjustments) per product, location and batch. After the first sync, each sync reads the movements changed since the previous one.Table:
stock_movements · Primary key: id · Sync: Incremental (extracted_at)Products
Products
Every product, active and inactive. Read in full on every sync.Table:
products · Primary key: id · Sync: Full tableCustomers
Customers
Every customer, active and inactive, individuals and companies. Read in full on every sync.Table:
customers · Primary key: id · Sync: Full tableSuppliers
Suppliers
Every supplier, active and inactive. Read in full on every sync.Table:
suppliers · Primary key: id · Sync: Full tableBranches
Branches
Companies and branches (empresas/filiais) registered in WK Radar. Read in full on every sync.Table:
branches · Primary key: id · Sync: Full tableImplementation Notes
Data Quality Considerations
- Dates and times are in UTC. WK Radar sends them without a time zone, in the server’s time (Brasília time unless you set another API time zone); Nekt converts them to UTC. Columns that hold only a date (due date, settlement date, entry date) keep the date as shown in WK Radar.
- How each stream is kept up to date:
- Sales orders, purchase orders, incoming invoices, stock movements, accounts payable and accounts receivable: each sync reads the records changed in WK Radar since the previous sync (with a one-day safety margin), whatever their date, plus the documents dated in the last days. The column
extracted_atrecords when the connector read the record. - Invoices: each sync re-reads the last 7 days of issue dates. Invoices whose NF-e or NFS-e is still waiting for authorization, was rejected or has a cancellation request are re-read on every sync until their status is final (for up to 90 days).
- Settlements: each sync re-reads the last 35 days of settlement dates (Settlements Lookback).
- Journal entries: each sync re-reads the last 60 days of entry dates (Journal Entries Lookback), which covers closing entries posted weeks after the month they belong to.
- Products, customers, suppliers, charts of accounts and branches: read in full on every sync. If WK Radar returns no products, customers, branches or ledger accounts at all, the sync stops instead of emptying the table.
- Sales orders, purchase orders, incoming invoices, stock movements, accounts payable and accounts receivable: each sync reads the records changed in WK Radar since the previous sync (with a one-day safety margin), whatever their date, plus the documents dated in the last days. The column
- Deleted records stay in your tables after incremental syncs (for example, a settlement reversed in WK Radar). A full sync removes them.
- Items have their own tables and are read together with their document. Join them by
nota_fiscal_id,pedido_id,ordem_compra_idorregistro_entrada_idto the document’sid. Every item carries theextracted_atof its document: an item removed from a document in WK Radar keeps an older value, so filter items withitem.extracted_at = document.extracted_atto see the current items only. Invoice items have no item number in WK Radar, soitem_keyis their position in the invoice; if an item is removed from the middle of an invoice still being edited, the following items move up one position. - Nested information (taxes, installments, apportionments, addresses, InfoPlus custom fields) is stored as JSON text. Totals, NF-e and NFS-e data are split into their own columns (for example
total_valor_total_nota_fiscal,nfe_status). additional_fieldskeeps, as JSON, any field WK Radar returns that has no column of its own (for example fields added in a newer Radar.API version).- There is no stock balance in the Radar.API: stock levels can be computed from Stock Movements. A movement deleted in WK Radar stays in the table until the next full sync, so balances computed this way can be off until then.
- On the first syncs, compare the purchase orders (all statuses) and products (all types, including kits and packaging) with the WK Radar screens: the connector asks for every status and type, as WK Radar does when no filter is given.
API Limits & Performance
- The Radar.API accepts at most 4 requests per second. The connector stays below that limit and waits when WK Radar asks it to slow down.
- The Radar.API returns each list in a single answer, so the connector first lists the ids of the records and then reads them in small batches. The first sync of a company with many years of documents can take hours; later syncs only read what changed.
Troubleshooting
Skills for agents
Download WK Radar skills file
WK Radar connector documentation as plain markdown, for use in AI agent contexts.