> ## Documentation Index > Fetch the complete documentation index at: https://docs.assetinfinity.ai/llms.txt > Use this file to discover all available pages before exploring further. # What this work can be given to: the crews, the technicians in each of them, the technicians no > crew is showing, and — asked for — the suppliers. A search is words, not a phrase, and a technician's words include the crew they are listed under, so "raj mechanical" names one of the two Rajs on the list. Nested and indented by `depth`, and both levels are selectable: a job goes to a crew, or to a named person in it. Current membership is many-to-many, so somebody in two crews is listed under both and either choice writes the same worker. A technician no surviving crew shows — in no crew, or in one this job's scope excluded — comes back with a null team_id, for the client to head its own block over: nobody is silently dropped from the list. Narrowed by whatever the caller knows. A team's own scope follows the rule it is documented with — naming no category, site, type or role means unrestricted — and the category test follows the classification tree, so a crew that handles Pumps is offered for a centrifugal pump. A technician is offered where they are based at the site or can travel to it, nested under a crew exactly as loose, so the two halves of the list cannot disagree. A supplier is offered where contracts.vendor_sites says they cover the site, or where they name no site at all. Refuses nothing: the three assignment functions decide whether the caller may act on what this returns. ## OpenAPI ````yaml /api-reference/openapi.json post /rpc/assignable_targets openapi: 3.0.0 info: description: '' title: >- The only schema PostgREST exposes. Reads are security_invoker views; writes are SECURITY DEFINER functions. Rebuilt wholesale on every deploy — it holds no data. version: 12.2.3 servers: - url: https://app.assetinfinity.ai/api security: [] tags: - name: Signing in - name: Profile - name: Assets - name: Asset lifecycle - name: Work lifecycle - name: Maintenance - name: Inventory - name: Inventory detail - name: Procurement - name: Contracts - name: Workforce - name: Capacity - name: Dispatch - name: Tools - name: Inspections - name: Verification - name: Reliability - name: Parts demand - name: Sensors and meters - name: Map - name: Floor plans - name: Labels - name: Lost and found - name: Root cause analysis - name: Reports - name: Audit center - name: Activity - name: Notifications - name: Channels - name: Search - name: Copilot - name: Import - name: Files - name: Sync - name: Support - name: Admin - name: Access - name: Lookups - name: Read models - name: Branding - name: Custom fields - name: Form studio - name: Workflows - name: Workflow studio - name: Rules - name: Statuses and transitions - name: Currencies and locales - name: Work configuration - name: Asset configuration - name: Inventory configuration - name: Tool configuration - name: Workforce configuration - name: Vendor and contract configuration - name: Document configuration - name: Inspection configuration - name: Sites, locations and the organisation - name: Platform - name: Amendments - name: Asset clone - name: Asset components - name: Asset register - name: Asset transfer - name: Audit feed - name: Billing - name: Bookings - name: Budgets - name: Bulk jobs - name: Calibration history - name: Capex plans - name: Conversations - name: Costing - name: Currency - name: Dashboards - name: Directory sync - name: Document control - name: Document folders - name: Document tree - name: Documents - name: Energy - name: Extracts - name: Features - name: Feeds - name: File exchange - name: Filing exceptions - name: Finance - name: Inbound mail - name: Keys - name: Knowledge - name: Licence - name: List views - name: Locations - name: Mapping - name: Mcp - name: Mcp oauth - name: Mfa - name: Numbering - name: Permits - name: Readers - name: Reference - name: Reference columns - name: Reference entry - name: Release - name: Scim - name: Security streams - name: Self verification - name: Setup - name: Shutdown - name: Sso - name: Telegram - name: Tenant switch - name: The caller's own work - name: The checklist library - name: Tools on a job, and who has them out - name: Tray - name: Vendor spend forecast - name: Vendors and contracts - name: Visitors - name: Work order execution - name: Work sequencing - name: Workforce detail externalDocs: description: PostgREST Documentation url: https://postgrest.org/en/v12/references/api.html paths: /rpc/assignable_targets: post: tags: - Workforce summary: >- What this work can be given to: the crews, the technicians in each of them, the technicians no description: >- crew is showing, and — asked for — the suppliers. A search is words, not a phrase, and a technician's words include the crew they are listed under, so "raj mechanical" names one of the two Rajs on the list. Nested and indented by `depth`, and both levels are selectable: a job goes to a crew, or to a named person in it. Current membership is many-to-many, so somebody in two crews is listed under both and either choice writes the same worker. A technician no surviving crew shows — in no crew, or in one this job's scope excluded — comes back with a null team_id, for the client to head its own block over: nobody is silently dropped from the list. Narrowed by whatever the caller knows. A team's own scope follows the rule it is documented with — naming no category, site, type or role means unrestricted — and the category test follows the classification tree, so a crew that handles Pumps is offered for a centrifugal pump. A technician is offered where they are based at the site or can travel to it, nested under a crew exactly as loose, so the two halves of the list cannot disagree. A supplier is offered where contracts.vendor_sites says they cover the site, or where they name no site at all. Refuses nothing: the three assignment functions decide whether the caller may act on what this returns. parameters: - $ref: '#/components/parameters/preferParams' requestBody: content: application/json: schema: description: >- What this work can be given to: the crews, the technicians in each of them, the technicians no crew is showing, and — asked for — the suppliers. A search is words, not a phrase, and a technician's words include the crew they are listed under, so "raj mechanical" names one of the two Rajs on the list. Nested and indented by `depth`, and both levels are selectable: a job goes to a crew, or to a named person in it. Current membership is many-to-many, so somebody in two crews is listed under both and either choice writes the same worker. A technician no surviving crew shows — in no crew, or in one this job's scope excluded — comes back with a null team_id, for the client to head its own block over: nobody is silently dropped from the list. Narrowed by whatever the caller knows. A team's own scope follows the rule it is documented with — naming no category, site, type or role means unrestricted — and the category test follows the classification tree, so a crew that handles Pumps is offered for a centrifugal pump. A technician is offered where they are based at the site or can travel to it, nested under a crew exactly as loose, so the two halves of the list cannot disagree. A supplier is offered where contracts.vendor_sites says they cover the site, or where they name no site at all. Refuses nothing: the three assignment functions decide whether the caller may act on what this returns. properties: p_asset_category_id: format: uuid type: string p_include_vendors: format: boolean type: boolean p_search: format: text type: string p_site_id: format: uuid type: string p_work_order_type_id: format: uuid type: string type: object application/vnd.pgrst.object+json: schema: description: >- What this work can be given to: the crews, the technicians in each of them, the technicians no crew is showing, and — asked for — the suppliers. A search is words, not a phrase, and a technician's words include the crew they are listed under, so "raj mechanical" names one of the two Rajs on the list. Nested and indented by `depth`, and both levels are selectable: a job goes to a crew, or to a named person in it. Current membership is many-to-many, so somebody in two crews is listed under both and either choice writes the same worker. A technician no surviving crew shows — in no crew, or in one this job's scope excluded — comes back with a null team_id, for the client to head its own block over: nobody is silently dropped from the list. Narrowed by whatever the caller knows. A team's own scope follows the rule it is documented with — naming no category, site, type or role means unrestricted — and the category test follows the classification tree, so a crew that handles Pumps is offered for a centrifugal pump. A technician is offered where they are based at the site or can travel to it, nested under a crew exactly as loose, so the two halves of the list cannot disagree. A supplier is offered where contracts.vendor_sites says they cover the site, or where they name no site at all. Refuses nothing: the three assignment functions decide whether the caller may act on what this returns. properties: p_asset_category_id: format: uuid type: string p_include_vendors: format: boolean type: boolean p_search: format: text type: string p_site_id: format: uuid type: string p_work_order_type_id: format: uuid type: string type: object application/vnd.pgrst.object+json;nulls=stripped: schema: description: >- What this work can be given to: the crews, the technicians in each of them, the technicians no crew is showing, and — asked for — the suppliers. A search is words, not a phrase, and a technician's words include the crew they are listed under, so "raj mechanical" names one of the two Rajs on the list. Nested and indented by `depth`, and both levels are selectable: a job goes to a crew, or to a named person in it. Current membership is many-to-many, so somebody in two crews is listed under both and either choice writes the same worker. A technician no surviving crew shows — in no crew, or in one this job's scope excluded — comes back with a null team_id, for the client to head its own block over: nobody is silently dropped from the list. Narrowed by whatever the caller knows. A team's own scope follows the rule it is documented with — naming no category, site, type or role means unrestricted — and the category test follows the classification tree, so a crew that handles Pumps is offered for a centrifugal pump. A technician is offered where they are based at the site or can travel to it, nested under a crew exactly as loose, so the two halves of the list cannot disagree. A supplier is offered where contracts.vendor_sites says they cover the site, or where they name no site at all. Refuses nothing: the three assignment functions decide whether the caller may act on what this returns. properties: p_asset_category_id: format: uuid type: string p_include_vendors: format: boolean type: boolean p_search: format: text type: string p_site_id: format: uuid type: string p_work_order_type_id: format: uuid type: string type: object text/csv: schema: description: >- What this work can be given to: the crews, the technicians in each of them, the technicians no crew is showing, and — asked for — the suppliers. A search is words, not a phrase, and a technician's words include the crew they are listed under, so "raj mechanical" names one of the two Rajs on the list. Nested and indented by `depth`, and both levels are selectable: a job goes to a crew, or to a named person in it. Current membership is many-to-many, so somebody in two crews is listed under both and either choice writes the same worker. A technician no surviving crew shows — in no crew, or in one this job's scope excluded — comes back with a null team_id, for the client to head its own block over: nobody is silently dropped from the list. Narrowed by whatever the caller knows. A team's own scope follows the rule it is documented with — naming no category, site, type or role means unrestricted — and the category test follows the classification tree, so a crew that handles Pumps is offered for a centrifugal pump. A technician is offered where they are based at the site or can travel to it, nested under a crew exactly as loose, so the two halves of the list cannot disagree. A supplier is offered where contracts.vendor_sites says they cover the site, or where they name no site at all. Refuses nothing: the three assignment functions decide whether the caller may act on what this returns. properties: p_asset_category_id: format: uuid type: string p_include_vendors: format: boolean type: boolean p_search: format: text type: string p_site_id: format: uuid type: string p_work_order_type_id: format: uuid type: string type: object required: true responses: '200': description: OK components: parameters: preferParams: description: Preference in: header name: Prefer required: false schema: enum: - params=single-object type: string ````