> ## Documentation Index > Fetch the complete documentation index at: https://developer.lofty.com/llms.txt > Use this file to discover all available pages before exploring further. # Resume saved search alerts > Switches alerts back on for the given saved searches, each at the cadence it ran at before it was paused (frequencyBeforePause on the read endpoint). Searches already on are reported as ALREADY_ACTIVE and keep their cadence. A search whose earlier cadence is unknown stays paused and is reported as PRIOR_FREQUENCY_UNKNOWN with a message; set alertFrequency through the update endpoint for it instead. The other searches resume as usual. A result of NOT_CHANGED means the search could not be switched on and should be checked in the CRM. ## OpenAPI ````yaml openapi/openapi.json POST /v1.0/leads/{leadId}/savedSearches/resume openapi: 3.0.1 info: title: Lofty Service Open APIs description: Lofty service API description version: '1.0' servers: - url: https://api.lofty.com security: [] tags: - name: Tasks & Appointments V2 description: >- Unified V2 API for lead tasks and appointments: list, create, read, update, finish, unfinish and delete. Tasks and appointments share the same taskId namespace; each endpoint resolves the target by ID regardless of underlying type. - name: Opportunity description: Operations about opportunity - name: Communication V2 description: >- Fetch a single communication record (text / email / call) by its communication ID. Closes the webhook follow-up gap where only list-by-lead endpoints existed for text and email. - name: Vendor description: >- Team vendor directory: team members, sub-accounts and associated agents within the caller's team. - name: Lead Routing description: >- Lead routing configuration: read and update routing rules and default (supplement) rules per business type, and list the members and roles available for assignment. - name: Lead Activity V2 API description: >- Unified lead activity timeline: returns call, text and email activities for a lead in chronological order, including both auto-captured and agent-logged entries. - name: Tasks & Appointments description: >- Agent tasks and lead appointments. Supports listing a lead's appointments, listing / reading / creating / updating / deleting tasks on a lead. - name: Transactions V2 description: V2 transaction APIs. - name: Lead Manual Log description: >- Agent-recorded log of communications that happened outside the Lofty CRM (calls placed on a personal line, emails sent from another mailbox, SMS sent from another device). Three channels are supported: logCall, logEmail, logText. Direction fields are recorded from the agent's point of view: 'outbound' = agent -> lead, 'inbound' = lead -> agent. Persistence is asynchronous: a POST returns the new entry's ID once the write is enqueued, and the entry becomes readable after a short delay. - name: Calls description: >- Calls placed or received through the Lofty dialer. Supports fetching a recording URL, retrieving a single call record, and listing calls attached to a lead. - name: Agents V2 description: >- Agent lifecycle management: deactivate an agent of the caller's team (frees the license seat, revokes sessions and tokens, keeps leads and data untouched) and reactivate a previously deactivated agent (re-occupies a seat and restores access without data loss). Deactivation is reversible and distinct from deletion. - name: Agent User description: >- Agent onboarding and team directory operations. Create a new agent under the caller's team and attach tags to existing agents. - name: Sales Agents V2 description: >- Sales Agent (AI Assistant) management: read the caller's assistant and quota, query leads followed by AI, mute leads, manage working-pool membership and plan tasks, and update Sales Agent settings. - name: Calendar V2 API description: >- Unified V2 API for tasks and appointments on a lead: create, update, delete, finish, unfinish, query a paginated list, and find available meeting slots. Calendar IDs returned by POST /v2.0/calendar are composite strings of the form '``-task' or '``-appointment' and must be sent back as-is to the per-entry endpoints. - name: Lead System Logs description: Query a lead's system log. - name: Lead Transaction description: Operations about leads - name: Notifications V2 description: Operations for sending notifications to agents - name: Notes description: >- Free-text notes attached to a lead. Supports create, list, get-by-id, update and delete. Notes may be pinned to surface them at the top of the lead's timeline. System-generated notes (automated activity) are included on the list endpoint only when explicitly requested. - name: Listing description: >- Listing data access: retrieve published listings for a site feed (XML), and search active / sold listings by agent, office or MLS id. - name: Intelligent Features description: AI-powered features for lead analysis and communication - name: Leads description: >- Lead lifecycle operations: create / read / update / delete a lead, search leads by stage, source, tag, create time or update time, place an inquiry or property on a lead, list lead activities, resolve assignee by lead info, and handle Brokermint contact callbacks. - name: Members description: >- Team member directory: look up members by user ID, by account (email), or list all members of the caller's team. Also supports retrieving the current user's profile. - name: Team Features description: >- Team-scoped metadata: lead tags, custom fields, and lead ponds. Supports listing existing entries, adding a new custom field, and retrieving a specific lead pond. - name: Agent Organization description: >- Team organizational structure: read the caller's organization info, manage company and office records, and list permission profiles available to the team. - name: Communication description: >- Lead communication history and outbound messaging: list call / email / text history for a lead, search communications for an agent, and send SMS or email to a lead. - name: Webhooks description: > Use webhooks to be notified about events that happen in a lofty account. Supported webhook event types (listId): | listId | Event Type | Description | |--------|-----------|-------------| | 1 | Agent Info | Agent created or updated | | 2 | Lead Info | Lead created, updated, or deleted | | 3 | Lead Activity | Lead site activity (e.g. SiteBrowse, SiteFavorite, SiteSearch) | | 4 | Listing Alert | Listing alert changed | | 5 | Transaction | Transaction created, updated, or deleted | | 6 | Call | Call event (MANUAL and LOGGED only, excludes AUTO) | | 7 | Email | Email event (MANUAL and LOGGED only, excludes AUTO) | | 8 | Text | Text message event (MANUAL and LOGGED only, excludes AUTO) | | 9 | Note | Note created, updated, or deleted | | 10 | Task | Task created, updated, finished, or deleted | | 11 | Appointment | Appointment created, updated, finished, or deleted | | 12 | Pipeline Change | Lead pipeline stage changed | ### Notification Recipient Rules Here "team" means the entire Lofty client account (the organization), not the Lofty "Team add-on" product. Which subscribed users receive a callback depends on the subscription's delivery mode (`permissionMode`). In both modes, only users in the lead's account (team) who have subscribed to the event type are considered. **Assignment-based delivery — `permissionMode: 0` (default)** A subscriber receives the callback only for leads assigned to them or that they administer: - If the lead is a **hidden lead**, only the **assigned agent** receives the notification. - Otherwise, the subscriber receives it if they are the **assigned agent** of the lead, or a **Company Owner** or **Company Admin**. - All other subscribers do **not** receive the notification. **Ownership-based delivery — `permissionMode: 1`** A subscriber receives the callback for any lead they manage, regardless of who it is assigned to: - Every assignment-based case above still applies (assigned agent, Company Owner / Company Admin). - In addition, the subscriber receives the callback for any lead within their **ownership scope** — a lead owned by their **team** or **office**, or **personally owned** by them — even if it is assigned to someone else. - Hidden leads are still delivered only to users who manage them. Ownership-based mode is intended for team/account-level integrations that must cover every lead in their scope, not only assigned leads. Set `permissionMode` when creating the subscription (POST /v1.0/webhook); it defaults to `0`, so existing subscriptions are unaffected. ### Delivery Timing Webhooks are typically delivered within **1 minute** of the event being triggered. During periods of high traffic, delivery may be delayed, but will always be sent within **5 minutes**. For detailed callback payload structures, see [Webhook Event Payloads](/concepts/webhooks#event-payloads). - name: Saved Searches description: >- Read the property searches a lead has saved, together with how their listing alerts are delivered. A saved search and its listing alert are one object: the search conditions and the delivery cadence travel together. ### Coverage `criteria` is a fixed field set. Filters this version does not model yet are listed by name in `unmappedCriteria`, so a partially understood search can be told apart from a fully mapped one. Values of unmapped filters are not returned. ### Pausing alerts A paused search keeps its conditions and schedule; only the emails stop. Pausing sets the cadence to NEVER, the same as choosing Never in the CRM, so a paused search reads back as `INACTIVE`, with the cadence it replaced in `frequencyBeforePause`; resume restores the same cadence. Alerts also stay silent while the lead is unsubscribed from property alerts, whatever the cadence. ### Errors A request rejected by validation or by a business rule (missing or invalid field, duplicate search, recipient that is not the lead's, ...) answers HTTP 200 with `{"code": , "message": "..."}` instead of the saved search. Check `code` in the body rather than the HTTP status. Unknown ids answer HTTP 404 and leads the token user cannot see answer HTTP 403. | code | meaning | |---|---| | 20012 | A field is missing, invalid or not allowed; `message` names it | | 2000001 | A saved search of the lead already has the same filters | | 2000005 | The lead has no email address to send alerts to | | 2000011 | The saved search cannot be edited (created by the lead on the website) | | 100000 | Lofty could not complete the change; try again later | paths: /v1.0/leads/{leadId}/savedSearches/resume: post: tags: - Saved Searches summary: Resume the alerts of a lead's saved searches description: >- Switches alerts back on for the given saved searches, each at the cadence it ran at before it was paused (frequencyBeforePause on the read endpoint). Searches already on are reported as ALREADY_ACTIVE and keep their cadence. A search whose earlier cadence is unknown stays paused and is reported as PRIOR_FREQUENCY_UNKNOWN with a message; set alertFrequency through the update endpoint for it instead. The other searches resume as usual. A result of NOT_CHANGED means the search could not be switched on and should be checked in the CRM. operationId: resumeSavedSearches parameters: - name: leadId in: path description: ID of the lead whose alerts to resume. required: true schema: minimum: 1 type: integer format: int64 example: 100001 - name: Authorization in: header description: Bearer [access_token] required: true schema: type: string - name: Content-Type in: header description: application/json required: true schema: type: string example: application/json requestBody: content: application/json: schema: $ref: '#/components/schemas/SavedSearchResumeRequest' required: true responses: '200': description: >- Success. A request rejected by validation or by a business rule also answers HTTP 200, with `{"code": , "message": "..."}` in place of the result: check `code` in the body, not the HTTP status. Codes are listed under Errors in the Saved Searches section. content: application/json: schema: $ref: '#/components/schemas/SavedSearchStatusChangesResponse' '403': description: The token user cannot access this lead '404': description: A saved search id is not one of this lead's components: schemas: SavedSearchResumeRequest: required: - savedSearchIds type: object properties: savedSearchIds: type: array description: >- The saved searches of the lead to switch back on. Each resumes at the cadence it ran at before it was paused (frequencyBeforePause). A repeated id is resumed once. items: type: integer format: int64 example: 88123456789 SavedSearchStatusChangesResponse: type: object properties: results: type: array description: One entry per saved search the call selected items: $ref: '#/components/schemas/SavedSearchStatusChange' SavedSearchStatusChange: type: object properties: id: type: integer description: Saved search id format: int64 example: 88123456789 category: type: string description: Which emails the search sends enum: - PROPERTY_ALERT - MARKET_SNAPSHOT result: type: string description: What the call did to the search enum: - PAUSED - RESUMED - ALREADY_INACTIVE - ALREADY_ACTIVE - PRIOR_FREQUENCY_UNKNOWN - NOT_CHANGED previousAlertFrequency: type: string description: Cadence before the call enum: - NEVER - TERMINATED - REFUSED - INSTANTLY - DAILY - WEEKLY - BIWEEKLY - MONTHLY alertFrequency: type: string description: Cadence after the call nullable: true enum: - NEVER - TERMINATED - REFUSED - INSTANTLY - DAILY - WEEKLY - BIWEEKLY - MONTHLY status: type: string description: Status after the call nullable: true enum: - ACTIVE - INACTIVE message: type: string description: What to do next when the search was left unchanged; absent otherwise nullable: true description: One entry per saved search the call selected ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.