For Agents
Run prompt-based tasks on OpenHelm Cloud and read back schema-shaped results with confidence and screenshot evidence, and send and triage email from agent inboxes with human approval holds.
Use for: Run this prompt and return the answer as JSON matching my schema, I want to check a website and get a screenshot as evidence, Get the result and confidence for run 7f3c, Pause all scheduled OpenHelm runs right now
Not supported: Does not train models, host your own model weights, or provide raw chat completion. Use for running OpenHelm task jobs and its agent email inboxes only.
The OpenHelm Public API runs prompt-driven tasks on OpenHelm Cloud and returns structured, schema-shaped results asynchronously. You author jobs, reusable task templates whose prompts carry {{placeholders}}, or send an inline prompt, then poll the run or receive a callback with a result, a high, medium, or low confidence level, evidence such as a screenshot URL and matched text, and token usage with cost_usd. Task failures come back as a structured failure_reason such as captcha, auth_required, or timeout rather than an HTTP error. The same API also gives an organization email inboxes with sending, threads, full-text search, human approval holds, sending domains, and suppressions.
Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the OpenHelm Public API, 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%2Fopenhelm.ai%2Fopenhelm" | 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%2Fopenhelm.ai%2Fopenhelm" | 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.
What an agent can do with OpenHelm Public API.
Run an inline prompt with {{placeholder}} inputs and an output_schema, then poll GET /runs/{id} or receive a callback for the result
Author reusable jobs with a prompt, model, and input and output schemas, and run them with parameters and an idempotency_key
Read each run's confidence level, screenshot and matched-text evidence, failure_reason, and token usage with cost_usd
Pause or resume every scheduled run in the account, and cancel or force an individual run
Create email inboxes with an autonomy mode of auto, approve_first, or notify, and send single messages or batches of up to 100
Release or reject outbound messages held for human approval
Search an organization's mail by full text and list threads, messages, and attachments
Patterns agents use OpenHelm Public API for, with concrete tasks.
★ Delegating structured tasks from your own agent
An AI agent working through Jentic hands a task to OpenHelm with POST /runs, sending a prompt, inputs for its {{placeholders}}, and an output_schema. The call returns 202 with a task_id, and GET /runs/{id} later returns a status of succeeded, failed, or needs_you along with the schema-shaped result, a confidence level, and evidence. Your own Jentic One instance injects the oh_live_ key at call time.
POST /runs with prompt 'Find the current price of {{product}} on {{site}}', inputs for product and site, and an output_schema with a price field, then poll GET /runs/{id} until status is succeeded and return result and confidence
Reusable monitoring jobs
For checks that repeat, POST /jobs stores a named template with a project_id, a prompt, and schemas, and PATCH /jobs/{id} sets a schedule. Runs fired with POST /jobs/{id}/runs carry their own inputs and an idempotency_key, and each result includes evidence with a screenshot_url and matched_text so a person can confirm what was checked. POST /scheduler/pause stops every scheduled firing at once if something goes wrong.
Create a job with POST /jobs for project_id p_123 with a prompt and output_schema, then run it with POST /jobs/{id}/runs passing inputs and an idempotency_key
Agent email with a human approval step
An inbox created with POST /inboxes and autonomy set to approve_first holds outbound agent mail instead of delivering it. GET /approvals lists the held messages, and POST /approvals/{message_id}/approve releases one, optionally with edits, while POST /approvals/{message_id}/reject discards it with a reason. Messages report sent, pending_approval, or scheduled, and suppressed recipients are listed on the response.
Send a reply with POST /inboxes/{id}/messages on an approve_first inbox, then list GET /approvals and approve the held message with POST /approvals/{message_id}/approve
Triage and search across inboxes
Support or sales mail arriving at OpenHelm inboxes can be searched with GET /search by query and inbox_id, and grouped with GET /threads. GET /attachments returns the files on a message or thread, and GET /attachments/{id} gives a signed download URL, so an agent can find the right conversation and pull its documents.
Call GET /search with query 'invoice' and an inbox_id, open the top result with GET /threads/{id}, and fetch its attachments with GET /attachments
68 endpoints — the openhelm public api runs prompt-driven tasks on openhelm cloud and returns structured, schema-shaped results asynchronously.
METHOD
PATH
DESCRIPTION
/runs
Run an inline prompt asynchronously
/runs/{id}
Poll a task result
/jobs
Create a task template
/jobs/{id}/runs
Run a job with parameters
/scheduler/pause
Pause all scheduled runs
/inboxes
Create an inbox
/inboxes/{id}/messages
Send from an inbox
/approvals/{message_id}/approve
Release a held message
/runs
Run an inline prompt asynchronously
/runs/{id}
Poll a task result
/jobs
Create a task template
/jobs/{id}/runs
Run a job with parameters
/scheduler/pause
Pause all scheduled runs
/inboxes
Create an inbox
/inboxes/{id}/messages
Send from an inbox
/approvals/{message_id}/approve
Release a held message
This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.
Base layer of spec validity and structural soundness.
Aggregated quality score from linter diagnostics, weighted by severity.
Percentage of `$ref` references that resolve successfully.
Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).
Structural correctness score based on schema issues using logarithmic dampening.
Clarity, completeness, and ingestion readiness for developers and tooling.
How richly the API is illustrated with examples.
Percentage of examples that conform to their schemas.
Percentage of operations with complete response definitions (success, client error, server error).
Health of API ingestion, bundling, and resolution within Jentic pipelines.
Semantic breadth, depth, and agent comprehension for AI systems.
Coverage of descriptions across API elements.
Coverage of RFC 9457 Problem Details for error responses.
Coverage, uniqueness, and casing consistency of operationIds for AI inference.
Coverage of summaries across operations/tags/info.
Functional utility, complexity comfort, and AI orchestration readiness.
Agent comfort level based on API operational and structural complexity.
Trust, risk posture, and security compliance.
Average quality of security schemes based on authentication method strength (weakest link for OAuth2).
Findability, semantic richness, and reasoning readiness.
Clarity and depth of descriptions across API elements.
Score it yourself
Every API in the directory is allowlisted, so you can re-score it with no key required.
npx @jentic/api-scorecard-cli score <openapi-url>What agents get from Jentic-routed access to this vendor.
Setup
Wiring OpenHelm by hand means minting an oh_live_ key, sending it as a bearer token, polling asynchronous runs or hosting a callback, and handling 202 batch responses with per-item outcomes. Through Jentic you install once, import OpenHelm from the API Directory, store the key once, and your agent calls it.
Permission scoping
OpenHelm puts job, run, and inbox ids in the URL path (/jobs/{id}/runs, /inboxes/{id}/messages), so a rule can pin your agent to one job or one inbox and the operations you pick. You choose the operations it may call, so account-wide ones like POST /scheduler/pause or DELETE /connections/{id} are not included unless you add them.
Credential isolation
Your OpenHelm key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'run a task with structured output' or 'approve a held email', and Jentic returns the matching OpenHelm operation with its input schema, including prompt, inputs, and output_schema, so the agent calls it directly.
Alternatives and complements available in the Jentic catalogue.
Specific to using OpenHelm Public API through Jentic.
What authentication does the OpenHelm Public API use?
The OpenHelm Public API uses a bearer token per its OpenAPI spec: send Authorization: Bearer with a key starting oh_live_, minted under Settings, API & Webhooks in OpenHelm. The spec applies it to every operation except GET /plans, which lists plans publicly with no key. Through Jentic the key is stored by your own instance and attached to each call.
How do I get a run's result from the OpenHelm Public API?
POST /runs and POST /jobs/{id}/runs return 202 with a task_id and poll_url. Poll GET /runs/{id}, or pass a callback_url to receive a run.completed or run.failed event. The result object follows your output_schema and comes with a confidence of high, medium, or low, evidence with a screenshot_url valid for 7 days, and usage including cost_usd. A failed task still returns 200 with a failure_reason such as captcha, site_down, or not_found.
What are the rate limits for the OpenHelm Public API?
The OpenAPI spec does not state numeric request limits. Run endpoints document a 429 for too many concurrent runs and a 402 for subscription, trial, or quota gates, and inboxes carry a daily_trigger_cap setting; batch sends stop at a daily-cap failure. See https://openhelm.ai for plan limits.
Is there an OpenHelm MCP server?
You don't need an MCP server to give your agent OpenHelm. Jentic connects it directly from the API Directory: import it, store your credential once, and your agent calls the run, job, and inbox operations it needs on demand without loading another server's tool definitions into its context.
How do I run an OpenHelm task through Jentic?
Search Jentic for 'run a task and return structured output', load the POST /runs operation, and execute it with a prompt, inputs, and an output_schema. Then load GET /runs/{id} and poll it with the returned task_id until the status is succeeded or failed. To run it on your own infrastructure, install Jentic One from its GitHub repo.
Can I limit what my agent is allowed to do with the OpenHelm Public API?
Yes. For a monitoring assistant, write a rule that allows POST /jobs/{id}/runs for one job id and GET /runs/{id}, and the agent can trigger that job and read its results while job deletion, scheduler pause, connection changes, and email sending stay out of reach. Every call it makes is logged.
GET STARTED