API Integration Guide: Connecting OxMaint CMMS with Your FMCG Tech Stack
By spencer on March 10, 2026
Every FMCG facility already runs a collection of systems that are supposed to talk to each other — an ERP managing procurement and finance, a SCADA controlling production equipment, an MES tracking batch records and OEE, robotic controllers on the production floor, IoT sensors streaming condition data, and a BI platform attempting to synthesise all of the above into something a plant manager can act on. In practice, these systems rarely communicate at the speed the business needs, and the CMMS is usually the most isolated of all. Work orders are created manually from verbal handovers. Spare parts consumption is reconciled with ERP at month-end. Equipment fault data from SCADA sits in one system while the maintenance history sits in another. Oxmaint's API platform closes these gaps — providing REST APIs that connect your CMMS bi-directionally with every layer of your FMCG tech stack. This guide covers the integration patterns, connection methods, data flows, and configuration requirements for ERP, SCADA, MES, robotics, IoT, and BI integrations. Book a demo to walk through the architecture for your specific stack.
Oxmaint's REST API gives your engineering and IT teams full programmatic access to work orders, assets, PMs, spare parts, and audit data — with webhook support for real-time event-driven integrations across your entire FMCG tech stack.
Standard API Architecture — JSON Payloads, OAuth 2.0 Auth, Full Swagger Documentation
<200ms
API Response Time for Standard Endpoints — Suitable for Real-Time SCADA and IoT Integration
6+
System Categories Supported — ERP, SCADA, MES, Robotics, IoT, BI — With Webhook Events
Real-time
Webhook Delivery for Work Order, PM, and Fault Events — No Polling Required
Why FMCG Systems Fail to Talk to Each Other — And What It Costs
FMCG maintenance operations are complex integration environments. A beverage plant may have 800+ assets feeding data into a SCADA system that has never been connected to the CMMS. A food manufacturer's SAP instance holds every purchase order but has no visibility into which work order consumed which part. The cost of these disconnections is not abstract — it is measurable in emergency procurement premiums, reactive breakdown hours, and technician time lost to manual shift handover briefings that a connected CMMS would eliminate automatically.
Disconnected vs Connected CMMS — FMCG Operations Impact
12-month outcome comparison for a mid-size FMCG plant with 800–1,200 assets
Manual work order creation — average 18–35 min from alarm to WO raised
Batch Traceability
No link between maintenance events and production batch records — manual QA correlation
Maintenance KPI Reporting
Monthly spreadsheet compilation — 6–12 hrs/month management time
Oxmaint — Fully Integrated via API
Spare Parts Accuracy
Real-time ERP inventory debit on WO closure — zero reconciliation lag
SCADA Alarm Response
Automatic work order creation on alarm trigger — under 30 seconds alarm-to-WO
Batch Traceability
Every maintenance event linked to active MES batch ID — full audit trail for QA
Maintenance KPI Reporting
Live BI dashboard — MTTR, MTBF, PM compliance updated in real time via API
API integration reduces alarm-to-work-order time by 97% — from 35 minutes to under 30 seconds
How the Oxmaint API Works — Architecture Overview
The Oxmaint API is a RESTful HTTP API using JSON for all payloads. Authentication uses the OAuth 2.0 client credentials flow — your integration middleware obtains a Bearer token using its API key and secret, then passes that token in the Authorization header of every subsequent request. All endpoints are versioned and fully documented in the Oxmaint Swagger UI, accessible from your account dashboard. Rate limits are 1,000 requests per minute on standard plans and 5,000 per minute on enterprise — well above the requirements of typical FMCG integration scenarios where most events generate fewer than 100 API calls per hour.
Six Integration Layers in the FMCG Tech Stack — What Each Exchanges with Oxmaint
ERP System
SAP / Oracle / Tally
Oxmaint pushes spare parts consumption to ERP inventory in real time on work order closure. ERP pushes approved POs back to Oxmaint. Asset master data syncs bidirectionally to eliminate duplicate records.
SCADA / DCS
Ignition / Wonderware
SCADA pushes equipment alarms and fault codes to Oxmaint as automatic work order triggers. Oxmaint returns live work order status so SCADA dashboards show maintenance progress without switching systems.
MES Platform
Rockwell / Siemens Opcenter
MES passes active batch IDs to Oxmaint when maintenance events occur during production — creating the link between equipment condition and batch records that QA and regulators require.
Robotic Controllers
FANUC / ABB / KUKA
Robot controllers push cycle counts and error codes to Oxmaint automatically. PM work orders fire at the correct cycle count interval regardless of actual operating hours — far more accurate than calendar scheduling.
IoT Platform
AWS IoT / Azure IoT / ThingsBoard
IoT platforms stream vibration, temperature, and pressure data. When readings cross defined thresholds, the platform calls the Oxmaint API to create a predictive maintenance work order — before the fault stops production.
BI / Analytics
Power BI / Tableau / Looker
BI tools pull MTTR, MTBF, PM compliance, and downtime data from Oxmaint's pre-aggregated analytics endpoints — enabling unified operational dashboards that combine maintenance, production, and quality data.
Authentication — How Your Systems Connect to Oxmaint
Every integration connection to Oxmaint uses the same OAuth 2.0 client credentials flow. Your integration middleware — whether MuleSoft, Node-RED, a Lambda function, or a custom service — obtains a time-limited Bearer token using the API key and secret assigned in the Oxmaint Integration Hub. That token is then passed with every API request. Tokens last 60 minutes and should be refreshed proactively by your middleware rather than on expiry, to prevent gaps during high-activity integration windows.
OAuth 2.0 Authentication Flow — Four Steps
1
Retrieve API Credentials
Log into Oxmaint → Integration Hub → API Keys. Generate an API Key and Secret for your integration. Each integration environment (development, staging, production) should use separate credentials.
▼
2
Request a Bearer Token
Your middleware posts the API Key, Secret, and grant type (client_credentials) to the Oxmaint token endpoint. The response contains a Bearer token valid for 3,600 seconds.
▼
3
Pass Token in Every Request
Every API call includes the Authorization header with the Bearer token. Requests without a valid token receive a 401 Unauthorized response. Expired tokens return 401 — your middleware should detect this and re-authenticate automatically.
▼
4
Refresh Before Expiry
Configure your middleware to re-request a new token at 50 minutes (10 minutes before the 60-minute expiry). Cache the active token in memory — do not re-authenticate on every individual API call.
Work Order Endpoints — The Core Integration Object
Work orders are the central object in Oxmaint's API and the primary data exchange point for SCADA, IoT, and MES integrations. The highest-value pattern is automatic work order creation when an alarm or threshold condition is met — eliminating the 18–35 minute manual gap between a SCADA alarm firing and a work order being raised in the CMMS. Every work order created via API appears identically in the Oxmaint mobile app, dashboard, and all KPI reports — there is no distinction from manually-created orders.
POST
/v1/workorders
Create Work Order
Creates a new work order in Oxmaint. Used by SCADA and IoT systems to auto-create corrective or predictive work orders when alarms or thresholds are triggered. Returns the new work order ID, assigned technician, and creation timestamp.
asset_idrequiredOxmaint asset identifier for the affected equipment
titlerequiredShort description of the maintenance event or fault
sourceoptionalOrigin system identifier — e.g. scada_alarm, iot_platform
metadataoptionalKey-value object for sensor readings, alarm IDs, or batch references
GET
/v1/workorders
List Work Orders
Returns a paginated list of work orders filtered by asset, status, type, date range, or batch ID. Used by SCADA dashboards to display live maintenance status for specific assets, and by BI tools that pull raw work order data for custom reporting.
batch_idfilterRetrieve all WOs linked to a specific MES production batch
date_from / date_tofilterISO 8601 date range filter for created_at timestamp
page / limitpaginationPage number and results per page (max 100)
PATCH
/v1/workorders/{id}/metadata
Update Work Order Metadata
Adds or updates metadata fields on an existing work order without modifying its core fields. Used by MES systems to attach the active production batch ID to a work order that was created by SCADA or IoT, creating the cross-system traceability link for QA audits.
production_batch_idstringMES batch identifier active at time of maintenance event
product_skustringProduct being manufactured during the maintenance event
line_idstringProduction line identifier from MES
batch_startdatetimeISO 8601 timestamp when the active batch started
ERP Integration — Real-Time Spare Parts Sync
The ERP integration is the highest operational value connection for FMCG finance and procurement teams. When a technician closes a work order in Oxmaint and records the parts consumed, the Oxmaint webhook fires within 500ms and delivers the full consumption detail to your ERP endpoint — debiting inventory, posting the goods movement, and closing the procurement loop in real time. This eliminates the end-of-month reconciliation that typically costs FMCG plants $40,000–$90,000/year in emergency procurement overspend and 8–12 person-hours/month in manual data entry.
ERP Spare Parts Sync — Data Flow on Work Order Closure
1
Technician Closes Work Order in Oxmaint
Technician logs parts consumed, quantity used, and store location via the Oxmaint mobile app. Work order status changes to Closed. Parts consumption is recorded against the asset and the work order simultaneously.
▼
2
Oxmaint Fires workorder.closed Webhook
Within 500ms of closure, Oxmaint delivers the full payload — work order ID, asset ID, parts consumed (part number, description, quantity, unit cost, store location), labour hours, cost centre, and closure timestamp — to your configured ERP webhook endpoint.
▼
3
ERP Processes Goods Movement
Your ERP webhook receiver (SAP BAPI, Oracle API, or custom handler) processes the payload — debiting inventory for each consumed part, posting the goods movement document, and updating the maintenance cost centre. No manual data entry required.
▼
4
Reorder Trigger Fires if Stock Drops Below Minimum
If the consumed quantity brings stock below the configured minimum, Oxmaint's parts.low_stock webhook fires simultaneously — triggering an automatic purchase requisition in your ERP procurement workflow before the stock-out affects the next maintenance event.
Oxmaint provides pre-built ERP integration templates for SAP, Oracle, and Microsoft Dynamics — with SAP BAPI field mappings and Oracle API connector specifications included in the deployment package.
SCADA Integration — Automatic Work Order Creation from Alarms
The SCADA integration closes the most costly gap in FMCG reactive maintenance: the 18–35 minute delay between a SCADA alarm firing and a work order being raised in the CMMS. Most plants currently handle this with a manual process — a SCADA alarm triggers an operator call to the maintenance supervisor, who creates the work order after receiving a verbal description. Connecting SCADA directly to the Oxmaint API via an OPC-UA-to-REST bridge or SCADA scripting layer eliminates this chain entirely. The alarm fires, the work order is created, and the technician receives a mobile notification — all within 30 seconds.
SCADA to Oxmaint — Work Order Creation Field Mapping
How SCADA alarm data maps to Oxmaint work order fields on automatic creation
SCADA Alarm Tag
The equipment tag ID in your SCADA system (e.g. LINE3_MOTOR_VIB). Map to Oxmaint asset_id via a tag-to-asset lookup table configured in Integration Hub.
→ asset_id
Alarm Description Text
The alarm description string from your SCADA historian or alarm server. Include the alarm code and measured value in the description for faster technician diagnosis.
→ title + description
Alarm Priority Level
Map SCADA priority levels (e.g. P1/P2/P3 or High/Medium/Low) to Oxmaint priority values: critical, high, medium, or low. Configure the mapping table once in Integration Hub.
→ priority
Alarm Timestamp
ISO 8601 alarm trigger time from SCADA historian. Stored in Oxmaint work order metadata for correlation with equipment condition data from the same timestamp window.
→ metadata.alarm_time
Sensor Value at Alarm
The measured process value that triggered the alarm (e.g. 12.4 mm/s vibration). Stored in metadata alongside the configured threshold so technicians can see the deviation magnitude immediately.
→ metadata.sensor_value
SCADA Alarm ID
The unique alarm identifier from your SCADA alarm management system. Stored in Oxmaint metadata for bidirectional lookup — allows SCADA to query Oxmaint for the work order status by alarm ID.
→ metadata.alarm_id
The tag-to-asset lookup table is the critical configuration step for SCADA integration. Every SCADA tag that should trigger work orders must be mapped to an Oxmaint asset ID. This mapping is done once in Integration Hub and maintained as assets are added or renamed.
Robot Controller Integration — Cycle-Count Based PM Triggers
Robotic systems in FMCG packaging and palletising lines require maintenance based on cycle counts, not calendar time. A robot running three shifts accumulates cycles three times faster than one on a single shift — calendar-based PM schedules systematically over- or under-maintain robots on variable operating patterns. Connecting the robot controller to Oxmaint via API ensures PM work orders trigger at the correct actual cycle count. The integration uses a lightweight middleware process that reads the controller's cycle counter via OPC-UA or the controller's own REST interface, and pushes meter readings to Oxmaint every hour.
In the Oxmaint asset record for the robot, create a meter named total_cycles with unit cycles. Set the PM trigger threshold — for example, 250,000 cycles for joint greasing or 1,000,000 cycles for a full mechanical inspection. PM work orders will auto-generate when the meter crosses each threshold.
02
02
Push Hourly Meter Readings via API
Your integration middleware reads the robot controller's cumulative cycle count every hour via OPC-UA, Modbus TCP, or the controller's native REST interface, then posts the current meter value to the Oxmaint asset meter endpoint. Oxmaint tracks the meter progression and compares it against all configured PM thresholds on every update.
03
Automatic PM Work Order on Threshold
When a meter reading crosses the next PM threshold, Oxmaint automatically creates a PM work order with the correct task list, assigns it to the scheduled technician, and fires the pm.due webhook — notifying production scheduling and spare parts pre-positioning systems simultaneously, with no human intervention required.
IoT platforms collect continuous sensor streams from vibration sensors, thermal cameras, power quality monitors, and pressure transducers. The correct integration architecture applies alerting logic at the IoT platform layer — not in Oxmaint. When a sensor reading crosses a threshold for a defined duration, the IoT platform calls the Oxmaint API to create a predictive maintenance work order. This keeps API call volumes manageable while ensuring every meaningful equipment condition event becomes a tracked, assigned maintenance action before the fault causes a production stoppage.
IoT to Oxmaint — Predictive Work Order Data Flow
Field mapping from IoT sensor event to Oxmaint predictive work order
Sensor Device ID
The IoT sensor's device ID or topic path. Mapped to an Oxmaint asset_id via a device-to-asset registry maintained in Integration Hub. One sensor can be linked to one parent asset.
→ asset_id
Sensor Measurement Type
The parameter being measured — vibration (mm/s or g), temperature (°C), current draw (A), or pressure (bar). Used in the work order title and description to tell the technician what anomaly was detected.
→ title
Measured Value + Threshold
The actual sensor reading and the threshold that was crossed. Both values stored in work order metadata so technicians see the deviation magnitude immediately — not just an abstract "alarm fired" notification.
→ metadata
Breach Duration
How long the reading has been above threshold. Configuring a minimum breach duration (e.g. 5 minutes) at the IoT platform layer prevents transient spikes from generating false-positive work orders.
→ metadata
Severity Classification
IoT platform classifies severity based on how far above threshold the reading is — e.g. 110–130% = medium, 130%+ = high. Maps directly to Oxmaint work order priority, controlling technician notification urgency.
→ priority
Work Order Type
IoT-triggered work orders are always created as type predictive — distinguishing them from reactive corrective orders in Oxmaint's KPI reports. This split is how you measure the progress from reactive to predictive maintenance over time.
→ type: predictive
Never send raw sensor readings directly to the Oxmaint API. Apply threshold and duration filtering at the IoT platform layer first. A correctly designed IoT integration generates 10–100 Oxmaint API calls per hour — not thousands. The IoT platform holds the sensor data; Oxmaint holds the maintenance response to that data.
MES Batch Traceability and BI Analytics
The MES integration creates the audit link every QA team in FMCG needs: a permanent, retrievable connection between maintenance events and the production batch records that were active when those events occurred. When a maintenance event happens on an active production line, the MES calls the Oxmaint API to attach the current batch ID to the open work order. From that point, any QA investigation or regulatory inspection can retrieve all maintenance events associated with any specific batch — in seconds, rather than through hours of cross-referencing paper records. The BI analytics integration provides the complementary view: pre-aggregated KPI data pulled on a scheduled refresh into Power BI, Tableau, or Looker dashboards.
GET
/v1/analytics/kpis
Maintenance KPIs for BI Dashboards
Returns pre-aggregated maintenance KPI data grouped by asset class, line, site, or technician for a specified date range. Designed for direct consumption by Power BI Power Query, Tableau Web Data Connector, or Looker API — no raw data processing required in the BI tool.
site_idfilterLimit results to a specific facility
date_from / date_tofilterReporting period — ISO 8601 date range
Updates a named meter on an asset with a new reading. Used by robot controller integration to push hourly cycle counts. Oxmaint evaluates the new reading against all PM trigger thresholds configured for that meter and automatically creates PM work orders when thresholds are crossed.
meter_namerequiredName of the meter as configured in the Oxmaint asset record
valuerequiredCurrent cumulative meter reading (cycles, hours, km, or custom unit)
unitrequiredUnit of measurement — must match the unit configured on the asset meter
recorded_atrequiredISO 8601 timestamp when the reading was taken at the controller
sourceoptionalIdentifier of the system or middleware that submitted the reading
Webhook Events — Six Real-Time Integration Triggers
Webhooks allow downstream systems to react to Oxmaint events in near real-time without polling loops. Configure webhooks in the Oxmaint Integration Hub with a target URL, a secret key for payload signature verification, and the list of events to subscribe to. Every webhook delivery includes an X-Oxmaint-Signature header containing the HMAC-SHA256 signature of the payload body — your endpoint should verify this signature before processing to prevent spoofed requests. Failed deliveries are retried automatically with exponential backoff up to 5 attempts before being logged as failed in the Integration Hub.
Six Webhook Events — FMCG Integration Triggers and Downstream Actions
workorder.created
Work Orders
Fires on all work order creation — manual, API-triggered, or PM schedule. Use to notify SCADA or production scheduling that maintenance is in progress on a specific asset. Payload includes asset ID, priority, estimated duration, and assigned technician.
workorder.closed
Work Orders
Fires on WO closure with full parts consumption, labour hours, and resolution details. The primary ERP integration trigger — fires within 500ms so ERP inventory is updated before the technician has left the asset location.
pm.due
Planned Maintenance
Fires 48 hours before PM due date. Use to pre-position spare parts, confirm technician availability, and update production scheduling to accommodate the upcoming maintenance window before the day arrives.
pm.overdue
Planned Maintenance
Fires when a PM passes its due date unclosed. Use to trigger escalation notifications in Slack, Teams, or SMS and flag compliance risk in your BI dashboard — critical for GMP-regulated equipment in food and personal care facilities.
parts.low_stock
Spare Parts
Fires when a spare part falls below its defined minimum. Use to auto-create purchase requisitions in ERP or send procurement alerts — preventing stock-outs before they extend maintenance response times on critical equipment.
asset.downtime_started
Asset Events
Fires when an asset is marked as down. Triggers production scheduling adjustments, line rebalancing notifications, and OEE impact logging in MES or BI — without waiting for a manual status update from the maintenance team.
Integration Complexity and Implementation Effort
Not all integrations require the same implementation effort. This benchmark covers the six FMCG integration categories, their typical implementation timeframe, the recommended connection method, and the primary data flows that deliver the highest operational value. ERP and SCADA integrations typically deliver ROI fastest and should be prioritised in the first deployment sprint — with BI and robot controller integrations following in parallel as the asset data matures.
FMCG Integration Complexity Reference — Six System Categories
Webhook on WO closure → ERP goods movement. Bidirectional asset master sync via scheduled API pull. Purchase requisition creation on parts.low_stock event. SAP BAPI mappings provided by Oxmaint integration team.
2–3 weeks
SCADA / DCS
OPC-UA or REST bridge → Oxmaint API. Tag-to-asset mapping configured in Integration Hub. Alarm rules generate work orders. Oxmaint WO status polled back to SCADA every 60 seconds for dashboard display.
1–2 weeks
MES Platform
MES PATCH call to attach active batch ID to open WO. Oxmaint WO close event triggers MES equipment-available signal. Bidirectional downtime duration sync for OEE calculation in MES.
1–2 weeks
Robot Controllers
OPC-UA or proprietary REST → middleware → Oxmaint meter endpoint. Hourly cycle count push. PM auto-triggers on meter threshold — no human intervention. Configuration: tag mapping + PM threshold setup in Oxmaint.
3–5 days
IoT Platform
Cloud rule engine (AWS IoT Rules / Azure Stream Analytics) filters threshold breach events. Each breach calls Oxmaint work order creation endpoint. Device-to-asset registry configured in Integration Hub.
3–7 days
BI / Analytics
Power Query or Tableau connector calls /analytics/kpis on scheduled refresh. OAuth token configured once in BI connector settings. No custom middleware required — standard HTTP connector with auth header.
1–2 days
Facilities without existing middleware infrastructure should add 1–2 weeks for middleware setup and connectivity testing before integration build begins. Oxmaint's integration team provides architecture recommendations for greenfield integration environments as part of the deployment scoping call.
Oxmaint's integration team works directly with your engineers to scope, design, and validate your specific tech stack connections — SAP BAPI mappings, SCADA tag configuration, and IoT device registry included in every enterprise deployment.
Does Oxmaint provide a sandbox environment for testing integrations before going live?
Yes — every Oxmaint account includes a sandbox environment with separate credentials from your production instance. The sandbox mirrors the production API exactly and contains sample asset, work order, and parts data seeded for integration testing. Webhook deliveries in sandbox route to a dedicated test endpoint that logs payloads without triggering live downstream actions in your ERP or MES. Oxmaint's integration team recommends at least 2 weeks of sandbox validation before switching credentials to production — particularly for ERP integrations where incorrect parts consumption data would require manual correction in SAP or Oracle.
How does Oxmaint handle failed webhook deliveries?
Oxmaint implements automatic retry with exponential backoff for all failed webhook deliveries. A failed delivery is retried at 1 minute, 5 minutes, 30 minutes, 2 hours, and 12 hours. After 5 failed attempts, the event is marked as failed and logged in the Integration Hub for manual inspection and replay. To prevent duplicate processing on retries, implement idempotency handling in your endpoint using the event_id field included in every webhook payload — this unique identifier allows your receiver to safely deduplicate events if a retry delivers a payload that was already processed successfully.
Can we connect Oxmaint to SAP PM (Plant Maintenance) specifically?
SAP PM integration is the most commonly requested ERP connection for FMCG facilities. The architecture uses the Oxmaint REST API on one side and SAP's RFC/BAPI layer or SAP Integration Suite on the other, with a middleware layer handling data structure translation. The three highest-value data flows are: work order creation sync (SAP PM notifications → Oxmaint work orders), parts consumption push (Oxmaint WO closure → SAP goods movement posting), and equipment master sync (SAP equipment records → Oxmaint asset hierarchy). Oxmaint's integration team has documented SAP-specific BAPI field mappings for all three flows and provides these as part of every enterprise deployment package.
What middleware platforms work best for connecting Oxmaint to our SCADA and ERP systems?
The Oxmaint API works with any HTTP-capable integration platform without a dedicated connector. Integration platforms FMCG customers most commonly use include MuleSoft Anypoint Platform for SAP-heavy enterprises, Azure Logic Apps or AWS Step Functions for cloud-native architectures, Node-RED for OT/IT bridging where engineers prefer visual flow tools, and custom Python or Node.js microservices deployed alongside existing infrastructure. For SCADA and IoT integrations, OPC-UA-to-REST bridge services are the most common pattern — translating the SCADA protocol to standard REST calls before they reach the Oxmaint API endpoint. Oxmaint's integration team provides architecture recommendations for each combination during the deployment scoping call.
Is the API rate limit sufficient for a facility with many IoT sensors?
The standard limit of 1,000 requests per minute is sufficient for the vast majority of FMCG IoT scenarios. The critical design principle is that alerting logic belongs at the IoT platform layer — not in Oxmaint. AWS IoT Rules, Azure Stream Analytics, or an edge rule engine should evaluate whether a sensor reading constitutes an actionable event before calling the Oxmaint API. A correctly designed IoT integration generates 10–100 Oxmaint API calls per hour per facility, not thousands. If your architecture requires higher frequency calls — for example, synchronising meter readings every minute across hundreds of assets — enterprise rate limits and bulk meter update endpoints are available. Book a technical scoping call to discuss high-volume IoT architecture before beginning implementation.
Does Oxmaint provide implementation support for integration, or do we need a third-party consultant?
Oxmaint includes integration support in the deployment package — covering ERP field mapping templates, SCADA tag configuration guides, IoT device registry setup, sandbox validation assistance, and a dedicated implementation manager for the integration phase. Most FMCG plants complete standard integrations (ERP, SCADA, BI) without a third-party consultant. For facilities with complex requirements — SAP S/4HANA with custom Z-objects, multi-site Wonderware deployments, or FDA 21 CFR Part 11 audit trail integration — supplementary consulting may add value. Book a deployment consultation to assess your specific integration scope and timeline.
API Platform & Integration Hub
Connect Your FMCG Tech Stack to Oxmaint. ERP, SCADA, MES, IoT, Robotics, BI.
Oxmaint's REST API and webhook platform gives your engineering team full programmatic control over work orders, assets, PMs, and spare parts — with pre-built integration patterns for every layer of the FMCG tech stack and a dedicated integration team to support your deployment from scoping through go-live.
REST API with Full Swagger Documentation and Sandbox Environment
Webhook Events for Real-Time ERP, SCADA, and MES Reaction
Cycle-Count PM Triggers from FANUC, ABB, and KUKA Robot Controllers
IoT Threshold Alerts Auto-Create Predictive Work Orders — No Manual Step
Pre-Aggregated KPI Endpoints for Power BI, Tableau, and Looker
Dedicated Integration Team — SAP BAPI Mappings, SCADA Guides Included
