API

Core meaning

An **API (Application Programming Interface)** is a formally defined interface that allows one software component or system to interact with another by exchanging data or invoking functions. It specifies:

– What operations are available (for example, `GET /orders/{id}`)
– What inputs are required (parameters, payload structure)
– What outputs are returned (response format, status codes)
– The rules and protocols for communication (for example, HTTP, message queues)

APIs are used to connect applications without exposing internal code or database structures. They create a stable contract between systems so that they can interoperate in a predictable, controlled way.

Use in industrial and regulated environments

In industrial operations and manufacturing, APIs commonly connect:

– **MES and ERP** systems for exchanging orders, material master data, inventories, and status updates
– **MES and external suppliers** for work-in-process (WIP) status, subcontracting operations, and shipment/receipt confirmations
– **OT systems and IT systems** (for example, historians, LIMS, PLM, or quality systems) for sharing process data, results, or electronic batch record elements
– **Plant systems and cloud services** for analytics, reporting, and remote monitoring

APIs in regulated environments are typically accompanied by:

– Versioned specifications and change control
– Access control and authentication
– Logging of requests and responses where data is quality- or compliance-relevant

Types of APIs relevant to manufacturing

Common API types in this context include:

– **Web/REST APIs**: Use HTTP(S), JSON or XML payloads; widely used for MES–ERP and supplier integration.
– **SOAP or other XML-based APIs**: Still found in many legacy ERP and LIMS integrations.
– **Message-based APIs**: Implemented over message brokers (for example, publish/subscribe patterns) for event-driven data exchange.
– **Vendor-specific OT APIs**: Exposed by controllers, equipment interfaces, or historians for reading and writing process data (often wrapped by higher-level services).

The term “API” typically refers to the logical interface specification, not to the underlying transport or protocol alone.

Boundaries and exclusions

An API:

– **Is** a defined contract for system-to-system interaction (operations, data structures, rules).
– **Is not** the underlying database schema, even if the API exposes data from that database.
– **Is not** a user interface (UI) for human operators, although a UI may call APIs behind the scenes.
– **Is not** limited to web technologies; it can exist over many protocols, though HTTP/REST is common.

Common confusion

– **API vs. interface in general**: All APIs are interfaces, but not all interfaces are APIs. For example, a physical machine panel is an interface but not an API.
– **API vs. integration**: An API is one building block of an integration. A complete integration also involves mapping, transformation, orchestration, and operational procedures.
– **API vs. middleware**: Middleware platforms often host or route APIs, but they are separate concepts. The API is the contract; the middleware is the infrastructure running or brokering calls.

Site context: APIs for tracking external WIP

When tracking work-in-process (WIP) at external suppliers, APIs often:

– Expose operations for suppliers or logistics systems to update WIP status, quantities, and timestamps
– Allow MES to query current WIP, shipment, and receipt data from partner systems
– Support automated or semi-automated confirmation of process steps performed outside the main site

In such scenarios, clarity of the API specification, responsibilities for who calls which endpoints, and reliability of the data exchange are critical for maintaining traceability and compliance.