Skip to main content
Nomus is a Brazilian ERP for manufacturing companies. This connector reads your Nomus system through the Nomus REST API and brings sales orders and proposals, purchase orders, NF-e and NFS-e invoices, accounts receivable and payable, payments and receipts, stock documents and movements, customers, products, price tables and the other registers, and production data (orders, operations, production reports, material allocations, bills of materials, routings and inspection results).
The connector only reads data. It never creates, changes or deletes anything in Nomus. Files (DANFE, NFS-e PDF, correction letters, bank slip PDFs and labels) are not loaded.

​
Configuring Nomus as a Source

In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the Nomus option from the list of connectors. Click Next and you’ll be prompted to add your access.

​
1. Add account access

You need two things from your Nomus system:
  • Nomus URL: the address you open Nomus with, for example https://yourcompany.nomus.com.br/yourcompany. You can also type only your company identifier (yourcompany). If your Nomus is installed outside nomus.com.br, use its full https address.
  • Integration Key: the REST integration key of your Nomus (“Chave de integração REST”). A Nomus administrator finds it in the general system configuration (“Configurações gerais do sistema”). Paste it exactly as Nomus shows it.
  • Start Date: the earliest creation or change date read by the incremental tables (see the list below) on the first sync and on full syncs. The other tables are always read whole.
In the advanced settings you can also set:
  • Re-read Window (days): sales orders issued in the last N days are read again on every sync, so item statuses that change when an order is invoiced stay up to date. When the option below is on, accounts receivable and payable due from N days ago on are re-read too. Default: 30. Use 0 to turn it off.
  • Re-read Open Receivables and Payables: on by default. Every sync reads again all accounts receivable and payable due from Re-read Window days ago on, including every title due in the future, so a payment that Nomus records without updating the title’s change date still shows up. With many open titles this is the heaviest part of a sync (receivables can also carry the bank slip PDF, which Nomus always sends and the connector discards). Turn it off to make syncs lighter and rely on the weekly Additional Full Sync to catch those payments.
Everything the connector reads depends on the modules enabled in your Nomus. If a table belongs to a module you don’t use, deselect it.
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.
Product Suppliers and Stock Balances are not selected by default: they make one request per product, which can take long on large catalogs. Select them if you need them. 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: Sales Orders, Sales Order Items, NF-e Invoices, Accounts Receivable, Accounts Payable, Payments, Receipts, Customers and Products can be Incremental: each sync reads only what was created or changed since the previous one. Every other stream is Full table: each sync reads the whole list from Nomus and replaces the table.
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, 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 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. We recommend an Additional Full Sync once a week for the incremental tables: it removes rows deleted in Nomus (for example items removed from an order) and catches changes Nomus did not mark (see Data Quality Considerations). Once you are ready, click Next to finalize the setup.

​
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.
For you to be able to see it on your Catalog, you need at least one successful source run.

​
Streams and Fields

​
Available streams

The table below lists every stream, its slug (the exact identifier to pass when creating the source via API), its sync type and a short description.

​
Fields by stream

Accounts payable (contas a pagar): due dates, amounts and balance. Read from contasPagar.Table: accounts_payable · Primary key: id · Sync: Incremental (by ultima_alteracao)
Accounts receivable (contas a receber): due dates, amounts, balance, settlement and bank slip line. Read from contasReceber.Table: accounts_receivable · Primary key: id · Sync: Incremental (by ultima_alteracao)
Production activities (atividades). Read from atividades.Table: activities · Primary key: id · Sync: Full table
Bank accounts registered in Nomus. Read from contasBancarias.Table: bank_accounts · Primary key: id · Sync: Full table
Bank slips (boletos) issued in Nomus and their status. Read from boletos.Table: bank_slips · Primary key: id · Sync: Full table
One row per component of a bill of materials. Read from componentesListaMateriais.Table: bill_of_materials_components · Primary key: id · Sync: Full table
Bills of materials (listas de materiais) with their components as JSON. Read from listasMateriais.Table: bills_of_materials · Primary key: id · Sync: Full table
Companies (empresas) of the Nomus installation. Read from empresas.Table: companies · Primary key: id · Sync: Full table
Contacts and their e-mails. Read from contatos.Table: contacts · Primary key: id · Sync: Full table
Cost centers. Read from centrosCusto.Table: cost_centers · Primary key: id · Sync: Full table
Custom fields defined in Nomus. Read from camposPersonalizados.Table: custom_fields · Primary key: id · Sync: Full table
Credit notes in favor of customers. Read from notasCreditoCliente.Table: customer_credit_notes · Primary key: id · Sync: Full table
Customers with address, tax data, sellers and sales representatives. Read from clientes.Table: customers · Primary key: id · Sync: Incremental (by ultima_alteracao)
Delivery routes. Read from rotas.Table: delivery_routes · Primary key: id · Sync: Full table
Employees (funcionários) used in production reports. Read from funcionarios.Table: employees · Primary key: id · Sync: Full table
Quality inspection results. Read from resultadosInspecao.Table: inspection_results · Primary key: id · Sync: Full table
Stock inventories. Read from inventarios/listar.Table: inventories · Primary key: id · Sync: Full table
Lots and serial numbers with their stock balance. Read from lotesSerie.Table: lots_series · Primary key: id · Sync: Full table
Material allocations (empenhos) of production orders. Read from empenhos.Table: material_allocations · Primary key: id_empenho · Sync: Full table
Movement types (tipos de movimentação) and their nature. Read from tiposMovimentacao.Table: movement_types · Primary key: codigo · Sync: Full table
Electronic invoices (NF-e) issued or received in Nomus: number, series, access key, status and protocol. Read from nfes.Table: invoices · Primary key: id · Sync: Incremental (by ultima_alteracao)
Electronic service invoices (NFS-e), with the XML. Read from nfses.Table: service_invoices · Primary key: id · Sync: Full table
Items of outgoing (sales) documents, with customer, CFOP, quantities and values. Read from itensDocumentoSaida.Table: outgoing_document_items · Primary key: id · Sync: Full table
Payment methods (formas de pagamento). Read from formasPagamento.Table: payment_methods · Primary key: id · Sync: Full table
Payment terms (condições de pagamento). Read from condicoesPagamentos.Table: payment_terms · Primary key: id · Sync: Full table
Payments made (pagamentos), with bank account, payment method and financial classification. Read from pagamentos.Table: payments · Primary key: id · Sync: Incremental (by ultima_alteracao)
Every person registered in Nomus (customers, suppliers, carriers, employees…) with their categories. Read from pessoas.Table: people · Primary key: id · Sync: Full table
Custom attributes defined for people. Read from atributosPessoa.Table: person_attributes · Primary key: id · Sync: Full table
Phone numbers of people and contacts. Read from telefones.Table: phones · Primary key: id · Sync: Full table
Product prices of each price table. Read from one request to tabelasPreco/ID/itens per record of tabelasPreco.Table: price_table_items · Primary key: id_tabela_preco, id_produto · Sync: Full table
Price tables. Read from tabelasPreco.Table: price_tables · Primary key: id · Sync: Full table
Problem causes (causas de problemas). Read from causasProblemas.Table: problem_causes · Primary key: id · Sync: Full table
CRM processes (processos). Read from processos.Table: processes · Primary key: id · Sync: Full table
Custom attributes defined for products. Read from atributosProduto.Table: product_attributes · Primary key: id · Sync: Full table
Product families. Read from familiasProduto.Table: product_families · Primary key: id · Sync: Full table
Product groups. Read from gruposProduto.Table: product_groups · Primary key: id · Sync: Full table
Operations of the product routings, with times and resources. Read from operacoesRoteiroProduto.Table: product_routing_operations · Primary key: id · Sync: Full table
Product routings (roteiros) with their operations as JSON. Read from roteirosProduto.Table: product_routings · Primary key: id · Sync: Full table
Suppliers of each product. One request per product, so it is not selected by default. Read from one request to fornecedoresProduto/ID per record of produtos.Table: product_suppliers · Primary key: id_produto, id_fornecedor · Sync: Full table
Product types. Read from tiposProduto.Table: product_types · Primary key: id · Sync: Full table
Operations of each production order, with planned and produced quantities. Read from operacoesRoteiroOrdem.Table: production_order_operations · Primary key: id · Sync: Full table
Production orders (ordens) with product, quantity, planned dates and status. Read from ordens.Table: production_orders · Primary key: id · Sync: Full table
Production reports (apontamentos): start, end, quantity, employee and resource. Read from apontamentos.Table: production_time_entries · Primary key: id · Sync: Full table
Products with family, group, type, unit, NCM and stock per company. Read from produtos.Table: products · Primary key: id · Sync: Incremental (by ultima_alteracao)
One row per proposal item. Read from the itensProposta list of each record of propostas.Table: proposal_items · Primary key: id · Sync: Full table
Commercial proposals (propostas) with customer, totals and items as JSON. Read from propostas.Table: proposals · Primary key: id · Sync: Full table
One row per purchase order item. Read from the itensPedidoCompra list of each record of pedidoscompra.Table: purchase_order_items · Primary key: id_pedido_compra, item · Sync: Full table
Purchase orders (pedidos de compra) with supplier, installments and items as JSON. Read from pedidoscompra.Table: purchase_orders · Primary key: id · Sync: Full table
Purchase requests (solicitações de compra) from production orders, free entry or MRP. Read from solicitacoesCompras.Table: purchase_requests · Primary key: codigo · Sync: Full table
Customer requests for quotation (solicitações) and their items as JSON. Read from solicitacoes.Table: quote_requests · Primary key: id · Sync: Full table
Payments received (recebimentos), with bank account, payment method and financial classification. Read from recebimentos.Table: receipts · Primary key: id · Sync: Incremental (by ultima_alteracao)
NF-e issued against your company by suppliers (notas fiscais destinadas) and their manifestation. Read from nfesDestinadas.Table: received_invoices · Primary key: id · Sync: Full table
Production resources (recursos). Read from recursos.Table: resources · Primary key: id · Sync: Full table
One row per sales order item: product, quantity, prices, discounts and item status. Read from the itensPedido list of each record of pedidos.Table: sales_order_items · Primary key: id · Sync: Incremental (by ultima_alteracao)
Sales orders (pedidos de venda) with totals, customer, seller, payment term and the items as JSON. Read from pedidos.Table: sales_orders · Primary key: id · Sync: Incremental (by ultima_alteracao)
Sales representatives (representantes). Read from representantes.Table: sales_representatives · Primary key: id · Sync: Full table
Sellers (vendedores). Read from vendedores.Table: sellers · Primary key: id · Sync: Full table
Service contracts and their items as JSON. Read from contratosServico.Table: service_contracts · Primary key: id · Sync: Full table
Service sale documents (documentos de venda de serviço) and their items as JSON. Read from documentosVendaServico.Table: service_sale_documents · Primary key: id · Sync: Full table
Current stock balance and costs of each product per company, with the balance per stock sector. One request per product, so it is not selected by default. Read from one request to saldosEstoqueProduto/ID per record of produtos.Table: stock_balances · Primary key: id_produto, id_empresa · Sync: Full table
One row per stock document item, with taxes and costs. Read from the itensDocumentoEstoque list of each record of documentosEstoque.Table: stock_document_items · Primary key: id · Sync: Full table
Stock documents (incoming, outgoing and service documents) with their items as JSON. Read from documentosEstoque.Table: stock_documents · Primary key: id · Sync: Full table
Every stock movement: product, quantity, sector, lot and the document line that moved it. Read from movimentacoesEstoque.Table: stock_movements · Primary key: codigo, discriminador · Sync: Full table
Stock sectors (setores de estoque). Read from setorEstoque.Table: stock_sectors · Primary key: id · Sync: Full table
Credit notes from suppliers. Read from notasCreditoFornecedor.Table: supplier_credit_notes · Primary key: id · Sync: Full table
Units of measure. Read from unidadesMedida.Table: units_of_measure · Primary key: id · Sync: Full table
User groups of Nomus. Read from grupoUsuarios.Table: user_groups · Primary key: id · Sync: Full table
Users of Nomus. Read from usuarios.Table: users · Primary key: id · Sync: Full table
Work centers (centros de trabalho). Read from centrosTrabalho.Table: work_centers · Primary key: id · Sync: Full table

​
Implementation Notes

​
Data Quality Considerations

  • Column names follow Nomus. Field names are the Nomus API names in snake_case (idPessoaCliente becomes id_pessoa_cliente); each field’s description says the original name. Every table also has an extra_fields column (JSON) with any field Nomus sent that has no column of its own, so nothing is dropped.
  • Numbers and dates are converted. Nomus sends amounts as text, sometimes formatted in Brazilian Portuguese (1.068,33) and sometimes as plain decimals (5.000000). The connector converts both to exact numbers. A value with a single dot followed by exactly three digits and no comma (1.500) can mean one thousand five hundred or one and a half: it is read as thousands only in the columns that Nomus formats for display (amounts, prices, quantities and percentages of orders and their items, proposals, purchase order items, stock documents and movements, lots, receivables, payables, payments, receipts, bank slips, credit notes, price tables, stock balances, bills of materials, production orders and their operations, production reports and purchase requests). In any other column such a value is left empty, kept as sent in extra_fields, and the sync log says how many values were affected. Dates (13/10/2026 16:21:55, always day first) become ISO dates and times in Brasília time (2026-10-13T16:21:55-03:00). Any other value that cannot be converted is also left empty and kept as sent in extra_fields.
  • How incremental tables work. Each sync reads the records created and the records changed since one day before the previous sync, and ultima_alteracao (the later of the creation and change dates) tracks progress. Receipts have no change date in Nomus, so only new receipts are read incrementally. A record that changes without Nomus updating its change date is only seen again on a full sync; this is why Sales Orders re-read the orders issued in the last 30 days and Accounts Receivable and Payable re-read the titles due from 30 days ago on, future ones included (both configurable; the second one can be turned off), and why a weekly Additional Full Sync is recommended.
  • Rows deleted in Nomus stay in incremental tables. An incremental sync only adds and updates rows. A record deleted in Nomus, or an item removed from a sales order, is never sent again, so its last version stays in the table (for example in Sales Order Items) until a full sync rewrites it. The weekly Additional Full Sync takes care of this.
  • A table is never half updated. The connector reads all the data of a table before writing any of it. If Nomus fails or refuses part of a table, the connector sends nothing for that table and the sync shows it as failed. On BigQuery (GCP and Nekt Express) the table then keeps its previous content. On AWS, a Full table stream that ends a sync without data can be written as an empty table; if that happens, run the sync again once Nomus answers.
  • A table that suddenly comes back empty is not sent. If Nomus returns no rows for a Full table stream that had rows in the previous sync, the sync fails for that table instead of sending an empty table. On BigQuery the table keeps its rows; on AWS the same caveat as above applies. If the data really was removed in Nomus, run a full sync of the source to accept the empty table.
  • Records deleted during a sync. Nomus lists are read page by page. If a record is deleted in Nomus while a list is being read, the record right after it can be skipped by that read. For the incremental tables, any read that spans more than one page is done twice and combined, so nothing is lost. A Full table stream can miss that record in that sync and gets it back on the next one.
  • Items have their own tables. Sales Order Items, Proposal Items, Purchase Order Items and Stock Document Items have one row per item; the parent tables also keep the items as JSON.
  • Time zone. Nomus does not say which time zone its dates are in; they are read as Brasília time. If your Nomus runs in another time zone, the times are shifted by the difference, but no record is missed.

​
API Limits & Performance

  • Nomus limits how many requests an integration may send. When the limit is reached, Nomus tells how long to wait; the connector waits that long and the sync log says the sync is slower because of it. Other integrations using your Nomus count toward the same limit.
  • The connector sends one request at a time. Lists come in pages, so large tables (stock movements, outgoing document items) can take a while on the first sync.
  • Product Suppliers and Stock Balances make one request per product; Price Table Items, one per price table (more when a table has more items than fit in one page).
  • On the first sync, incremental tables with many records are read twice (see Records deleted during a sync), so the first sync takes longer than the next ones. The re-read of recent orders and open titles is read once.
  • Accounts Receivable is usually the heaviest table: Nomus sends the bank slip PDF inside each title that has one (there is no option to leave it out; the connector discards it), and with Re-read Open Receivables and Payables on, every open title is read again on every sync. If syncs take too long, turn that option off.

​
Troubleshooting

​
Skills for agents

Download Nomus skills file

Nomus connector documentation as plain markdown, for use in AI agent contexts.