> ## 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.

# Update Task (V1)

> Partially updates an existing task. Fields not supplied are left unchanged.

Notes:
- When finishFlag is true, the task is marked completed and all other fields are ignored. Completion is rejected for smart-plan tasks (TASK_IS_SMARTPLAN).
- When leadId is supplied, it must match the task's existing lead; otherwise 400 INVALID_UPDATE_OPERATION_LEADID.
- At least one field must be supplied; an entirely empty payload returns 400 MISSING_PARAMETER.
- Caller must have manage permission on the task's lead.
- The response body is empty.



## OpenAPI

````yaml openapi/openapi.json PUT /v1.0/tasks/{taskId}
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: Listing V2
    description: Listing search V2
  - 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 '<numericId>-task' or '<numericId>-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).
paths:
  /v1.0/tasks/{taskId}:
    put:
      tags:
        - Tasks & Appointments
      summary: Update Task (V1)
      description: >-
        Partially updates an existing task. Fields not supplied are left
        unchanged.


        Notes:

        - When finishFlag is true, the task is marked completed and all other
        fields are ignored. Completion is rejected for smart-plan tasks
        (TASK_IS_SMARTPLAN).

        - When leadId is supplied, it must match the task's existing lead;
        otherwise 400 INVALID_UPDATE_OPERATION_LEADID.

        - At least one field must be supplied; an entirely empty payload returns
        400 MISSING_PARAMETER.

        - Caller must have manage permission on the task's lead.

        - The response body is empty.
      operationId: updateTask_1
      parameters:
        - name: taskId
          in: path
          description: ID of the task to update.
          required: true
          schema:
            minimum: 1
            type: integer
            format: int64
          example: 563172647619608
        - 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/TaskRequest'
        required: true
      responses:
        '200':
          description: Task updated successfully. No response body.
        '400':
          description: >-
            Missing or invalid parameter (20012 INVALID_PARAMETER /
            MISSING_PARAMETER), finish attempted on a smart-plan task
            (TASK_IS_SMARTPLAN), or leadId does not match the task's lead
            (INVALID_UPDATE_OPERATION_LEADID).
        '401':
          description: Missing or invalid authentication token.
        '404':
          description: >-
            Task does not exist (TASK_NOT_EXIST) or caller lacks access to the
            lead (20006 LEAD_NOT_EXIST).
        '500':
          description: Internal server error.
components:
  schemas:
    TaskRequest:
      required:
        - assignedRole
        - content
        - deadline
        - leadId
        - type
      type: object
      properties:
        content:
          type: string
          description: Description of the task.
          example: Send an email to my lead
        leadId:
          type: integer
          description: ID of the lead this task belongs to.
          format: int64
          example: 563172647619608
        deadline:
          type: integer
          description: Deadline of the task, in milliseconds since Unix epoch (UTC).
          format: int64
          example: 1508580010000
        type:
          type: string
          description: Type of the task.
          example: Call
          enum:
            - Other
            - Call
            - Email
            - Text
        assignedRole:
          type: string
          description: Role the task is assigned to.
          example: Agent
          enum:
            - Agent
            - Assistant
        finishFlag:
          type: boolean
          description: >-
            When true on update, the task is marked completed and other fields
            are ignored.
          example: true
          default: false
      description: Task payload.

````