> 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/update-service-type.md).

# Update service type

Update a service type. Configuring the workflow is separated from working on the service orders that run through it: this is a configuration write and asks for SERVICE\_CONFIG, while reading types asks for any service permission.

Required permissions: 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":{"ServiceTypeResponse":{"description":"Example response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/ServiceTypeResponseSchema"}}}}},"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"]},"ServiceTypeUpdateRequestSchema":{"title":"ServiceTypeUpdateRequestSchema","type":"object","properties":{"name":{"type":"string"},"serviceStatuses":{"type":"array","deprecated":true,"description":"Deprecated. Statuses are tenant-wide and a service type carries no list of its own, so the list is ignored: sending it changes nothing, and the type is served with the tenant's statuses regardless.\nIt is no longer in the required set, and will be removed after the announced deprecation window; see the deprecation log for the date.","items":{"$ref":"#/components/schemas/ServiceTypeStatusSchema"}},"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, stored exactly as written, markers included. 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.\nWhen the text differs from the one in force for the type, Flow records a new version and the service orders created from then on carry it; the service orders that already exist keep the wording they were created under, and nothing is re-asked. Sending the same text again records nothing. Send an empty string to have the type add nothing. Left out, the type keeps the text it has, and a type created without one adds nothing."},"estimatedBusinessDays":{"type":"integer","nullable":true,"minimum":0,"maximum":365,"description":"How long work of this type is expected to take, counted in business days: 0 to 365, anything outside that range is refused with a 400. Send null to leave the type without an expected turnaround, and nothing is prefilled. Left out, the type keeps the figure it has, and a type created without one has none.\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. Set that one on the service type's per-store turnaround endpoint."},"dueWarningCount":{"type":"integer","nullable":true,"minimum":1,"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: 1 or more, anything below is refused with a 400. Send null to leave the type without such a warning. Left out, the type keeps the figure it has, and a type created without one has none.\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,"minimum":2,"maximum":10,"description":"The largest number of service orders one intake registers for work of this type: 2 to 10, anything outside that range is refused with a 400. A maximum of one is what null already says, so 1 is refused with the rest of the range. Send null to leave work of this type taken in one unit at a time. Left out, the type keeps the figure it has, and a type created without one has none.\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. 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 of the SERIAL_NUMBER or IMEI system kind as an unconditional placement, visibleWhen null, so the units can be told apart once they are registered. 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."},"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. The key must be one the platform offers, matched exactly; other values are refused, the empty string among them.\nSend null to leave the type without an icon, and clients draw their default glyph. Left out, the type keeps the key it has, and a type created without one has no icon.\nIt only ever picks the glyph. Nothing is computed from it."}},"required":["name"]},"ServiceTypeStatusSchema":{"title":"ServiceTypeStatusSchema","deprecated":true,"description":"Deprecated. It is the shape of the deprecated serviceStatuses list on the service type request schemas, and that list is ignored: statuses are tenant-wide, and are written through the service status endpoints. 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"},"position":{"type":"integer"}},"required":["serviceStatusUid"]}},"requestBodies":{"ServiceTypeUpdateRequest":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/ServiceTypeUpdateRequestSchema"}}}}}},"paths":{"/tenants/{tenantUid}/serviceorders/types/{serviceTypeUid}":{"put":{"summary":"Update service type","operationId":"put-serviceorders-types","description":"Update a service type.\nConfiguring the workflow is separated from working on the service orders that run through it: this is a configuration write and asks for SERVICE_CONFIG, while reading types asks for any service permission.\n\nRequired permissions: SERVICE_CONFIG","responses":{"200":{"$ref":"#/components/responses/ServiceTypeResponse"}},"tags":["Service"],"requestBody":{"$ref":"#/components/requestBodies/ServiceTypeUpdateRequest"}}}}}
```


---

# 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/update-service-type.md?ask=<question>&goal=<user_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.