Docs / Endpoints: webhooks, APIs, MCP, apps
One endpoint, four interpretations
An endpoint is a path on one of your connections, reached under https://hooks.a9script.lengauer.biz. What a caller gets there depends on one field, the endpoint’s interpretation: webhook, api, mcp, app. The path, the credential, the allowed networks, the sender profile, the delivery-id check and the on/off switch are the same for all four — the interpretation decides the protocol and nothing else.
Webhook
The default, and what an endpoint is when the field is absent. A sender
POSTs, is acknowledged at once, and your scripts run afterwards. Several
scripts can listen on one webhook endpoint, each with its own when filter,
so each receives only the events it asked for; an event no script takes is
counted and logged. A sender that ships a delivery id has a repeated delivery
dropped at the endpoint.
Use it for the systems that push to you: an issue tracker, a shop, a payment provider, a chat tool. Your first automation builds one end to end.
API
Another application calls and waits for the answer. Exactly one script
answers a bare call with respond(); the caller is told 404 when no script
listens, 500 when the script failed and 504 when it did not answer in time.
An endpoint set to API can also carry operations: a table of names, each
pointing at a configured function or a script, reached as one more path
segment. An operation’s target runs as an ordinary run, under the same
budgets and the same fairness as everything else.
Answering a caller is the page that walks it.
An API endpoint can require a signed-in caller — one of your own app users — and each operation says who may reach it: everyone, signed-in callers, or a list of roles. An unknown operation and one the caller may not reach answer alike, so nothing can be probed.
MCP
The same operations table, spoken as the Model Context Protocol: an assistant lists the operations as tools, each with an input schema generated from the parameter structure the target declares, and calls them. The protocol versions the endpoint answers are 2025-11-25, 2025-06-18, 2025-03-26, 2024-11-05. The endpoint is stateless — a session is accepted but not required — and a call that ran and failed is a tool result with an error, while a broken exchange is a protocol error. An endpoint an assistant can call is the page that walks it.
A tool call answers within the synchronous budget. A run that would have to wait — a throttle, a long pause — is stopped and the client is told; the far end was asked once. Turning an API into an MCP server walks through it.
App
A folder of files served at your app’s address, signing your users in at your environment. Nothing runs and nothing triggers on it; the endpoint carries no credential of its own. Hosting a small app covers it, and In the beta says whether the beta has an apps host.
What the interpretation does not change
- The path:
/hooks/<tenant>/<environment>/<path>accepts and does not wait;/api/<tenant>/<environment>/<path>waits for the answer. - The credential a caller presents, and the networks it may come from.
- The switch: a switched-off endpoint acknowledges a webhook sender (so it does not retry for days), tells a synchronous caller, and refuses a replay.
- The self-description every activated endpoint answers — see Describing your endpoint.
Where the mistake is caught
A trigger that does not fit the interpretation is refused where you add it, and the whole list is judged again on Activate: several filtered listeners on an API endpoint are legitimate, an unfiltered one beside any other is not. A folder applied from the command line is judged the same way, over the state the folder leaves, so file order cannot make a legitimate move fail.