2 APIs across 1 product group.
| I want to... | Use | Why |
|---|---|---|
| Read or write variables and I/O on a SNAP-PAC-R or SNAP-PAC-S controller | PAC Control REST API | PAC Control exposes named int32, float, string, and table variables plus analog and digital I/O points on SNAP-PAC hardware. |
| Read or write data store tag values on a groov EPIC or groov RIO controller | groov View Public API | groov View exposes the data store abstraction with per-tag read and write endpoints and log retrieval on groov-family hardware. |
Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Opto 22 APIs, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fopto22.com" | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fopto22.com" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Once connected, ask your agent something like: “read and write Opto 22 controller variables and tags”.
What agents get from Jentic-routed access to this vendor.
Setup
Wiring the Opto 22 APIs by hand means building a Basic Auth header for PAC Control, appending an API key for groov View, and tracking each controller's named-variable and data store route tree yourself. Through Jentic you install once, add the PAC Control REST API and the groov View Public API from the Jentic directory, store each credential once, and your agent calls them.
Permission scoping
Both APIs put the target in the URL path, such as /device/strategy/ios/analogInputs/{ioName}/eu on PAC Control and /v1/data-store/read/{id} on groov View, so your own rules can pin an agent to reading a single input or tag. You choose which operations the agent may call, so write and setpoint operations are excluded unless you add them.
Credential isolation
Specific to using Opto 22 APIs through Jentic.
What can an AI agent do across the Opto 22 APIs?
An agent can read and write named strategy variables and analog or digital I/O points on SNAP-PAC controllers through the PAC Control REST API, and read and write data store tag values and pull system logs on groov EPIC and groov RIO controllers through the groov View Public API. That covers monitoring live plant values, pushing setpoints and recipes, and collecting diagnostics across a mixed Opto 22 estate.
Do the two Opto 22 APIs share one credential?
No. Each API has its own credential. PAC Control uses HTTP Basic Auth built from an API key id and value, and groov View uses an API key created in groov Manage. An integration that touches both hardware lines configures both credentials separately.
When should I use PAC Control versus groov View?
Use PAC Control when the target hardware is a SNAP-PAC-R or SNAP-PAC-S series controller and you need to read or write named variables or I/O points. Use groov View when the target is a groov EPIC or groov RIO controller and you need to read or write data store tag values or pull logs. The two APIs split cleanly by controller family.
Do these APIs require custom code on the controller?
BOOK A DEMO
Browse thousands of APIs and connect them all to your agent with Jentic One. One layer, one credential — every API your agent needs.
For Agents
An agent can read and write named variables, I/O points, and data store tags across Opto 22 SNAP-PAC and groov controllers over HTTPS, push setpoints and recipe values onto the plant floor, and pull controller logs for diagnostics.
Opto 22 exposes the internal strategy of its industrial controllers by symbolic name rather than by register address, so integrations read and write variables, I/O points, and tags the same way the control program does. The two APIs split by hardware line: PAC Control for SNAP-PAC controllers and groov View for groov EPIC and groov RIO devices.
Use for: Reading and writing named strategy variables, I/O points, and data store tags on Opto 22 SNAP-PAC and groov industrial controllers over HTTPS, and pulling groov system logs.
Not supported: PLC programming, strategy compilation, firmware updates, real-time streaming, bulk table loads
Credentials: No, each API uses a different credential: PAC Control uses HTTP Basic Auth carrying an API key id and value, while groov View uses an API key created in groov Manage.
All 2 Opto 22 OpenAPI specs are vendor-official and indexed by Jentic, kept validated and agent-ready.
Opto 22 builds industrial automation controllers, and its two REST APIs give external systems HTTPS access to the data running inside them. The PAC Control REST API reads and writes named strategy variables plus analog and digital I/O points on SNAP-PAC-R and SNAP-PAC-S controllers, while the groov View Public API reads and writes data store tag values and pulls system logs on groov EPIC and groov RIO controllers. Together they let dashboards, MES, ERP, and historian systems exchange live plant-floor data with Opto 22 hardware without custom controller code.
Each workflow spans multiple Opto 22 APIs. Jentic routes each operation to the right API automatically.
Unified plant-floor variable bridge
Read named variables and tags from both SNAP-PAC and groov controllers across a mixed plant floor and forward the values to a single MES, SCADA, or historian without writing separate controller code per hardware line.
GET /device/strategy/vars/int32s on the SNAP-PAC and GET /v1/data-store/read/{id} on the groov controller, then post both to a time-series database on a fixed interval
PAC Control REST API + groov View Public API
Setpoint and recipe push from business systems
Let an ERP or scheduling system push recipe values and setpoints onto whichever Opto 22 controller runs the target line, writing named variables on a SNAP-PAC or data store tags on a groov device when a job is released.
POST a value to the named float variable on the SNAP-PAC or POST /v1/data-store/write/{id} on the groov controller when an ERP job changes the recipe target
PAC Control REST API + groov View Public API
Cross-controller diagnostics collection
Gather diagnostic data across the Opto 22 estate by reading SNAP-PAC table variables such as alarm queues and history buffers and pulling groov system logs into one observability stack when an alert fires.
GET the named SNAP-PAC float table variable for the last batch results and GET /v1/logging/groovLogs.json, then forward both to an incident channel
PAC Control REST API + groov View Public API
Your SNAP-PAC key id and value and your groov API key are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'write a value to a SNAP-PAC float variable' or 'read a groov tag value', and Jentic returns the matching operation with its parameter schema so the agent calls the right endpoint on the right controller without browsing the reference docs.
No. Both APIs expose the controller's internal state over HTTPS by symbolic name, so an integration reads and writes variables, I/O points, and tags without adding firmware or custom logic to the device. PAC Control follows the same named-variable model the control strategy uses, and groov View routes everything through the data store abstraction.
Can these APIs move bulk data at high frequency?
They are built for named reads and writes against live controllers, not high-volume transfer. PAC Control caps JSON payloads at 3KB, so large table loads must be chunked, and neither API declares rate limits because throughput is bounded by the controller's CPU and your polling interval. Avoid aggressive sub-second polling across many tags.
What kinds of upstream systems connect to Opto 22 through these APIs?
Common consumers include MES, SCADA, ERP, scheduling systems, cloud dashboards, and historians. They read live variable and tag values for monitoring and analytics, write setpoints and recipes back to the controller, and pull table variables or system logs for diagnostics.
Both are in the Jentic catalogue with the same one-credential, intent-search pattern.