agencyzoom

Showing 25 of 104 from the live probe.

• Search Leads

  Search leads. POST /v1/api/leads/list Filter server-side. To pull one stage, pass workflowStageId — do NOT page the whole book and filter in memory. Args: filters: freeform filter dict. Keys AZ honors (from its OpenAPI spec, confirmed live): workflowId int, the pipeline workflowStageId the stage. String, and accepts several at once separated by "/" (e.g. "462347/436296"). assignedTo

• Lead Pipeline Counts

  Lead counts per stage. POST /v1/api/leads/pipeline-count Cheap way to size a stage before pulling it. Pass workflowId to choose the pipeline; omit it and AZ returns the primary pipeline. AZ documents this as taking the same request model as search_leads, but in practice it behaves as a fixed stage tally: workflowId changes the output, while status and the date filters were verified to leave the counts unchanged. Passing those adds a "_mcpWarning". For a count narrowed a

• Get Lead

  Full lead details. GET /v1/api/leads/{leadId}

• Create Lead

  Create a lead. POST /v1/api/leads/create All ID fields are integers. Use list_lead_sources, list_pipelines_and_stages, and list_employees to resolve names -> IDs first. Args: firstname: Required. email: Required. lead_source_id: Required int. From list_lead_sources(). assign_to: Required int. Producer/agent ID from list_employees(). pipeline_id: Required int. From list_pipelines_and_stages(). stage_id: Required int. Stage within that

• Batch Create Leads

  Batch create up to 5 personal leads. POST /v1/api/leads/batch-create Each lead dict must include the same required fields as create_lead: firstname, email, leadSourceId, assignTo, country, pipelineId, stageId.

• Update Lead

  Update a lead. PUT /v1/api/leads/{leadId} Pass ONLY the fields you want to change. This tool fetches the lead, maps AZ's read field names to its write field names, merges your changes over the top, and sends a complete body. Do NOT hand-merge a get_lead() response yourself. Two verified facts make that destructive: 1. The read and write names differ — assignedTo/workflowId/ workflowStageId/comments on the way out are assignTo/pipelineId/ stageId/note

• Change Lead Status

  Change lead status. PUT /v1/api/leads/{leadId}/status Verified working: marking a lead lost with a loss reason came back status 3 with lossReason set. Note it also clears workflowStageId — a won/lost/x-dated lead leaves the pipeline stages. TWO STATUS VOCABULARIES. This endpoint takes 0 ACTIVE, 2 WON, 3 LOST, 5 XDATED (the strings below). The status you FILTER on in search_leads is a six-value enum — 0 NEW, 1 QUOTED, 2 WON, 3 LOST, 4 CONTACTED, 5 EXPIRED — where 1 a

• Change Lead Stage

  Move a lead to a different pipeline stage. Goes through PUT /v1/api/leads/{leadId} (fetch, remap, full body), which is the path verified to actually move a lead. AZ's dedicated PUT /v1/api/leads/{leadId}/stage is NOT used, because it does not work: it takes LeadChangeStatusRequest (required `status`, with the stage as workflowStageId/toStageId), and the body this tool used to send — {"stageId": N} — matches nothing in that schema. Verified live: AZ answered {"messag

• Mark Lead Sold

  Mark a lead as sold. POST /v1/api/leads/{leadId}/sold Body is LeadSoldRequest: {"keepOpen": bool, "soldProducts": [SoldProduct]}. `keepOpen` leaves the lead open for its remaining unsold products. Each SoldProduct requires: locationId STRING location id, from list_locations() (e.g. "A0A0001") isSold bool a carrier carrierId, or standardCarrierCode. The spec calls these optional; AZ rejects the call without one:

• Add Note To Lead

  POST /v1/api/leads/{leadId}/notes

• Get Lead Notes

  GET /v1/api/leads/{leadId}/notes

• Get Lead Tasks

  GET /v1/api/leads/{leadId}/tasks

• Get Lead Opportunities

  GET /v1/api/leads/{leadId}/opportunities

• Get Lead Quotes

  Quotes on a lead. GET /v1/api/leads/{leadId}/quotes Quotes hang off the LEAD, not off an opportunity. Each Quote carries carrierId, productLineId, items and premium (whole dollars).

• Create Lead Quote

  Add a quote to a lead. POST /v1/api/leads/{leadId}/quotes AZ requires all four of carrierId, productLineId, items and premium. Args: carrier_id: From list_carriers(). product_line_id: From list_product_lines(). items: Number of items quoted (e.g. 2 autos). premium: WHOLE DOLLARS (spec example 300 = $300), not cents. Quoting is what moves a lead's quote totals; use mark_lead_sold() when the business is actually written.

• Update Lead Quote

  Update a quote on a lead. PUT /v1/api/leads/{leadId}/quotes The quote id goes in the BODY as `id`, not in the path. AZ requires id, carrierId, productLineId, items and premium on every update, so read the current quote with get_lead_quotes() and resend the unchanged values. premium is WHOLE DOLLARS, not cents.

• Get Lead Recycle Events

  Recycle-event picklist. GET /v1/api/{leadId}/recycle-events Despite the name and the path, this returns the agency's CONFIGURED recycle/x-date event types — a picklist for choosing an xDateType — not a history of what happened to this lead. The leadId scopes which options apply; it does not produce that lead's timeline. For a lead's actual history use get_lead_notes() and the lead's date fields.

• Delete Lead

  Delete a lead (irreversible). POST /v1/api/leads/{leadId}/delete-lead

• Search Customers

  Search customers. POST /v1/api/customers Keys AZ honors (from its OpenAPI spec, confirmed live — fullName="Gabbard" correctly returns just that household): fullName partial match on the full name firstname/lastname partial match email, phone policyNumber searches written AND AMS-synced policies state (2-letter), city agentId assigned agent id status 1 active, 0 inactive, -1 all (default -

• Search Customers Cached

  Find a customer by name, phone, or email. Queries a Supabase mirror of the AZ customer list (refreshed hourly) rather than the AZ API. Use it for fuzzy, multi-word, or typo-tolerant matching. (The original reason for this tool — "AZ search is broken" — was really a filter-key error: AZ has no searchTerm on POST /v1/api/customers and ignores it. That endpoint's real fullName/firstname/lastname/email/phone filters do work, so search_customers is fine for structured lookups

• Get Customer

  GET /v1/api/customers/{customerId}

• Update Customer

  PUT /v1/api/customers/{customerId}

• Create Customer

  Create a customer directly (bypassing lead flow). POST /v1/api/customers/create

• Get Customer Policies

  Policies entered directly in AZ. GET /v1/api/customers/{customerId}/policies This is the AZ-ENTERED store, and it is the secondary one. Prefer get_customer_ams_policies() as the source of truth for what a customer actually has — see that tool. Use this store when you specifically need an AZ-native policy id (policy_ids on a ticket, update_policy, update_policy_status, endorse_policy), or to spot double-counting. Records here often have an EMPTY policyNumber, so they can

• Get Customer Ams Policies

  Policies synced from the AMS — THE DEFAULT SOURCE OF TRUTH. GET /v1/api/customers/{customerId}/ams-policies When you need to know what policies a customer has, read this store and work from it. The AMS (EZLynx, HawkSoft, AMS360, ...) is the system of record; AZ-entered policies are a secondary, hand-maintained store that is often thinner — real policy numbers live here, and AZ-entered duplicates frequently have an empty policyNumber. A customer can hold BOTH stores