Skip to main content

Saved searches

Save a reusable query inside one client space, then run it in any of the five search views. Saving consumes no credits and does not store a copy of the results. A new run uses the current permissions, subscription and credit envelope.

Open Organizations, select your workspace, then choose the asset scope or client space that will own the saved search. Availability and write access depend on the workspace status and your role.

  1. Select the organization and client space before searching.
  2. Choose Save search in the workspace bar, enter a name and check the dataset and visibility.
  3. Open the client space to find, edit or run saved searches.
  4. For Hosts, DNS, Certificates or WHOIS, choose Create watch to prepare a monitoring rule. Review the estimate, budget and frequency before saving. Automatic collection is off by default.

The saved recipe contains the raw query and selected search engine. Display mode, current page and temporary page filters are not saved. Search syntax is validated when executed or when requesting the watch estimate. A saved query is not a credit authorization.

Visibility and editing​

  • Staff recipes are internal by default. Assigned staff and service keys with search:read for this client can read them.
  • Shared with this client makes the query visible to everyone assigned to the same client space.
  • External users can create shared recipes and edit or delete their own recipes. They cannot edit a recipe created by another user or read an internal recipe.
  • Staff assigned to the client can manage its recipes. Knowing a recipe ID grants no access across clients or organizations.
  • Concurrent edits require reloading the latest version; the UI keeps an unsaved draft after a conflict. Archived or expired workspaces preserve read access and reject mutations.

There are at most 200 saved queries per client and 1,000 per organization. Deleting a recipe keeps existing search results and watches. Editing a recipe does not silently change an existing watch or its baseline.

API and MCP​

Session routes use /api/v2/organizations/{organizationId}/clients/{clientId}:

  • GET /saved-queries — visible recipes, including can_manage.
  • POST /saved-queries — { "name": "Services", "engine": "hosts", "query": "host:example.com", "visibility": "internal" }.
  • GET /saved-queries/{queryId} — one visible recipe.
  • PATCH /saved-queries/{queryId} — the same input with If-Match: "3" for version 3.
  • DELETE /saved-queries/{queryId} — also requires If-Match.

Allowed engines are unified, hosts, dns, vhosts and whois. Queries are limited to 4,096 characters and names to 120. Service keys expose only the two GET routes under the service API prefix, requiring search:read. MCP organization_records accepts resource saved-queries with an optional recipe UUID. Creating, editing and deleting recipes require a named user session.

Support diagnostics expose counts per client and mutation audit identifiers, without recipe names or query text.

Last updated on