> 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/create-new-service-status.md). # Create new service status Create a new service status. It is tenant-wide: every service type uses the tenant's statuses, and the status carries no position of its own. 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 statuses 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":{"ServiceStatusResponse":{"description":"Example response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/ServiceStatusResponseSchema"}}}}},"schemas":{"ServiceStatusResponseSchema":{"title":"ServiceStatusResponseSchema","type":"object","properties":{"serviceStatusUid":{"$ref":"#/components/schemas/UID"},"tenantUid":{"$ref":"#/components/schemas/UID"},"name":{"type":"string"},"state":{"$ref":"#/components/schemas/ServiceStateENUM"},"deprecated":{"type":"boolean","default":false,"description":"A deprecated status is kept for the service orders that already carry it but is no longer offered when picking a status, and a status change to it is refused with a 400 — unless it is the status the service order is already at, which does nothing."},"color":{"type":"string","description":"The color the status is drawn in, as a hex color such as #0065d2. It is what the status chip is colored by wherever the service order is shown. An empty string when no color has been chosen, which leaves the chip in the client's default color."},"customerVisibleLabel":{"type":"string","description":"What the customer sees this status called, on the service portal and in the messages sent to them. An empty string when none has been set, and the internal name is then what the customer reads too — a customer-visible label is only needed where the internal wording is not meant for the customer."}},"required":["serviceStatusUid","tenantUid","name","state","deprecated","color","customerVisibleLabel"]},"UID":{"title":"UID","type":"string","pattern":"^[A-Za-z0-9-_]+"},"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"]},"ServiceStatusCreateRequestSchema":{"allOf":[{"$ref":"#/components/schemas/ServiceStatusUpdateRequestSchema"},{"properties":{"serviceStatusUid":{"$ref":"#/components/schemas/UID"}}}],"type":"object","title":"ServiceStatusCreateRequestSchema"},"ServiceStatusUpdateRequestSchema":{"title":"ServiceStatusUpdateRequestSchema","type":"object","properties":{"name":{"type":"string"},"state":{"$ref":"#/components/schemas/ServiceStateENUM"},"deprecated":{"type":"boolean","description":"A deprecated status is kept for the service orders that already carry it but is no longer offered when picking a status, and a status change to it is refused with a 400 — unless it is the status the service order is already at, which does nothing."},"color":{"type":"string","description":"The color the status is drawn in, as a hex color such as #0065d2. Send an empty string to leave the chip in the client's default color."},"customerVisibleLabel":{"type":"string","description":"What the customer sees this status called, on the service portal and in the messages sent to them. Send an empty string to have the customer read the internal name as well."}},"required":["name","state"]}},"requestBodies":{"ServiceStatusCreateRequest":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/ServiceStatusCreateRequestSchema"}}}}}},"paths":{"/tenants/{tenantUid}/serviceorders/statuses":{"post":{"summary":"Create new service status","operationId":"post-serviceorders-statuses","description":"Create a new service status. It is tenant-wide: every service type uses the tenant's statuses, and the status carries no position of its own.\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 statuses asks for any service permission.\n\nRequired permissions: SERVICE_CONFIG","responses":{"201":{"$ref":"#/components/responses/ServiceStatusResponse"}},"tags":["Service"],"requestBody":{"$ref":"#/components/requestBodies/ServiceStatusCreateRequest"}}}}} ``` --- # 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/create-new-service-status.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.