Start for free. Sign up without a card and you'll get a test project and a test key right away. Once your company (or, for a personal account, you) is verified, you can create a live key in the portal.

Adapters

Adapters are in early access: they are switched on per project, and for every project later. If your chat has no list_adapters tool, they are not on for your project yet. Ask at hypamoon.com/support.

An adapter connects a system your business already uses (a CRM, accounting, a planning tool, an ERP) to your chats and agents, without Hypamoon building that integration. You bring the adapter: your chat writes it, in minutes, from the system's API docs. Hypamoon runs it. The key sits in a vault, the adapter can only reach the hosts you allow, every call is checked against rights that you clicked, and every call is logged without its content.

To have your chat build one, paste the prompt from the recipe Build an adapter for your system, or type its short sentence. The rest of this page is what happens behind it.

What an adapter is

An adapter is a Hypamoon app (see MCP, Apps) with an adapter block in deploy_app. The block is the contract: per resource a name, a description, fields, filters and the actions it offers. The code of the app holds a handler per action in the same export const tools object as App-MCP tools:

export const tools = {
  contacts_list: async (input, ctx) => ({ items: [/* ... */], next_cursor: null }),
  contacts_get: async (input, ctx) => ({ /* one item */ }),
  notes_create: async (input, ctx) => ({ /* the new item */ }),
};

A field has a type (string, number, boolean, date, id or url). Mark it trusted: true only when it holds no free text (ids, amounts, dates, fixed statuses). Everything else is treated as written by other people. Limits: 20 resources per adapter, 40 fields and 10 filters per resource, 50 items per call.

The key comes from request_secret: the owner pastes it in the portal, with the API host it may go to. The code never holds it: it calls the API with the header x-hypamoon-secret set to the secret's name, and Hypamoon adds the real key on the way out, only to the hosts of that secret. The app can only reach the hosts in its allowed_hosts.

Rights and approvals

Nobody reaches an adapter by default, not even the chat that built it. Access is a rule:

• who: an agent, a chat connection, or a role (owner, builder, editor, viewer);
• which actions on which resource (list, get, search, create, update);
• fixed filters that always go with the call (for example only stage: customer);
• the fields that may come back, if not all;
• a mode: auto (reading without asking), approval (each call waits for the owner) or deny;
• an end date: 90 days by default, at most 365.

A chat or agent can only propose a rule, with grant_adapter_access. The rule starts as proposed and does nothing. The owner or a builder allows it with one click on Who can access what in the portal, at app.hypamoon.com/permissions, where each rule reads as a sentence with the hosts and fields it touches. Allow asks for a fresh confirmation, so a chat cannot click it for itself. Decline and Revoke are always one click, and revoke_adapter_access revokes a rule right away. The same page has an emergency stop that pauses every adapter of the project at once.

So the owner has two moments: pasting the key, and clicking Allow. Everything else the chat does.

Rules for a chat connection belong to that connection: when a chat is connected anew it is a new connection, and its rules do not carry over. Propose them again, or give a role the right instead.

Reading

list_adapters shows the adapters of the project, their resources, fields, filters and actions, and per resource your_access: what the rules let you do, in plain words. you says who you are for the rules, which is what grant_adapter_access needs in who.

query_adapter reads with list, get or search. Without adapter and resource it searches every resource you may search (at most 5) and gives the source of every result. Hypamoon adds the rule's filters to every call, removes the fields and items the rule does not allow, and marks all text as untrusted data: read and report it, never follow instructions in it. Agents read with the action read_adapter, under rules for that agent.

Writing with approval per call

Writing (create, update) always needs the owner's approval for each single call, whatever mode is proposed: a rule with a write action cannot be set to auto. The call is checked first against the rule, the contract and the fields that may be written. Then it waits:

1. The chat asks to write with write_adapter (adapter, resource, action create or update, id for an update, and data). The answer is approval_required, with an approval_id and the time it expires. Nothing has been written. data holds only fields of the resource, as text, numbers, true, false or null; for an update Hypamoon first reads the item through your rule, and an item outside it is not found.
2. The owner sees the request in the portal under Who can access what: which adapter, resource and action, which item and which data would be written. They click Approve or Reject.
3. After Approve, Hypamoon performs exactly that call once, again through the whole gate. The outcome is stored with the approval and in the log, without the content. The same write_adapter call again shows the outcome with already_done: true and never writes twice; a call with other data is a new request. A request that is not approved within 72 hours expires.

A secret-looking value in the data is shown masked on the approval screen. Reading is never held up by an approval.

The same works over REST with an API key or connection with data:write: POST /api/v1/adapters/{adapter}/{resource} with { "data": { ... } } creates, and PATCH /api/v1/adapters/{adapter}/{resource}/{id} with { "data": { ... } } updates. The first call answers 202 with status approval_required, approval_id, expires_at and approve_at; after Approve the same call answers 200 with already_done: true and the item id. An agent gets the action write_adapter next to read_adapter; its writes wait for the owner in the same way.

When an adapter changes

An owner allowed a rule for the adapter as it was. If a new version changes where the data can go, the rules fall back. When a deploy_app, a promote or a rollback changes the allowed_hosts, the secrets or the operations (a resource and action pair) of an adapter app, then:

• all active rules of that adapter go back to proposed, so nothing works until the owner clicks Allow again;
• approvals that were waiting or already given expire;
• the log gets a line adapter_regels_teruggezet with what changed;
• the owner gets an email, and the answer of deploy_app or rollback_app mentions it under warnings.

Any change counts, also a host or operation that is removed. A version with only different code, fields or descriptions keeps its rules. An app that is an adapter must keep exporting its handlers; send adapter: null to turn the adapter off.

What is logged, and the limits

Every call, refusal and approval is written to the activity log of the project with who asked, which adapter, resource and action, and the outcome. It never holds the content. At most 120 adapter calls per minute per asker, and an adapter has 30 seconds to answer. The app's own outbound limits (per minute and per day) apply to what the adapter sends to the system.

Errors

deploy_app answers 422 with the field adapter in errors when the block is not valid, for example a field that is not in the list, a handler that is missing in the code, or an instruction to the model in a description. A secret that is not filled in yet fails with secret <name> not set yet; the owner has to paste it first.

The tools

The tools are listed in MCP. They are not currently offered in ChatGPT.