> For the complete documentation index, see [llms.txt](https://docs.flowretail.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flowretail.com/docs/developers/api-documentation/service/list-service-types.md). # List service types List service types. Reading them asks for any service permission — SERVICE\_ORDER or SERVICE\_STORE\_CONFIG at the tenant, at an organization or at any one store, or SERVICE\_CONFIG, which is held at the tenant only — because whoever configures the service types reads them, and the service screens read them to work. A tenant-wide ADMIN grant counts as every permission. A caller holding none of them, a user with no role assignments included, is refused with a 403. Required permissions: SERVICE\_ORDER, SERVICE\_STORE\_CONFIG, SERVICE\_CONFIG ```json {"openapi":"3.0.2","info":{"title":"Flow Retail API version 2","version":"2.0.0"},"tags":[{"name":"Service","description":"Service"}],"servers":[{"description":"Flow Retail Production","url":"https://api.flowretail.com/v2"},{"description":"Flow Retail Stage","url":"https://api.stage.flowretail.com/v2"}],"security":[{"accessToken":[]},{"authToken":[]},{"integrationToken":[]}],"components":{"securitySchemes":{"accessToken":{"description":"Access token recevied after user login with a deviceToken","scheme":"bearer","type":"http"},"authToken":{"description":"Token received from the auth service","scheme":"bearer","type":"http"},"integrationToken":{"scheme":"bearer","type":"http"}},"responses":{"ServiceTypeListResponse":{"description":"Example response","content":{"application/json":{"schema":{"type":"object","properties":{"items":{"type":"array","items":{"$ref":"#/components/schemas/ServiceTypeResponseSchema"}},"paging":{"$ref":"#/components/schemas/Paging"}},"required":["items","paging"]}}}}},"schemas":{"ServiceTypeResponseSchema":{"title":"ServiceTypeResponseSchema","type":"object","properties":{"serviceTypeUid":{"$ref":"#/components/schemas/UID"},"tenantUid":{"$ref":"#/components/schemas/UID"},"serviceStatuses":{"type":"array","deprecated":true,"description":"Deprecated. Statuses are tenant-wide and a service type carries no list of its own — read the tenant's statuses through the service status endpoints. During the deprecation window it lists every status of the tenant that is not deprecated, ordered by state, in the order of ServiceStateENUM's values, and then by name, with position counting from 1 in that order, so a client that still reads it sees the same statuses on every type.\nIt is still served during the deprecation window, and is no longer in the required set. It will be removed after the announced deprecation window; see the deprecation log for the date.","items":{"$ref":"#/components/schemas/ServiceStatusWithPosition"}},"name":{"type":"string"},"deprecated":{"type":"boolean"},"additionalTermsText":{"type":"string","description":"Terms and conditions that apply to service orders of this type on top of the tenant's terms, in the terms format that termsText in the service settings describes — a data-loss notice on phone repairs, a worn-parts clause on bike service. On a service order of this type it is appended after the tenant's terms in termsText, as both read when the service order is created.\nSaving a changed text records a new version of it; the service orders already created keep the wording they were created under. An empty string when the type adds nothing, and the tenant's terms alone apply."},"estimatedBusinessDays":{"type":"integer","nullable":true,"description":"How long work of this type is expected to take, counted in business days. null when the type has no expected turnaround, and nothing is prefilled.\nIntake prefills the service order's readyAtEstimate from it: the day of registration plus this many business days, skipping Saturdays, Sundays and the active days of the tenant's holiday calendar that apply to the store. Core computes that date and serves it as readyAtEstimate on the service type's per-store turnaround response; the client reads it there rather than counting days itself. It is a starting point rather than a promise — staff adjust the date case by case, and the adjusted date is what the service order carries.\nA store can hold a figure of its own for this type, which wins over this one for that store. Read the figure that actually applies through the service type's per-store turnaround endpoint."},"dueWarningCount":{"type":"integer","nullable":true,"description":"When at least this many service orders of this type are due on the same day, the intake client shows a soft nudge to the user putting a due date on a service order. null when the type has no such warning.\nJob types aggregate into it automatically, because they live under the service type: however finely the work is sliced into job types, they are all counted against this one number.\nIt only ever triggers the nudge. Nothing is computed from it, no date is derived from it, and no submit is ever blocked by it."},"maxIntakeUnits":{"type":"integer","nullable":true,"description":"The largest number of service orders one intake registers for work of this type. A store taking in several identical units at once — a batch of machines to preinstall — registers one service order per unit without asking the same questions again. null when work of this type is taken in one unit at a time, which is every type that has not been given a figure.\nNothing is computed from it and there is no batch operation behind it: the client sends one ordinary service order create per unit, each naming the customer and each carrying its own serviceOrderUid, and each one is an ordinary service order from the moment it exists. Nothing groups them afterwards.\nIt only ever decides whether the intake client offers to register several units, and it offers that only where the resolved intake form also places a field that tells one unit from another — an unconditional placement, visibleWhen null, of the SERIAL_NUMBER or IMEI system kind. Units that differ in nothing cannot be told apart once they are registered, so where the form asks for no such value the client offers nothing, whatever this figure says. Nothing on the server checks that such a field is placed: a figure is accepted whatever the forms of the type's stores ask for, and no create is ever refused because of it."},"iconKey":{"type":"string","nullable":true,"description":"The icon the type is shown with, as one of the platform's icon keys — a semantic name such as wrench, bike or phone, never an image. null when no icon has been chosen.\nEach client maps the keys it knows to glyphs it bundles and draws one default glyph for null and for any key it does not know. Extensible — new keys may be added, so clients must not fail on a key they do not know.\nIt only ever picks the glyph. Nothing is computed from it."}},"required":["serviceTypeUid","tenantUid","name","deprecated","additionalTermsText","estimatedBusinessDays","dueWarningCount","maxIntakeUnits","iconKey"]},"UID":{"title":"UID","type":"string","pattern":"^[A-Za-z0-9-_]+"},"ServiceStatusWithPosition":{"title":"ServiceStatusWithPosition","deprecated":true,"description":"Deprecated. It is the shape of the deprecated serviceStatuses list on the service type, and nothing else uses it: statuses are tenant-wide, and the tenant's statuses are read through the service status endpoints as ServiceStatusResponseSchema. This schema will be removed after the announced deprecation window; see the deprecation log for the date.","type":"object","properties":{"serviceStatusUid":{"$ref":"#/components/schemas/UID"},"serviceStatusName":{"type":"string"},"position":{"type":"integer"},"state":{"$ref":"#/components/schemas/ServiceStateENUM"},"color":{"type":"string","description":"The hex color of the status, like #0065d2 — the same value as on the status itself, embedded so status chips render without a second fetch."},"customerVisibleLabel":{"type":"string","description":"What the customer sees for this status on the portal and in messages. The internal name is used when empty."}},"required":["serviceStatusUid","serviceStatusName","position","state","color","customerVisibleLabel"]},"ServiceStateENUM":{"title":"ServiceStateENUM","description":"Where a service order stands, as the platform understands it. Every status a tenant defines maps to exactly one state, and it is the state Flow reasons about: the workspace filters, the wording the portal shows the customer and the turnaround figures all follow the state rather than the name the status was given.\nAWAITING_PRODUCT: the service order is registered, but the device has not arrived yet.\nNOT_STARTED: the device is here and the work is queued.\nIN_TRANSIT: the service order is in a box on its way between locations.\nIN_PROGRESS: the work is being done.\nWAITING_CUSTOMER: waiting for an answer from the customer — never for the device, which is what AWAITING_PRODUCT is for.\nWAITING_SUPPLIER: waiting for parts or for an answer from a supplier.\nREADY_FOR_PICKUP: the outcome is ready to be handed over.\nCOMPLETE: the customer has the device back. This is the handover, never the payment.\nCANCELLED: the service order ended without a completed repair.\nCOMPLETE and CANCELLED are the terminal states.\nThe states are owned by the platform: tenants never define or rename them, and only decide which state each of their own statuses maps to. A status that exists today keeps the state it has until the tenant remaps it — nothing is remapped for them.\nExtensible — new states may be added, so clients must not fail on a value they do not know.","type":"string","enum":["AWAITING_PRODUCT","NOT_STARTED","IN_TRANSIT","IN_PROGRESS","WAITING_CUSTOMER","WAITING_SUPPLIER","READY_FOR_PICKUP","COMPLETE","CANCELLED"]},"Paging":{"description":"totalCount The total number of items in the result set.\n\npageSize The number of items per page.\n\npageNumber The current page in the result set.","properties":{"pageNumber":{"type":"integer"},"pageSize":{"type":"integer"},"totalCount":{"type":"integer"}},"required":["totalCount","pageSize","pageNumber"],"title":"Paging","type":"object"},"SortDirectionENUM":{"description":"|ENUM | Description |\n| ---------------- | ------------ |\n| ASC | Sort in ascending order|\n| DESC | Sort in descending order|\n","enum":["ASC","DESC"],"title":"SortDirectionENUM","type":"string"}},"parameters":{"pageNumberQuery":{"description":"Reference to a specific page in a result set.","in":"query","name":"pageNumber","required":false,"schema":{"type":"integer"}},"pageSizeQuery":{"description":"The number of items per page in a result set.","in":"query","name":"pageSize","required":false,"schema":{"type":"integer"}},"sortByQuery":{"description":"Defines which field the resource list is sorted by.","in":"query","name":"sortBy","required":false,"schema":{"type":"string"}},"sortDirectionQuery":{"description":"Reference to a sort direction","explode":false,"in":"query","name":"sortDirection","schema":{"$ref":"#/components/schemas/SortDirectionENUM"},"style":"form"}}},"paths":{"/tenants/{tenantUid}/serviceorders/types":{"get":{"summary":"List service types","tags":["Service"],"responses":{"200":{"$ref":"#/components/responses/ServiceTypeListResponse"}},"operationId":"get-serviceorders-types","description":"List service types.\nReading them asks for any service permission — SERVICE_ORDER or SERVICE_STORE_CONFIG at the tenant, at an organization or at any one store, or SERVICE_CONFIG, which is held at the tenant only — because whoever configures the service types reads them, and the service screens read them to work. A tenant-wide ADMIN grant counts as every permission. A caller holding none of them, a user with no role assignments included, is refused with a 403.\n\nRequired permissions: SERVICE_ORDER, SERVICE_STORE_CONFIG, SERVICE_CONFIG","parameters":[{"$ref":"#/components/parameters/pageNumberQuery"},{"$ref":"#/components/parameters/pageSizeQuery"},{"$ref":"#/components/parameters/sortByQuery"},{"$ref":"#/components/parameters/sortDirectionQuery"}]}}}} ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.flowretail.com/docs/developers/api-documentation/service/list-service-types.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.