canonical: https://jentic.com/apis/jentic.com/jentic-one-broker # Jentic Broker API The Broker API is a stateless data-plane proxy that forwards any HTTP request to an upstream API with the caller's stored credentials injected at the edge. The caller sends the upstream URL as the request path, and the Broker forwards the method, headers, and body unchanged, returns the upstream response synchronously, or falls back to a 202 with a polling link for long-running calls. Because secrets are injected at the proxy, they stay off the agent and the end-user device, outbound traffic has one auditable egress point, and upstream credentials rotate centrally without redeploying callers. ## For AI agents Proxy authenticated HTTP calls to any upstream API through a stateless broker that injects stored credentials at the edge, so agent code never holds the secret. Returns the upstream response or a polling link for long calls. ## Scope Does not store credentials, define permission rules, or register upstream APIs. Use for forwarding authenticated requests to upstream APIs only. ## Capabilities - Forward read requests to an upstream API with the caller's credentials injected at the proxy - Forward write requests to an upstream API without exposing the secret to agent code - Return the upstream response synchronously, or a 202 polling link for long-running calls - Route all outbound API traffic through one auditable egress point - Probe service health with a liveness check - Check saturation-aware readiness before sending traffic ## Use cases ### Agent calls third-party APIs without touching secrets An AI agent needs to call several third-party APIs but should never see their credentials. The Broker API injects each upstream credential at the proxy, so the agent sends only the upstream URL and payload while the secret stays on the server. Through Jentic the agent discovers the forwarding operation by intent and the credential is supplied at call time. Example prompt: Forward a POST payload to an upstream API through the broker and read back the upstream response without ever holding the upstream credential ### Single auditable egress point A team wants every outbound API call from its agents to pass through one place that can be logged and controlled. The Broker API gives outbound traffic a single choke-point: it forwards method, headers, and body unchanged, so existing upstream integrations keep working while every call is observable from one spot. Example prompt: Route an upstream GET through the broker so the call is captured at the central egress point and the response is returned unchanged ### Long-running upstream calls Some upstream operations take longer than a synchronous request can wait. The Broker API returns the upstream body with a 200 for fast calls and falls back to a 202 with a polling link for slow ones, so an agent can start the work and poll for the result instead of holding a connection open. Example prompt: Forward a slow upstream request, receive the 202 polling link, and poll until the upstream result is ready ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | `/{upstream_url}` | Execute a GET against an upstream API | | POST | `/{upstream_url}` | Execute a POST against an upstream API | | PUT | `/{upstream_url}` | Execute a PUT against an upstream API | | DELETE | `/{upstream_url}` | Execute a DELETE against an upstream API | | GET | `/health` | Service health probe | | GET | `/ready` | Saturation-aware readiness probe | ## Key resources - **Execution** — Forward GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS requests to an upstream API with credentials injected - **System** — Liveness health probe and saturation-aware readiness probe ## AI readiness 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. - **Score:** 85 / 100 - **Maturity:** AI-Ready - **Dimensions:** - Foundational Compliance: 100 / 100 - Developer Experience & Jentic Compatibility: 85 / 100 - AI-Readiness & Agent Experience: 90 / 100 - Agent Usability: 94 / 100 - Security: 60 / 100 - AI Discoverability: 82 / 100 - **View full report:** https://jentic.com/apis/jentic.com/jentic-one-broker/scorecard - **How the score is calculated:** https://docs.jentic.com/reference/api-readiness-framework/overview/ - **More about the dimensions:** https://docs.jentic.com/reference/api-readiness-framework/specification/#dimensional-model-overview ### Score it yourself Every API in the directory is allowlisted, so you can re-score it with no key required. - **Score your own API:** https://jentic.com/scorecard.md - **Scoring CLI agent skill:** https://github.com/jentic/jentic-api-scorecard/blob/main/skills/jentic-api-scorecard/SKILL.md ```sh npx @jentic/api-scorecard-cli score ``` ## Why Jentic - **Setup:** Wiring secure outbound calls by hand means building a proxy, holding upstream secrets in agent-reachable config, and handling retries and long-call polling yourself. Through Jentic you install once, import the Broker from the API Directory, store the bearer token once, and your agent proxies upstream calls through it. - **Permission scoping:** The Broker splits forwarding by HTTP method, so you choose which methods the agent may proxy: a rule can allow read forwarding and withhold delete forwarding. You decide the operation set, so destructive forwards are not included unless you add them. - **Credential handling:** Your Broker bearer token 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. - **Discovery method:** Agents search Jentic by intent such as 'call an upstream API with injected credentials', and Jentic returns the matching Broker operation with its input schema so the agent forwards the right request without reading the reference docs. ## Related APIs - **Jentic Control Plane API** — The control plane configures what the Broker may do, for whom, and with which credentials. - **Apideck Proxy** — Apideck Proxy forwards calls to connected SaaS APIs through a managed gateway. - **Akeyless** — Akeyless stores and serves secrets, where the Broker injects them into live outbound calls. ## FAQ ### What authentication does the Broker API use? The Broker API authenticates the caller with a bearer token, per its OpenAPI spec. The upstream credentials it injects into forwarded requests are held separately and never travel back to the agent. Through Jentic the bearer token is stored once and injected at call time, so it never enters the agent's prompt, logs, or context. ### Can I forward long-running calls through the Broker API? Yes. The Broker returns the upstream body with a 200 for fast calls and falls back to a 202 with a polling link for long-running ones, so your agent can start the work and poll for the result rather than hold a connection open. The method, headers, and body are forwarded unchanged in both cases. ### Can I limit what my agent is allowed to do with the Broker API? Yes. The forwarding operations are split by HTTP method, so a rule can allow read forwarding while withholding the delete-forwarding operation, letting the agent proxy safe calls and nothing destructive unless you add it. Every forwarded call passes the single egress point and is logged. ### Is there a Broker API MCP server? You don't need an MCP server to give your agent the Broker API. Jentic connects it directly from the API Directory: import it, store your bearer token once, and your agent proxies upstream calls through it. Operations are discovered on demand, so no extra tool definitions sit in the agent's context. ### How do I proxy an upstream API call through Jentic? Search Jentic for an intent such as 'call an upstream API with injected credentials' and it returns the matching forwarding operation with its input schema, so your agent sends the upstream URL and payload while the secret stays on the server. To run it on your own infrastructure, install Jentic One from its GitHub repo.