Many customers already have inventory, stores, ERP, procurement, vehicle, asset, or warehouse data. WYNTIQ is designed to start with controlled CSV import today and can be extended with approved SQL, SQLite, Azure, API, and application connectors for enterprise deployments.
WYNTIQ should not force a customer to replace their existing systems. The practical approach is to import clean operational data first, then build controlled connectors for live or scheduled integration where required.
Local-first inventory, demand, approval, issue, QR, asset, audit, report, backup, and sync workflows.
The table below explains the customer data sources that can be used for a WYNTIQ deployment. Some are available through standard import; deeper direct connectors require customer-approved credentials, mapping, testing, and commercial scope.
| Source | Use Case | Connection Method | Deployment Notes |
|---|---|---|---|
| CSV / Excel | Item master, stock quantity, minimum quantity, unit, location, part number, category. | Template-based CSV import/export inside WYNTIQ. | Best first step. Works offline. No server or database access required. |
| SQLite | Local legacy app data, portable field database, offline warehouse files. | File-based import or mapped connector. | Good for offline migrations. Customer should provide sample file and schema. |
| Microsoft SQL Server | Enterprise inventory, stores, procurement, maintenance, asset records. | Host/IP, port, database, read-only user, SSL/VPN where required. | Recommended through staged import first. Direct write-back should be approved carefully. |
| MySQL / MariaDB | Custom ERP, web apps, inventory portals, warehouse systems. | Host/IP, port, database, username, password, table mapping. | Use read-only access for discovery. Import into WYNTIQ after mapping and validation. |
| PostgreSQL | Modern internal applications, analytics databases, operations systems. | Connection string or host/IP credentials, schema/table mapping. | Can support scheduled import where network policy allows. |
| Azure SQL | Cloud-hosted customer database, central stock, procurement, or ERP extensions. | Azure SQL endpoint, firewall rules, SQL user or managed access model. | Customer IT must allow secure connectivity. Offline WYNTIQ devices still keep local copies. |
| Azure Storage / Files | Shared CSV drops, backup files, import/export folder, branch data exchange. | Approved storage path, SAS/token, or customer-controlled access. | Useful for scheduled file-based integration without direct database access. |
| REST API | Customer apps, ERP API, procurement system, support desk, vendor portal. | API base URL, API key/token/OAuth, field mapping, rate limit rules. | Best when customer system already exposes approved endpoints. |
| Other applications | Tally, SAP exports, Zoho, Odoo, custom desktop/web apps, logistics tools. | CSV export, API, database read, or agreed connector adapter. | Scope depends on customer access, data quality, and security approval. |
Database integration is not just a connection string. The important work is mapping, validation, role workflow, audit behaviour, and deciding whether WYNTIQ should import, export, or sync.
Review customer systems, tables, APIs, exports, and field names.
Match customer fields to WYNTIQ item, part, quantity, location, asset, and demand fields.
Clean duplicate items, missing part numbers, bad quantities, and location mismatches.
Load approved records into WYNTIQ through CSV or connector import.
Check totals, low stock, sample QR records, and user workflow accuracy.
If required, enable recurring import/export or approved API sync.
WYNTIQ integrations should be implemented with least privilege and customer approval. A safe connector design is more valuable than a fast but risky database connection.
Start with read-only database/API credentials during discovery and import testing.
Use VPN, private IP, firewall rules, or offline file transfer where customer policy requires it.
Do not push data into production systems until fields, IDs, quantities, and audit impact are approved.
Create backups before bulk import, schema mapping, or connector testing.
Track who imported what, when, from which source, and how many records were accepted or rejected.
Do not store database passwords or API tokens in public files, screenshots, or shared documents.
To estimate integration effort, WYNTIQ support needs enough information to understand the source data, security model, and desired direction of data movement.
Database type, application name, export format, API documentation, or sample files.
Table names, field names, sample rows, item IDs, part numbers, quantities, locations, and units.
One-time import, recurring import, export from WYNTIQ, or two-way sync requirement.
LAN, VPN, public IP, offline-only, Azure, private cloud, or file-drop access model.
Credential method, read-only access, firewall rules, audit rules, and approval process.
Number of items, assets, sites, users, records per day, and expected update frequency.
Share your source system, sample fields, and deployment environment. We can plan the safest import or connector path for your operation.