Launching today
Jentic Mini
Give your AI agents safe access to 10,000+ APIs
361 followers
Give your AI agents safe access to 10,000+ APIs
361 followers
Building agents that call real APIs is painful. You end up hardcoding auth, juggling secrets in prompts, and writing glue code for every service. Jentic Mini is a self-hosted, open-source API execution layer that sits between your agent and the outside world. Your agent says what it wants to do. Jentic Mini finds the right API from a catalog of 10,000+, injects credentials at runtime, and brokers the request. Secrets never touch the agent.
Jentic Mini
Hey Product Hunt 👋
A message from Jentic’s CEO:
I'm Sean, co-founder of Jentic. We've spent the last 18 months working on a problem that anyone building AI agents has hit: how do you let an agent call real APIs without leaking credentials or losing control?
Here's the typical pattern today: you hardcode API keys into prompts, write bespoke wrapper functions for every service, and hope nothing gets logged, cached, or hallucinated back. It works for demos. It breaks in production.
What Jentic Mini actually does
It's an API execution layer — a FastAPI server you self-host in Docker — that sits between your agent and every API it needs to call. The architecture is straightforward:
Search: Your agent queries a BM25 full-text index across 10,000+ API specs and 380 Arazzo workflow sources from our public catalog. It finds the right operation without you writing a single wrapper.
Execute: Jentic Mini brokers the request. Credentials are stored in a Fernet-encrypted local vault and injected at runtime. The agent never sees them. They're never returned via the API.
Toolkits: Each agent gets a scoped toolkit key (tk_xxx) with its own credential bundle and access policy. One key per agent, individually revocable. If something goes wrong, you kill the key. Done.
Observe: Full execution traces and audit logs. You can see exactly what your agent called, when, and what came back.
Why we built it
We're already running a hosted Jentic platform (with semantic search, Lambda-based brokering, SOC 2-grade security) and we're a verified connector in Claude. But we kept hearing the same thing from developers: "I want to run this myself." So we built Mini, same API surface, self-hosted, Apache 2.0 licensed.
Getting started is one command:
Add your API credentials through the UI at localhost:8900, and specs are auto-imported from the public catalog. Your agent authenticates with a toolkit key via the X-Jentic-API-Key header and starts searching and executing immediately.
What's next
This is early access. There will be rough edges. We're sharing it now because we want the community building with agents (OpenClaw, NemoClaw, LangChain, CrewAI, whatever your stack is) to test it, break it, and tell us what's missing.
Would love to hear what APIs and workflows you'd want to connect first.
Jentic Mini
I've had the advantage of using Jentic Mini since version 0, and it has changed how I'm using openclaw (or should I say how my openclaw uses me?). I'm now willing to let it hook up to APIs and SaaS that would have been just too risky to give access to before. Example: thanks to jentic mini my claw can now compose drafts in gmail but does not have permission to send them. More than that, it makes connecting to lots of things and managing permissions super easy - just ask the agent to orchestrate you through the process of hooking up to anything while keeping its access minimal. No fumbling around in badly designed settings menus. And particularly proud of the killswitch - that one helps us all sleep better at night.
A few questions: Multi-agent orchestration — If multiple agents share a single Mini instance, how does credential isolation work across toolkit keys in practice? Can one agent's key ever accidentally resolve another's credentials?
Jentic Mini
@larkloss You can have multiple toolkits to isolate different sets of APIs/credentials from each other. You call how you want to arrange it, but you can have all agents go through one toolkit, or have a different toolkit per agent (with different permissions policies) or anything in between.
Most people solving the "agent + credentials" problem hardcode keys, inject them into prompts, or hope their env/config stays private. That's not agentic power, that's exposure waiting to happen.
Jentic Mini sits between the agent and every API it touches. Credentials are injected at runtime, never in prompts, never in logs. The agent gets a scoped toolkit key. The real secrets never leave your instance.
What do I really love? The agent can formalise a workflow as an Arazzo Spec document, register it back into Jentic Mini, and retrieve it just-in-time (via our search facility). The workflow becomes a versioned asset, not a repeated guess. No more burning context or tokens on something already solved. And if the underlying API description needs improving, the agent can do that too. Using the Overlay spec to contribute it back in better shape.
Jentic Mini intimately understands OpenAPI, Arazzo, and Overlay. Not as an afterthought but as the foundation.
Credentials shouldn't be an agent's problem. In Jentic Mini, the agent guides you, it auto-requests permissions for the toolkits it needs, so you grant only what the task actually requires and nothing more.
Jentic Mini (and Jentic as the enterprise version of it) address a number of challenges in the rapidly evolving space of AI agents. Agents become increasingly powerful and can solve increasingly complex problems. But finding the right tools to help them solving these problems can be tricky. Jentic helps by providing a sophisticated search facility, that helps minimize context use and allows agents to find the tools that they need.
Jentic also addresses the issue of access control: Agents should never get user credentials. Instead, they should get their own specific credentials which are then mapped to capability credentials in a separate place. This place is Jentic. This allows to fine-tune the access rights given to agents, and it also provides a centralized view of all agents and their access right. That way, agents can never share access credentials (because they never get them), and if something does go wrong, it is easy to tweak the access rights of specific agents or to completely revoke their access to resources and capabilities.
Try out Jentic Mini (or Jentic if you are looking for a SaaS solution) and be more confident when designing and evolving your agents!
That lazy-load approach makes sense - way better than upfront credential sprawl. Interested to try it with a few of the messier enterprise APIs.
@mykola_kondratiuk, you should definitely feel the difference. Dynamic tool selection outperforms "all tools all the time" very easily, to be frank. We put a lot of effort into what I like to call the "tool tool", and it helps a lot with finding the best tools just when your agents need them.
Thanks to everyone taking a look at Jentic Mini today.
What feels important to us about this launch is where it sits in the stack. General-purpose agents are getting much more capable, but the minute they need live access to real systems, credentials, permissions and control become a much bigger part of the story, which is the gap we wanted to address with Jentic Mini.
Very proud of the team for getting this out into the world. Keen to hear what people are building, which APIs you’d want to connect first, and where the rough edges still are. Let us know what you think!
10,000+ APIs is wild - how do you handle auth across all of them? Storing credentials per agent sounds like a nightmare, and rate limit management across a fleet of agents hitting the same API is a real problem I've run into.
@mykola_kondratiuk Both are challenges, and here's where we are.
Firstly, we don't store a credential per API up front. You only add credentials for the APIs you actually use. The broker handles injection regardless of auth pattern: bearer token, API key header, basic auth, OAuth. And if an API's OpenAPI document has wrong or missing security schemes (more common than it should be), agents can register a correction via our security scheme overlay flywheel (using the Overlay Spec from OAI). Those overlays get auto-confirmed on the first successful 2xx and are reused by all agents in that toolkit going forward.
Longer term, the right fix is better specs at source. We give providers the tools to get there: our AI-readiness scorecard scores APIs across six dimensions including security scheme completeness, and the underlying open source framework is available for anyone to run themselves. Validity and usability are not the same thing. The flywheel is a workaround for today. Better specs are the answer for tomorrow.
Jentic Mini doesn't do rate limit management yet on a per API basis. It's on the roadmap. Every call routes through the broker as a single chokepoint, so you have full trace visibility into who's hitting what. What we do prevent is the problem you've likely hit before: N agents with N hardcoded keys all hammering the same API independently. Credentials are centralised. You can bind the same credential to multiple toolkits, so all agents route through one provider API token if you want to manage quota centrally. Rate limiting enforcement and per-toolkit quota controls are next. If that's a blocker for your use case, keen to hear the specifics.
Makes sense - context bloat from including all tools is a real issue when you're chaining calls. Selective loading keeps the model focused.