Keep the systems that work. Fix the layer between them.
No distributor wants another rip-and-replace. Wholara is built to sit between the systems you already trust, take over the operational decisions, and write confirmed transactions back where they belong.
Where Wholara sits in your stack.
Read it as a division of labour: systems of record keep the truth, Wholara decides what to do about it.
Systems of record stay authoritative
Items, customers, suppliers, financial postings, tax and statutory history remain where they are. Wholara reads them, and writes back only confirmed operational transactions.
Wholara takes the operational layer
Demand and cover, replenishment decisions, pricing application and validation, order intake and validation, allocation, substitution, exception handling and the audit trail that ties them together.
Exact connector availability depends on your specific systems and versions. During scoping we confirm what exists already, what needs building, and how long each path takes — in writing, before you commit.
Three ways to connect, chosen per system.
Most customers end up using more than one. The method is a practical decision about your systems, not a product tier.
Managed connectors
Built and maintained for systems we integrate with regularly. Field mapping, incremental sync, conflict handling and error reporting are handled for you.
Best for
- Common ERP and accounting platforms
- Established e-commerce platforms
- Standard EDI document sets
What you provide
- Credentials and a test environment
- Confirmation of custom fields in use
- A named contact for validation
Scheduled file exchange
For systems that prefer to publish extracts. Wholara ingests CSV or XML on a schedule, validates every record, and produces a rejection report when something does not match.
Best for
- Older ERP installations with no usable API
- Nightly item, cost and customer updates
- Legacy WMS scheduling exports
What you provide
- A file location and a schedule
- Sample files with edge cases included
- An owner for rejection reports
REST API and webhooks
For real-time flows and anything bespoke. Documented endpoints, revision-safe records and event webhooks for order, receipt, shipment and exception activity.
Best for
- Custom middleware or an internal platform
- Real-time stock and price feeds
- Event-driven workflows and alerts
What you provide
- A developer or integration partner
- Auth setup and environment plan
- Rate and volume expectations
API at a glance
- JSON over HTTPS, predictable resource paths and cursor pagination
- Idempotency keys on all write operations
- Source key and revision on every record for safe retries
- Webhooks signed and retried with exponential backoff
- Sandbox tenant for development and testing
- Full endpoint documentation and example payloads shared during onboarding
{
"item_code": "SKU-1842",
"description": "Pressure valve, 1\" brass",
"unit": "EA",
"locations": [
{ "code": "EATL", "on_hand": 210, "committed": 148, "available": 62 },
{ "code": "CDAL", "on_hand": 134, "committed": 96, "available": 38 },
{ "code": "WRNO", "on_hand": 68, "committed": 42, "available": 26 }
],
"inbound": 200,
"cost": { "latest": 51.20, "average": 49.85, "replacement": 52.00 },
"lead_time_days": { "promised": 14, "actual_avg": 18.0, "variation": 4.2 },
"service_target": 0.98,
"source": { "system": "erp", "key": "1842", "revision": 88214 },
"updated_at": "2026-05-18T09:15:42Z"
}Illustrative response shape. The full schema and field reference are provided during onboarding.
What flows in each direction.
A clear division prevents the classic integration failure: two systems both believing they own the same field.
| System | Into Wholara | Out of Wholara | Typical frequency |
|---|---|---|---|
| Record systems | |||
| ERP and finance | Items, customers, suppliers, costs, price bases, open orders, credit position | Confirmed purchase orders, sales order confirmations, receipts, adjustments, shipment confirmations | Near real-time on change, with a nightly reconciliation |
| Accounting | Ledger references, tax codes, payment status | Invoice and credit data generated from fulfilled orders | Per document, plus a daily control total |
| WMS and barcode layer | Physical movements, picks, receipts, counts and variances | Work instructions, allocation decisions, expected receipts | Real-time at scan, or batch per wave |
| Demand channels | |||
| E-commerce and portals | Orders, customer registrations, quote requests | Availability, price and lead-time feeds, order status | Availability continuously; orders as placed |
| EDI and trade documents | Purchase orders (850), acknowledgements, advance ship notices, invoices received | Acknowledgements (855), ship notices (856), invoice data (810) | Per document exchange |
| Email and document intake | Purchase orders as PDF or structured text, supplier confirmations | Order acknowledgements, delivery notifications, exception summaries | Continuous |
| Logistics and settlement | |||
| Carriers and shipping | Rate quotes, label references, tracking events, delivery and failure status | Shipment details, consignment data, collection requests | Per shipment, with tracking updates as received |
| Suppliers and punchout | Confirmations, promise dates, price updates, catalogue data | Purchase orders, follow-ups, forecast and rebate reports | Per transaction, plus agreed scheduled reports |
How we build integrations so they survive year two.
Most integration pain appears months after go-live, when records change shape and nobody is watching.
Idempotent by default
Every write carries a source key and revision. A timeout and retry produces one record, not two — which is the difference between a sync you trust and a duplicate invoice enquiry.
Observable
Each sync run reports records in, records out, conflicts, rejections and duration. If a flow silently stops, you find out from a monitor rather than from a customer.
Reconcilable
Daily control totals are produced for the flows that affect money and stock, so an integration error is caught by arithmetic rather than by month-end surprise.
Fail visibly, pause safely
When a source system is unavailable, affected workflows pause rather than operating on stale data. Paused workflows are shown on the operations board with the reason.
Versioned mappings
When a source field changes — a renamed column, a new unit code — the mapping change is versioned and dated, so behaviour before and after is explainable.
No hidden writes
Wholara does not amend records in your ERP beyond the documented flows. If something is written, it appears in the integration log with the workflow that produced it.
Integration questions
If your system is unusual, that is a normal conversation rather than a disqualification.
Connector coverage grows over time, and publishing a list here would guarantee it goes stale. The honest answer is that we confirm this during scoping, in writing, along with the effort involved.
Practically: if your system exposes any of an API, a scheduled export, or a database read we can work with, there is a route. The variable is effort, not feasibility.
Either, and often both. Managed connectors are ours. Bespoke middleware is usually your IT team or your existing ERP partner, using our documented API, with our engineers available to review the approach. We do not insist on owning work that your team is better placed to maintain.
Managed connectors are maintained against supported versions, and we tell you when a version you rely on is approaching end of support. For bespoke integrations, the API contract is versioned so an upgrade on your side does not silently break a flow.
Yes, and it is expected. A sandbox tenant mirrors your configuration so mappings, rules and error handling can be tested against real data shapes before anything touches production. Sandbox usage is part of onboarding rather than an extra.
Traffic is encrypted in transit and stored data is encrypted at rest, with tenant data logically separated. Authentication uses scoped credentials per integration, so a connector can only reach the resources it needs. Access, IP allow-listing and rotation policy are agreed during onboarding.
Yes. Scheduled extracts and API access let you load operational records into your existing BI environment, so Wholara does not become a reporting island. We will document which fields are operational and which originate in your systems of record, so definitions stay consistent.
Tell us what you run. We will tell you what it takes.
Bring your system names and versions to the demo and you will get a straight answer on effort and sequence.
wholara.net