Create Treatment Record

Record a treatment given to one mob: a drench, fluke or lice treatment, a vaccine, a vitamin or mineral, an antibiotic, pain relief, an additive, a foot treatment, a reproductive treatment or an HGP implant. Creates the one task that is the record, with its typed treatment child, and answers with that task exactly as GET /tasks/{id} would. The server sets the producer from the farm's owner, operation_type to treatment, capture_source to agent and operator from the signed-in user. head defaults to the mob's head count. date (YYYY-MM-DD) defaults to today and is stored as midday in the application time zone; a future date creates the open task (status: pending, created_as: task) instead of a completed record.

category is required: drench, fluke, lice, flystrike, other_external_parasite, vaccine, vitamin_mineral, antibiotic, pain_relief, feed_water_additive, foot_treatment, reproductive, hgp or other. route (oral, injection, backline, jetting, dip, capsule, topical, in_feed_water) is what the farmer said; leave it unset if they did not.

Send one products entry per product given together, up to 10 (name, active, batch, expiry, dose, whp_days, esi_days, and the wool and milk intervals when the label has them). A product with no interval adds nothing to the mob's status. Never invent a batch, expiry, dose or withholding period; listProducts is a short catalogue to check the label against. A completed record with no product row is refused (422, "A treatment needs at least one product").

GET /mobs/{id} and getFarmStatus report the mob's current status, derived from this record's products. A treatment belongs to a mob; a paddock id is a 404 here.

Before calling, check listTasks with this mob's asset_id and filter[status][]=completed for a same-date duplicate, and confirm the summary with the farmer. The MCP tool is refused until it is called again with confirm: true. If the call errors or times out, read the mob's records back before retrying: a 502 or 504 can arrive after the write succeeded. Do not send broadcast or share_scope. Needs a grant that allows writing in the mob's business. A 403 whose code is insufficient_access is that refusal; its detail names the business and the access that is missing. Photos. A file on disk is staged with createImageUpload, whose curl_example PUTs the bytes, and attached with image_upload_ids. Never base64-encode a local photo into a tool call. A public http(s) URL: pass image_urls. Only a tiny generated image (under about 100 KB decoded) uses image_base64s. One upload can be attached to several records until it expires. On update, image_mode defaults to append (add to the existing photos); replace swaps them all out; remove_image_ids deletes specific ones. If any image fails, the whole create or update is rolled back. The attaching call still needs confirm: true. createImageUpload and its PUT do not.