Operations
An operation is one call that an agent can make to your API: a REST route, a GraphQL query or mutation, or a gRPC method. The analysis finds the operations, and the Operations tab of the API lists them grouped by resource.
How it works
Each operation has a key, such as crm.deals.create. An agent never sees a URL. It calls the key with an input object, and the gateway builds the request from the operation's endpoint and the connection it routes to.
For REST, the input is one flat object. The gateway takes the path parameters from it, then sends the rest as the query string for GET and DELETE and as a JSON body for the other methods. The same operation runs against any connection of the API.
What you set on an operation here applies in every gateway that serves the API. A gateway only chooses which operations it exposes. See Choose which operations are exposed.
What an operation carries
| Field | What it is | Editable |
|---|---|---|
| Key | namespace.resource.action. What agents and gateways refer to. |
No |
| Endpoint | The method and path for REST, the field for GraphQL, the service and method for gRPC. | No |
| Summary | One line. The tool description that agents read. | Yes |
| Description | When to use the operation, what it returns, caveats. | Yes |
| Request schema | A JSON Schema for the input. | Yes |
| Response schema | A JSON Schema for the result. | Yes |
| Kind | read or write. |
Yes |
| Requires confirmation | Whether a person confirms each call. | Yes |
| Identifying fields | For writes, the request fields that identify a repeated call. See Repeated writes. | Yes |
To see these fields, select the operation's row. To change them, see Review and test an operation.
Kind
The analysis marks each operation as a read or a write. A gateway API key or gateway user that is read-only can call read operations only, so the kind decides what such a credential reaches. Review the kind of each operation and change it where your API differs from the convention. A POST route that only searches is a read, for example.
Requires confirmation
An operation that requires confirmation does not run until a person confirms the call. The analysis turns the flag on for the writes it considers destructive, and you can change it for any operation. The flag is set once on the API. What happens when an agent calls such an operation is decided for each key or user on the gateway. See Confirmation and Mark an operation as requiring confirmation.
Hidden and deprecated operations
Hidden (auth endpoints), under the table, lists the login and token routes the analysis found. Faustine uses them to sign in to your API. They are never exposed to agents.
An operation with the Deprecated badge was marked as deprecated in the code or the spec. New gateways do not expose it by default.
Composite operations
A recipe that you accept becomes an operation of the API. It appears in the same table and agents call it the same way. Its kind and its confirmation flag come from the steps it runs, so they are not editable. See Recipes.
Edits and versions
Edits to an operation are saved to the draft. Gateways serve published versions, so an edit reaches agents after you select Publish. A dot next to an operation's key marks it as edited. Reset to analysis in the operation's menu drops your edits and restores what the analysis wrote.
To see the operations of a published version, select the version in the API's header. The table is read-only in that view.
Next steps
- Review and test an operation: open an operation, edit it and call it against a connection.
- Mark an operation as requiring confirmation: decide which writes need a person.
- Recipes: combine several operations into one.
- Choose which operations are exposed: hide operations in a gateway.
Last updated November 13, 2026