S7-1500 REST API Integration: Web API, OPC UA and WinCC Explorer Practical Lab

Separate the CPU API from your REST API

The S7-1500 Web API uses JSON-RPC 2.0 requests sent to https://<cpu-address>/api/jsonrpc. Siemens documents availability from firmware V2.8 for supported S7-1500 variants; check the actual CPU family and method support. It is not a built-in REST resource API with routes such as GET /units/101.

In this lesson an edge gateway reads the controller through its supported Web API or OPC UA interface and exposes an original REST resource to a reporting client. WinCC Explorer can continue reading the S7-1500 through the tested OPC UA channel. No REST feature of WinCC is assumed.

Lab scope: use an isolated training CPU/network, TIA Portal compatible with its firmware and a supported WinCC Classic release where required. Check the exact CPU order number, firmware, license and installed software before following configuration steps. Examples use read-only telemetry; no example writes a motor command. The addresses, tag names and values are teaching choices.

Prepare the read-only CPU Web API path

1. Confirm Web API support for the CPU variant, firmware and the methods you need.
2. In the training TIA Portal project, configure the CPU web server and HTTPS/certificate settings according to that release.
3. Configure a user with the required read permission. Siemens specifies read_value for PlcProgram.Read.
4. Confirm the test DB member is available to the web API under the project’s access settings.
5. Compile/download the intended configuration and check CPU diagnostics.
6. From an approved API client, validate the CPU certificate identity/trust and test the endpoint. Keep TLS verification enabled.

Use the API method/version discovery supported by your CPU to inspect capability. Being listed as a method does not mean the current user is authorized to call it.

Send login, read and logout requests

The following are example JSON request bodies. Submit them as HTTPS POST requests with Content-Type: application/json. Replace the placeholders in your local test client; do not embed real credentials in a public webpage.

{"jsonrpc":"2.0","method":"Api.Login",
 "params":{"user":"YOUR_READ_USER","password":"YOUR_PASSWORD"},"id":1}

On successful login, use the returned session token in the X-Auth-Token HTTP header of authenticated requests. The token is not a URL query parameter.

{"jsonrpc":"2.0","method":"PlcProgram.Read",
 "params":{"var":"\"DB_IIoT\".LevelPct","mode":"simple"},"id":2}

The symbolic variable spelling is an example. Confirm the name available through your CPU’s API browse/access configuration. Check both the HTTP result and the JSON-RPC body: an HTTP response alone does not prove the method succeeded. Handle an error object instead of assuming result always exists.

{"jsonrpc":"2.0","method":"Api.Logout","id":3}

Close the test session when finished. A successful scalar read returns a value; it does not automatically supply the same source-quality/timestamp information as an OPC UA DataValue. In the gateway, label read success and collection time accurately.

Define the application-facing REST resource

The following endpoint belongs to the gateway you implement, not to the PLC firmware:

GET https://YOUR-GATEWAY/api/v1/units/unit101/telemetry
Accept: application/json

One proposed success representation is:

{
  "unit": "unit101",
  "source": "s7-1500-lab",
  "level_pct": 50.0,
  "flow_m3h": 12.0,
  "pump_running": true,
  "quality": "read_success",
  "collected_at": "2026-09-06T10:30:00Z",
  "age_ms": 250
}

This is an original API contract. For an OPC UA source, retain its status and source time where available; for separate Web API reads, do not claim an atomic snapshot. Define timeouts, cache lifetime and what happens if only part of a multi-tag read succeeds.

Implement authentication on the gateway, keep controller credentials on its server side, bound source polling and restrict the resource to the approved fields. If the data is too old, return a defined stale/error result rather than a healthy cached value.

Test the contract instead of only the happy path

Change level in the PLC, then compare WinCC and the API response. Test wrong credentials, expired session, unavailable CPU and stale cache separately. An API login error belongs to authentication; a missing symbolic member belongs to data mapping.

Deliver: sanitized request/response samples, the chosen source path, the REST contract and error-test results. The HTTP resource above is a design to implement in your gateway, not an endpoint created by this website update.