REST API · HTTP & JSON · S7-1500 WEB API · PYTHON CLIENTS & SERVICES · MES / ERP
The course for automation engineers who are told to “just send the data to MES”. Start with HTTP methods, status codes and JSON payload design, configure and use the S7-1500 web API with token authentication, then build real clients and services in Python with timeouts, retries and logging that hold up on a plant network. Finish by writing results into SQL Server, serving dashboards, choosing honestly between REST, OPC UA and MQTT, and tracing a failed call with a packet capture.
Classroom day batches · Online 7:30 PM–9:00 PM · Sunday 11:00 AM–5:00 PM
See the tools, controller features and practical topics used at each stage of the REST API integration path. Select a module to view exactly what you will work with.
Training progression: Module 01 gives you the HTTP and JSON vocabulary and a working Python environment, Module 02 uses the controller’s own web API and compares it with OPC UA, Module 03 builds the client and service code that runs in production, and Module 04 connects it to MES, ERP, SQL Server and dashboards — including what to do when a call fails only on the plant network.
View Detailed REST Training Contents →The course builds all three end to end. The first takes data out of the controller itself with Python in the middle; the second uses the SCADA server’s own IT connectivity, with no custom code at all; the third is the energy management variant, feeding an on-site SQL Server historian and a cloud EMS platform from the same collector. Which one fits depends on whether you already run WinCC, where the data has to end up, and who will maintain the integration after handover.
Controller-direct. A Python service subscribes to the CPU’s OPC UA server, builds the JSON payload and posts it to the business system — the flexible route when there is no SCADA layer in between, or when the payload has to be shaped exactly to someone else’s API contract.
SCADA-direct. WinCC V8 ships the IT/OT connectivity in the product: a REST API that IT applications query, a REST Connector that pushes runtime and archive values outward, and MQTT publishing for broker-based consumers — all configured rather than coded.
The energy management variant, and the one customers ask for most often. Meters are read by the controller, the Python collector builds interval records with tariff windows and kWh per tonne, and the same JSON goes two ways — into a SQL Server historian on site for reports, and out to a corporate or cloud EMS platform over a REST API with a local buffer so nothing is lost when the link drops.
How we choose on site: if WinCC is already the system of record, we use its own connectivity and keep the integration configurable. If the data has to leave a controller with no SCADA in front of it, or the payload needs logic the SCADA cannot express, the Python service is the honest answer. Either way the rule holds — convert once inside the plant, and never let a business system poll the controller directly.
The course is organised as four practical modules covering 15 hands-on topics. Every topic below is a written guide with working code you can open before or after the session — from HTTP and JSON basics through the S7-1500 web API to Python clients, services and full MES or ERP integration.
Start with the vocabulary the IT side already uses: requests and responses, methods and status codes, JSON payload structure and data type mapping, and a clean Python environment to test all of it from.
Install Python and VS Code and add requests, so every REST call in the course can be written, run and debugged on your own machine.
View training topic →02Keep each integration isolated in its own environment and reproduce it on the plant server from requirements.txt.
View training topic →03How Python types, JSON fields and database columns line up — timestamps, decimals and nulls, which is where most integration payloads break.
View training topic →Modern Siemens controllers expose a REST web API of their own. This module configures it, reads and writes tags through it, and compares it honestly with the OPC UA route on the same CPU.
Enable the web API on the CPU, log in for a token, read and write tags over HTTPS, and see the same data through OPC UA and WinCC for comparison.
View training topic →02The alternative route on the same controller — typed namespace, certificates and subscriptions — so the choice between the two is made on evidence.
View training topic →Write the code that actually runs in a plant: a client that consumes an MES or ERP endpoint, a small service that exposes plant data, structured into modules with real error handling and logging.
Build and consume REST endpoints in Python — GET, POST, headers, query parameters, JSON bodies and response handling.
View training topic →02Structure a growing integration into modules and classes so an API client stays maintainable when the endpoint changes.
View training topic →03Timeouts, retries, connection failures and non-200 responses handled properly, with a log file that explains what a scheduled call did overnight.
View training topic →04Pull the plant data your API will serve out of SQL Server and shape it into the JSON structure the consumer expects.
View training topic →Complete the loop: write API results back to the database, compare REST against MQTT and OPC UA per requirement, publish to dashboards, and troubleshoot an HTTPS call when it silently fails on a plant network.
Store what the API returns — production orders, material data, quality results — with parameterised inserts and commit handling.
View training topic →02Ten working scripts to adapt for the database side of any integration, covering create, read, update and delete.
View training topic →03Where a broker beats a request/response API — high-rate telemetry, many consumers and unreliable WAN links.
View training topic →04The publish/subscribe alternative in Python, so the REST versus MQTT decision is made from having built both.
View training topic →05Serve the data to a dashboard that people use: which KPIs, which queries behind them and how often they refresh.
View training topic →06Trace an API call that fails on the plant network — proxy interception, TLS handshake failures, blocked ports and 4xx responses.
View training topic →REST is the request and response style used by almost every business application: a client asks an endpoint over HTTP or HTTPS and receives a JSON answer. In a plant it is the natural way to exchange records with MES, ERP, quality systems and web dashboards — production orders, material data, batch results and shift summaries.
Yes on modern controllers. The S7-1500 web API is configured and used in this course: you log in for a token and then read and write tags over HTTPS. It is useful for low-rate, record-style exchange, and the course is equally clear about where OPC UA is the better choice on the same CPU.
REST for request and response record exchange with business systems, OPC UA for typed and secured access to controller data, MQTT for high-rate telemetry to many consumers over an unreliable link. Most working architectures use more than one, and the course builds each so the decision comes from experience rather than a vendor slide.
No. The first module sets up the environment and the later modules introduce the code step by step. If you have already done a Python course, you will move faster through the client and service building, but it is not assumed.
HTTPS with valid certificates, authentication by API key or bearer token with proper expiry handling, credentials kept out of the script, and the controller never exposed directly to an outside network. The gateway or application in the DMZ holds the connection, and the zone rules are written down for the IT team.
They can if the design is wrong. Controllers cap concurrent sessions and every request costs CPU time, so the course covers request rate, caching and the pattern that avoids the problem entirely — a service reading the plant database rather than every consumer polling the controller.
Both. You consume an MES or ERP endpoint as a client, and you expose plant data as a small service so a dashboard or another system can query it. In practice most integrations need the two directions.
That is a normal situation and it has a method: check proxy interception, TLS handshake failure, blocked ports and the actual status code returned. The final module traces exactly this with a packet capture so the answer comes from evidence rather than guesswork.
Classroom sessions run in the day batches and live online sessions run from 7:30 PM to 9:00 PM on weekdays, with a Sunday batch from 11:00 AM to 5:00 PM. Corporate and in-plant groups can request a different schedule.
Send your requirement for REST API integration training. Mention the system you have to exchange data with (MES, ERP, quality or a web platform), your controller, and whether you need to consume an endpoint, expose one or both, so the labs match your integration. Online batch runs 7:30 PM to 9:00 PM on weekdays and 11:00 AM to 5:00 PM on Sunday.
Explore the four modules, the controller and Python setup used in the labs, the integration targets covered and classroom or online batch options.
Content reviewed: 18 September 2026