PI Web API vs AF SDK
Two main ways to access PI System data programmatically. This page gives you an honest, detailed comparison so you can choose the right tool -- or use both.
What they are
PI Web API is a RESTful HTTP service that exposes PI System data as JSON over HTTPS. Any language or tool that can make HTTP requests can use it. It runs as an IIS-hosted service on a Windows server and connects to PI Data Archive and PI AF Server on the backend using AF SDK internally.
AF SDK (Asset Framework SDK) is a .NET class library that communicates directly with PI Data Archive and PI AF Server using proprietary protocols (PI-RPC and AF-RPC). It must run on a Windows machine with the SDK installed and requires .NET Framework 4.8 or .NET 6+ (via compatibility shims from AVEVA).
Architecture comparison
PI Web API architecture
Your code talks to PI Web API over HTTPS. PI Web API then talks to PI Data Archive and PI AF Server using AF SDK internally. This means PI Web API is essentially a RESTful wrapper around AF SDK, adding HTTP overhead but gaining language/platform independence.
Your Code (Python, JS, Java, Go, etc.)
|
| HTTPS / JSON (port 443)
v
PI Web API (IIS on Windows)
|
| AF SDK (internal, in-process)
v
PI Data Archive + PI AF ServerAF SDK architecture
Your code uses AF SDK directly to connect to PI Data Archive and PI AF Server over proprietary binary protocols. No intermediary server, no HTTP serialization.
Your Code (.NET on Windows)
|
| PI-RPC / AF-RPC (proprietary TCP, port 5450/5457)
v
PI Data Archive + PI AF ServerPI Web API is built on AF SDK
Because PI Web API uses AF SDK internally, any feature available in PI Web API is also available in AF SDK. The reverse is not always true: some AF SDK features (like data pipe callbacks, AFCalculation client-side evaluation, and some advanced AF queries) have no REST equivalent yet.
Detailed comparison
| Criteria | PI Web API | AF SDK |
|---|---|---|
| Protocol | HTTPS / REST / JSON | Proprietary TCP (PI-RPC, AF-RPC) |
| Languages | Any (Python, JavaScript, Java, Go, Rust, etc.) | .NET only (C#, VB.NET, F#, PowerShell) |
| Client platform | Any OS (Linux, macOS, Windows, containers, cloud) | Windows only (.NET Framework 4.8 or .NET 6+) |
| Client installation | None. Just network access to the server. | AF SDK installer on every client machine (~200 MB) |
| Authentication | Basic, Kerberos, NTLM, Bearer (OpenID Connect) | Windows Integrated only (Kerberos/NTLM) |
| Firewall requirements | Port 443 only (standard HTTPS) | Ports 5450, 5457, 5459 (non-standard, often blocked) |
| Single-value read latency | ~5-20 ms (HTTP overhead) | ~1-5 ms (direct connection) |
| Bulk read (100K values) | ~2-8 seconds (JSON serialization overhead) | ~0.5-2 seconds (binary protocol, less serialization) |
| Bulk write (10K values) | ~1-4 seconds | ~0.2-1 second |
| AF hierarchy traversal | Full access via REST. Requires multiple requests for deep trees. | Full access with lazy-loaded object model. More ergonomic for deep trees. |
| Event frames | Supported (CRUD + search) | Supported with richer query capabilities (AFEventFrameSearch) |
| Real-time subscriptions | Channel endpoint (long-polling / WebSocket-like). Less mature. | Native data pipe with callbacks (AFDataPipe). Production-proven. |
| Calculations | Server-side via calculation endpoints | Client-side via AFCalculation or server-side |
| Batch operations | Batch endpoint with dependent requests and RequestTemplate | Native multi-call methods (PIPointList.CurrentValue, etc.) |
| Versioning | REST API with backward compatibility. New features via new endpoints. | Assembly version tied to PI System version. Breaking changes between major versions. |
| Containerization | Clients run anywhere. Server requires Windows container. | Requires Windows container or VM. No Linux support. |
Performance characteristics
These numbers are approximate and depend on network conditions, server hardware, and PI System load. They represent typical performance observed across multiple enterprise PI deployments.
| Operation | PI Web API | AF SDK | Notes |
|---|---|---|---|
| Single snapshot read | 5-20 ms | 1-5 ms | HTTP overhead. Use batch endpoint to amortize. |
| 100 snapshot reads (batch) | 50-150 ms | 10-30 ms | PI Web API batch reduces round trips significantly. |
| 100K recorded values | 2-8 s | 0.5-2 s | JSON serialization is the main overhead for PI Web API. |
| 1M recorded values | 20-60 s | 5-15 s | For this volume, AF SDK is clearly faster. |
| Write 10K values | 1-4 s | 0.2-1 s | AF SDK uses UpdateValues which is optimized for bulk writes. |
| AF element traversal (1000 elements) | 2-10 s | 0.5-2 s | PI Web API requires one request per level. AF SDK lazy-loads. |
PI Web API performance optimizations
You can close much of the performance gap with PI Web API by using the batch endpoint, selectedFields to reduce response size, streamsets for multi-point reads, and server-side interpolation/summaries instead of pulling raw data.
When to use PI Web API
- You are using Python, JavaScript, Java, or any non-.NET language. There is no AF SDK for Python. PI Web API is your only option for cross-platform access.
- You are running on Linux, macOS, or in the cloud. AF SDK requires Windows and the SDK installer.
- You are building a web application or microservice. REST endpoints are easy to consume from any frontend or backend.
- You want zero client-side installation. PI Web API only requires network access to the server.
- You are integrating with non-AVEVA tools. Postman, Power Automate, Azure Logic Apps, Grafana, and other tools can call REST APIs directly.
- Firewall rules are strict. PI Web API uses standard HTTPS (port 443), which is typically already allowed. AF SDK requires non-standard ports (5450, 5457) that may be blocked.
- You need Bearer/OpenID Connect authentication. AF SDK only supports Windows Integrated authentication.
When to use AF SDK
- You are building a .NET application on Windows. AF SDK provides a rich, strongly-typed object model that is more ergonomic in C# than raw HTTP calls.
- You need maximum throughput for bulk operations. Direct protocol access avoids HTTP and JSON serialization overhead. For moving millions of values, AF SDK can be 3-5x faster.
- You need real-time data subscriptions with callbacks. AF SDK's AFDataPipe provides a native, production-proven subscription model that is more mature than PI Web API channels.
- You need advanced event frame queries. AFEventFrameSearch provides richer query capabilities than the PI Web API event frame endpoints.
- You are extending PI System Management Tools or ProcessBook. These products use AF SDK internally, so extending them requires the same SDK.
- You need client-side calculations. AFCalculation allows you to evaluate PI expressions on the client side without a round trip to the server.
Code comparison: same task, both approaches
Read the last 24 hours of recorded values for a PI point and compute the average.
PI Web API (Python)
import requests
import pandas as pd
session = requests.Session()
session.auth = ("DOMAIN\\user", "password")
session.verify = "/path/to/ca-bundle.pem"
BASE_URL = "https://pi-server/piwebapi"
# Look up the point by path
resp = session.get(
f"{BASE_URL}/points",
params={"path": "\\\\MY-DA\\Temperature_Reactor1"},
)
web_id = resp.json()["WebId"]
# Read recorded values with selectedFields for performance
resp = session.get(
f"{BASE_URL}/streams/{web_id}/recorded",
params={
"startTime": "*-24h",
"endTime": "*",
"maxCount": 50000,
"selectedFields": "Items.Timestamp;Items.Value;Items.Good",
},
)
items = resp.json()["Items"]
# Convert to DataFrame and compute average
df = pd.DataFrame(items)
df = df[df["Good"] == True] # Filter bad quality
avg = df["Value"].mean()
print(f"24h average: {avg:.2f}")AF SDK (C#)
using OSIsoft.AF;
using OSIsoft.AF.PI;
using OSIsoft.AF.Time;
using OSIsoft.AF.Data;
// Connect to PI Data Archive (uses Windows Integrated Auth)
var piServer = PIServer.FindPIServer("MY-DA");
piServer.Connect();
// Find the point
var point = PIPoint.FindPIPoint(piServer, "Temperature_Reactor1");
// Read recorded values
var timeRange = new AFTimeRange("*-24h", "*");
var values = point.RecordedValues(
timeRange,
AFBoundaryType.Inside,
filterExpression: null,
includeFilteredValues: false,
maxCount: 0 // 0 = no limit
);
// Compute average (filtering bad quality)
var goodValues = values
.Where(v => v.IsGood && v.Value is float)
.Select(v => (float)v.Value)
.ToList();
double avg = goodValues.Average();
Console.WriteLine($"24h average: {avg:F2}");Lines of code comparison
The AF SDK version is more concise because the object model handles connection management, type conversion, and quality filtering more naturally. However, the PI Web API version runs on any platform without installing anything on the client.
Migrating from AF SDK to PI Web API
Many organizations are migrating from AF SDK to PI Web API as they move to cloud infrastructure, containerized deployments, and cross-platform languages. Here are the key patterns.
Concept mapping
| AF SDK concept | PI Web API equivalent | Notes |
|---|---|---|
| PIServer.Connect() | GET /piwebapi/ | No persistent connection in PI Web API. Each request is independent. |
| PIPoint.FindPIPoint() | GET /points?path= | Returns a WebID instead of a PIPoint object. |
| point.CurrentValue() | GET /streams/{webId}/value | Returns JSON with Value, Timestamp, Good fields. |
| point.RecordedValues() | GET /streams/{webId}/recorded | Use boundaryType parameter. Watch for maxCount truncation. |
| point.InterpolatedValues() | GET /streams/{webId}/interpolated | Direct equivalent. |
| point.Summary() | GET /streams/{webId}/summary | Direct equivalent. Specify summaryType parameter. |
| point.UpdateValue() | POST /streams/{webId}/value | Use updateOption parameter for Replace/Insert behavior. |
| PIPointList.CurrentValue() | GET /streamsets/{webId}/value | Or use the batch endpoint for arbitrary multi-point reads. |
| AFElement.Elements | GET /elements/{webId}/elements | Returns child elements. Paginated. |
| AFDataPipe | GET /streams/{webId}/channel | PI Web API channels are less mature. Consider polling as alternative. |
Migration strategy
- Start with new services. Build new integrations on PI Web API. Do not migrate existing stable AF SDK code unless there is a compelling reason (cloud migration, platform change).
- Abstract the data access layer. Create an interface (e.g.,
IPIDataReader) that both AF SDK and PI Web API implementations satisfy. This lets you swap implementations without changing business logic. - Migrate read-heavy services first. Read operations are simpler to migrate than writes. The PI Web API read endpoints are direct equivalents of AF SDK read methods.
- Keep AF SDK for high-throughput write services. If a service writes millions of values per day, the AF SDK performance advantage may justify keeping it on Windows.
- Replace AFDataPipe with polling. If you use AF SDK data pipes for real-time subscriptions, replace with periodic polling via PI Web API until the channel endpoint matures.
Hybrid architecture patterns
Many organizations use both PI Web API and AF SDK. Here are proven patterns for combining them.
Pattern 1: AF SDK for ingest, PI Web API for read
Use AF SDK on a Windows server for high-throughput data ingestion (writing millions of values from OPC, PLC, or file sources). Use PI Web API for all read operations from dashboards, notebooks, cloud applications, and cross-platform services.
Data Sources (OPC, PLC, files)
|
| AF SDK (high-throughput writes)
v
PI Data Archive
^
| PI Web API (reads)
|
Cloud Dashboards, Python Notebooks, Web AppsPattern 2: AF SDK for real-time, PI Web API for historical
Use AF SDK data pipes for real-time alerting and monitoring on Windows servers. Use PI Web API for historical analysis, reporting, and data science workloads from any platform.
Pattern 3: Gradual cloud migration
Expose PI Web API through a reverse proxy or API gateway at the network edge. Cloud services call PI Web API through the gateway. On-premises services continue using AF SDK directly. Over time, migrate on-premises services to PI Web API as they get containerized.
Cloud Services (Azure, AWS, GCP)
|
| HTTPS (through API Gateway / VPN)
v
PI Web API (on-premises Windows server)
|
| AF SDK (internal)
v
PI Data Archive + PI AF Server
^
| AF SDK (direct)
|
On-premises Windows services (legacy)AVEVA Cloud (PI Cloud Connect)
AVEVA also offers PI Cloud Connect and AVEVA Data Hub for cloud-native PI data access. If your organization is investing in AVEVA's cloud ecosystem, evaluate these alongside PI Web API for cloud workloads.
Decision guide
| If you... | Use |
|---|---|
| Are using Python, JavaScript, Java, or Go | PI Web API |
| Are on Linux, macOS, or in containers | PI Web API |
| Are building a web application | PI Web API |
| Are building a .NET Windows service | AF SDK (or PI Web API if planning cloud migration) |
| Need to move millions of values per hour | AF SDK |
| Want zero client installation | PI Web API |
| Need real-time data pipe subscriptions | AF SDK |
| Need advanced event frame queries | AF SDK |
| Are integrating with cloud services | PI Web API |
| Have strict firewall rules (only 443 open) | PI Web API |
| Are starting a new project in 2026 | PI Web API (unless AF SDK performance is required) |
You can use both
Many organizations use AF SDK for high-throughput backend services on Windows servers and PI Web API for cross-platform dashboards, notebooks, and integrations. They are not mutually exclusive. Pick the right tool for each specific use case.