canonical: https://jentic.com/apis/amazonaws.com/aws-iot-jobs-data

# AWS IoT Jobs Data Plane

Jentic publishes the only available OpenAPI specification for AWS IoT Jobs Data Plane, keeping it validated and agent-ready. AWS IoT Jobs are remote operations - firmware updates, reboots, certificate rotations, configuration pushes - sent to one or more devices connected to AWS IoT. The Jobs Data Plane is the device-facing runtime API that lets devices fetch their pending job executions, mark them in progress, and report success or failure. It is a small 4-endpoint surface focused entirely on the device side of the job lifecycle.

## For AI agents

Allow devices and device-side automation to fetch pending IoT Jobs, start the next pending execution, and update job execution status as work progresses on the device.

## Scope

Does not handle job creation, fleet targeting, or rollout configuration - use for the device-side job execution lifecycle only.

## Capabilities

- List pending and in-progress job executions for a specific thing
- Start the next pending job execution on a thing and atomically mark it IN_PROGRESS
- Describe a specific job execution to fetch its job document and current status
- Update a job execution's status to IN_PROGRESS, SUCCEEDED, FAILED, REJECTED, or REMOVED
- Report progress with custom status details on a long-running job
- Acknowledge job documents and write back step-level outcomes from the device

## Use cases

### Over-the-Air Firmware Rollout

Devices pick up firmware update jobs by calling StartNextPendingJobExecution at boot or on a schedule. The job document points at a signed firmware artifact in S3; once the device installs it, UpdateJobExecution reports SUCCEEDED. Failed installs report FAILED with statusDetails so the fleet operator can roll back or retry.

Example prompt: Call PUT /things/thing-42/jobs/$next with statusDetails={} to claim the next pending job, install the artifact, then call POST /things/thing-42/jobs/{jobId} with status=SUCCEEDED

### Certificate Rotation Workflow

Use IoT Jobs to coordinate scheduled certificate rotation across a fleet. The device fetches the rotation job, generates a new key pair, requests a fresh certificate via the control plane, and reports back via UpdateJobExecution. Status details allow it to pass back the new certificate ID for audit and reconciliation.

Example prompt: Call DescribeJobExecution to read the rotation job document, then UpdateJobExecution with status=SUCCEEDED and statusDetails containing the new certificate ID once rotation completes

### Configuration Push with Progress Reporting

For multi-step configuration jobs, devices report incremental progress by repeatedly calling UpdateJobExecution with status=IN_PROGRESS and a fresh statusDetails map. The fleet operator sees step-level state in the IoT Jobs console without the device leaking telemetry through MQTT topics.

Example prompt: Call POST /things/thing-42/jobs/{jobId} with status=IN_PROGRESS and statusDetails={"step":"download_complete","percent":"50"}

### AI Agent Edge Job Operations

Through Jentic, an AI agent embedded in or alongside a device runtime can drive the job lifecycle on the device side - claiming the next pending job, executing the work, and reporting status. Jentic exposes the 4 Jobs Data Plane operations as discoverable tools so the agent picks the right call from intent.

Example prompt: Search Jentic for 'start next aws iot job', load the StartNextPendingJobExecution schema, and execute it for the relevant thingName

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /things/{thingName}/jobs | GetPendingJobExecutions - list pending and in-progress executions for a thing |
| PUT | /things/{thingName}/jobs/$next | StartNextPendingJobExecution - claim the next pending job and mark it IN_PROGRESS |
| GET | /things/{thingName}/jobs/{jobId} | DescribeJobExecution - fetch a specific job execution and its job document |
| POST | /things/{thingName}/jobs/{jobId} | UpdateJobExecution - update status and statusDetails on a job execution |

## Key resources

- **JobExecution** — Per-thing instance of a job, with status, document, and execution number
- **Job** — Cross-fleet job definition referenced by each JobExecution

## Why Jentic

- **Setup:** Wiring the AWS IoT Jobs Data Plane by hand means implementing AWS Signature v4 request signing, resolving your account's data.jobs.iot endpoint, and mapping the device-side job execution calls to their REST paths yourself. Through Jentic you install once, import AWS IoT Jobs Data Plane from the API Directory, store the AWS credentials once, and your agent calls it.
- **Permission scoping:** This API puts the thing name and job id in the URL path (/things/{thingName}/jobs/{jobId}), so a rule can pin your agent to one thing's job executions. You choose the operations it may call, so a state-changing one like UpdateJobExecution is not included unless you add it.
- **Credential handling:** Your AWS credentials 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.
- **Discovery method:** Agents search Jentic by intent such as 'start the next pending AWS IoT job' or 'update a job execution status', and Jentic returns the matching AWS IoT Jobs Data Plane operation with its input schema so the agent calls the right endpoint without browsing the AWS service reference.

## Related APIs

- **AWS IoT Data Plane** — Companion data-plane API for MQTT publish and device shadow operations
- **AWS Greengrass** — Edge runtime that can host job-handling logic close to the device
- **AWS IoT Events** — Detector models that can react when job executions enter specific states

## FAQ

### Why is there no official OpenAPI spec for AWS IoT Jobs Data Plane?

AWS does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call AWS IoT Jobs Data Plane 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 IoT Jobs Data Plane API use?

The API uses AWS Signature Version 4 (HMAC) request signing. Devices typically authenticate via certificate-based MQTT, but the HTTPS endpoint covered by this spec uses SigV4 with an AWS access key. Through Jentic, requests are signed server-side.

### Can I claim the next pending job for a thing through the API?

Yes. Call PUT /things/{thingName}/jobs/$next with an optional statusDetails and stepTimeoutInMinutes. The response returns the job document and execution metadata, and the execution is atomically transitioned to IN_PROGRESS so other clients cannot claim the same job.

### What are the rate limits for the AWS IoT Jobs Data Plane API?

AWS applies per-account, per-region request quotas to Jobs Data Plane operations and these vary by call. UpdateJobExecution has lower throughput than GetPendingJobExecutions. Check AWS Service Quotas for current limits.

### How do I report a job as completed through Jentic?

Search Jentic for 'update aws iot job execution', load the UpdateJobExecution schema, and execute with thingName, jobId, and status=SUCCEEDED. Optionally include statusDetails to record outcome metadata for audit.

### What is the difference between this API and the IoT Jobs control plane?

This data-plane API is what devices and device-side agents use at runtime to fetch and report on jobs. The control plane (part of the IoT Core API) is what fleet operators use to create, target, and cancel jobs. The two surfaces share the same JobExecution resource.

### Can I limit what my agent is allowed to do with the AWS IoT Jobs Data Plane API?

Yes. Because you run Jentic One yourself, your own rules decide which of the four operations the agent may call, so a read-only agent can be given GetPendingJobExecutions and DescribeJobExecution while a state-changing call like StartNextPendingJobExecution or UpdateJobExecution is left out unless you add it. Since the thing name and job id sit in the URL path, such as /things/{thingName}/jobs/{jobId}, a rule can also pin the agent to one thing's job executions. You control both the operations and the stored AWS credentials the agent is allowed to use.