AWS Greengrass
Browse all Amazonaws APIsAgent-ready OpenAPI document · curated by JenticIOTDevice Managementhmac92 EndpointsREST
Know of an official OpenAPI document? Contribute it →
For Agents
Manage AWS Greengrass v1 groups, cores, device definitions, function definitions, subscriptions, and deployments to configure and roll out edge runtime configurations to fleets of IoT devices.
Use for: I need to create a Greengrass group for a new fleet of edge devices, Set up a function definition with a Lambda alias and pin it to a group version, List all Greengrass cores associated with a given group, Trigger a deployment of the latest group version to the connected core
Not supported: Does not handle device-side runtime, MQTT publish/subscribe, or device shadow updates - use for Greengrass v1 group orchestration and edge configuration only.
Jentic publishes the only available OpenAPI specification for AWS Greengrass, keeping it validated and agent-ready. AWS IoT Greengrass extends AWS onto edge devices so they can run Lambda functions, machine learning inference, and local messaging while staying connected to the cloud for management and analytics. The Greengrass v1 control-plane API manages groups, cores, devices, function definitions, subscription tables, resource definitions, and deployments across 92 operations. It is the orchestration layer for fleet-wide configuration of Greengrass cores running at the edge.
Install Jentic One Beta
Connect the AWS Greengrass to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the AWS Greengrass, 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.
1
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%2Famazonaws.com%2Faws-greengrass" | sh2
Step 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%2Famazonaws.com%2Faws-greengrass" | 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.
Capabilities
What an agent can do with AWS Greengrass API.
Create and version Greengrass groups that bundle cores, devices, functions, and subscriptions
Define core, device, function, resource, and connector definitions and pin specific versions to a group
Configure subscription tables that route MQTT messages between local devices, Lambda functions, and AWS IoT
Trigger group deployments to push configuration to Greengrass cores at the edge
Associate IAM service roles and certificate authorities with Greengrass groups
List historical deployments and reset deployments on misconfigured cores
Manage bulk deployments for fleet-wide rollouts and tag Greengrass resources
Use Cases
Patterns agents use AWS Greengrass API for, with concrete tasks.
★ Edge ML Inference Fleet Management
Deploy machine learning models to a fleet of Greengrass cores running on factory or retail hardware. Use function definitions to pin Lambda functions that wrap inference code, resource definitions to attach the model artifacts on local disk, and subscription tables to wire camera or sensor topics into the inference Lambda. A bulk deployment pushes the configuration to thousands of cores in one operation.
Create a function definition version with a Lambda function ARN, create a resource definition version with a local ML model path, attach both to a new group version, and call CreateDeployment with DeploymentType=NewDeployment
Industrial Telemetry Aggregation
Use Greengrass to aggregate sensor telemetry from local Modbus or OPC-UA devices, run filtering Lambdas at the edge, and forward only relevant events to AWS IoT Core. Subscription definitions wire devices to functions to cloud topics, and connector definitions add prebuilt integrations for common industrial protocols. Deployments take minutes once the group is configured.
Create a connector definition version including the IoT SiteWise OPC-UA Collector connector, attach it to the group, then create and deploy a new group version
Disconnected-First Retail Edge
Deploy Greengrass to retail point-of-sale or kiosk hardware that needs to keep working when the internet is down. Local device definitions and subscription tables let in-store devices talk to each other through the Greengrass core without round-tripping to the cloud, while the cloud receives a synced view once connectivity returns. The Greengrass v1 API manages this configuration centrally for thousands of stores.
Create a device definition version listing 12 store devices with their certificate ARNs, create a subscription definition version routing topic store/orders/* between devices and a local Lambda, and deploy the new group version
AI Agent Edge Operations
Through Jentic, an AI agent can act as an operator for an edge fleet - querying group state, running diagnostic deployments, and rolling configurations forward or back without operating the AWS console. Jentic exposes the 92 Greengrass operations as discoverable tools so the agent picks the right call from intent.
Search Jentic for 'redeploy aws greengrass group', load the CreateDeployment schema, and execute it for a specific group ID and group version
Key Endpoints
92 endpoints — jentic publishes the only available openapi specification for aws greengrass, keeping it validated and agent-ready.
METHOD
PATH
DESCRIPTION
POST
/greengrass/groups
CreateGroup - create a new Greengrass group
POST
/greengrass/groups/{GroupId}/versions
CreateGroupVersion - pin definition versions to a group
POST
/greengrass/groups/{GroupId}/deployments
CreateDeployment - deploy a group version to its core
POST
/greengrass/definition/functions
CreateFunctionDefinition - define edge Lambda functions
POST
/greengrass/definition/subscriptions
CreateSubscriptionDefinition - define MQTT routing
GET
/greengrass/groups/{GroupId}/deployments
ListDeployments - list group deployment history
PUT
/greengrass/groups/{GroupId}/role
AssociateRoleToGroup - attach an IAM service role
POST
/greengrass/groups
CreateGroup - create a new Greengrass group
POST
/greengrass/groups/{GroupId}/versions
CreateGroupVersion - pin definition versions to a group
POST
/greengrass/groups/{GroupId}/deployments
CreateDeployment - deploy a group version to its core
POST
/greengrass/definition/functions
CreateFunctionDefinition - define edge Lambda functions
POST
/greengrass/definition/subscriptions
CreateSubscriptionDefinition - define MQTT routing
GET
/greengrass/groups/{GroupId}/deployments
ListDeployments - list group deployment history
PUT
/greengrass/groups/{GroupId}/role
AssociateRoleToGroup - attach an IAM service role
Why Jentic?
What agents get from Jentic-routed access to this vendor.
Setup
Wiring AWS Greengrass by hand means building SigV4 request signing, resolving the Greengrass host, and handling AWS throttling and retries yourself. Through Jentic you install once, import Greengrass from the API Directory, store the AWS access keys once, and your agent calls it.
Permission scoping
Greengrass puts the group id in the URL path (/greengrass/groups/{GroupId}/...), so a rule can pin your agent to one group: it can create versions, deployments, and role associations for that group and nothing else. You choose the operations it may call, so deleting a group or resetting deployments is not included unless you add it.
Credential isolation
Your AWS access keys for Greengrass are stored once, encrypted, by your own Jentic One instance and injected at execution time when the request is signed. They never enter the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'deploy a Greengrass group' or 'create a function definition', and Jentic returns the matching Greengrass operation with its input schema so the agent calls the right endpoint without browsing the reference docs.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using AWS Greengrass API through Jentic.
Why is there no official OpenAPI spec for AWS Greengrass?
AWS does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call AWS Greengrass via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.
What authentication does the AWS Greengrass API use?
The API uses AWS Signature Version 4 (HMAC) request signing with an AWS access key ID and secret access key. Through Jentic, AWS credentials are stored encrypted in the vault and the agent calls signed operations without seeing the raw keys.
Can I deploy a Greengrass group with the AWS Greengrass API?
Yes. Call CreateDeployment on /greengrass/groups/{GroupId}/deployments with DeploymentType set to NewDeployment and the GroupVersionId you want to deploy. Use GetDeploymentStatus on the returned deployment ID to monitor progress.
What are the rate limits for the AWS Greengrass API?
AWS applies per-account, per-region request quotas to Greengrass control-plane operations and these vary by call type. List operations have higher quotas than deployment operations. Check AWS Service Quotas for current limits in your region.
How do I add a Lambda function to a Greengrass group through Jentic?
Search Jentic for 'create greengrass function definition', execute CreateFunctionDefinition or CreateFunctionDefinitionVersion with the Lambda function ARN and runtime configuration, then create a new GroupVersion that references the function definition version, and call CreateDeployment to roll it out.
Does the API support both Greengrass v1 and v2?
This spec covers Greengrass v1, which manages groups, definitions, and deployments. AWS Greengrass v2 has a separate API (greengrassv2) with a different resource model based on components rather than function and subscription definitions.
Can I limit what my agent is allowed to do with the AWS Greengrass API?
Yes. Because Greengrass carries the group id in the URL path (/greengrass/groups/{GroupId}/...), a rule in your self-hosted Jentic One can pin the agent to a single group so it only creates group versions, deployments, and role associations for that group and nothing else. You decide which operations the agent may call, so destructive actions like deleting a group or resetting a deployment are excluded unless you explicitly add them. Your AWS access keys stay with your own instance and are injected only when a permitted, signed request runs, never reaching the agent's prompt or logs.
GET STARTED