> ## Documentation Index
> Fetch the complete documentation index at: https://developers.sults.com.br/llms.txt
> Use this file to discover all available pages before exploring further.

# Editar pedido

> Cancela, reativa ou troca a situação de um pedido na plataforma do SULTS.



## OpenAPI

````yaml /api-reference/openapi.json put /api/v1/comercial/pedido/{pedidoId}
openapi: 3.1.0
info:
  title: API SULTS
  version: v1
  description: >-
    API REST do SULTS. Todas as chamadas devem ser autenticadas por um token
    enviado, puro e sem o prefixo `Bearer`, no cabeçalho HTTP `Authorization`.
    As datas seguem o formato UTC ISO 8601 (`yyyy-MM-ddTHH:mm:ssZ`) e campos com
    máscara (CNPJ, telefone, CEP etc.) são retornados sem máscara. Endpoints de
    listagem paginados aceitam os parâmetros `start` e `limit`.
  contact:
    name: Suporte SULTS
    url: https://ajuda.sults.com.br
servers:
  - url: https://api.sults.com.br
    description: Produção
security:
  - apiKeyAuth: []
tags:
  - name: Unidades
    description: >-
      Unidades da rede e colaboradores ativos cadastrados no SULTS. Somente
      leitura: a API não grava unidades nem colaboradores. A API do SULTS é REST
      sobre HTTPS e responde em JSON. Cada requisição leva o token no cabeçalho
      `Authorization`, enviado puro, sem o prefixo `Bearer`. O token é gerado
      por um administrador na plataforma, em Segurança > API > Gestão de Tokens
      v1. O limite é de 2 requisições por segundo, por IP.
  - name: Chamados
    description: >-
      Chamados abertos na plataforma e a timeline de cada um, com os endpoints
      de criação e conclusão. A API do SULTS é REST sobre HTTPS e responde em
      JSON. Cada requisição leva o token no cabeçalho `Authorization`, enviado
      puro, sem o prefixo `Bearer`. O token é gerado por um administrador na
      plataforma, em Segurança > API > Gestão de Tokens v1. O limite é de 2
      requisições por segundo, por IP.
  - name: Checklist
    description: >-
      Avaliações de checklist aplicadas nas unidades, com respostas, check-ins,
      check-outs e planos de ação. A API do SULTS é REST sobre HTTPS e responde
      em JSON. Cada requisição leva o token no cabeçalho `Authorization`,
      enviado puro, sem o prefixo `Bearer`. O token é gerado por um
      administrador na plataforma, em Segurança > API > Gestão de Tokens v1. O
      limite é de 2 requisições por segundo, por IP.
  - name: Compras
    description: >-
      Pedidos de compra e catálogo de produtos da v1, incluindo o cadastro e a
      edição de produto e a edição de pedido. A v1 de Compras não recebe novas
      funcionalidades: mix de produtos, etapas de pedido e as próximas novidades
      do módulo estão só na API v2, que é a indicada para integrações novas de
      Compras. A API do SULTS é REST sobre HTTPS e responde em JSON. Cada
      requisição leva o token no cabeçalho `Authorization`, enviado puro, sem o
      prefixo `Bearer`. O token é gerado por um administrador na plataforma, em
      Segurança > API > Gestão de Tokens v1. O limite é de 2 requisições por
      segundo, por IP.
  - name: implantacao
    description: >-
      Projetos de implantação de novas unidades e as tarefas de cada projeto. A
      API do SULTS é REST sobre HTTPS e responde em JSON. Cada requisição leva o
      token no cabeçalho `Authorization`, enviado puro, sem o prefixo `Bearer`.
      O token é gerado por um administrador na plataforma, em Segurança > API >
      Gestão de Tokens v1. O limite é de 2 requisições por segundo, por IP.
    x-group: Implantação
  - name: Projetos
    description: >-
      Projetos da operação e as tarefas vinculadas a eles. A API do SULTS é REST
      sobre HTTPS e responde em JSON. Cada requisição leva o token no cabeçalho
      `Authorization`, enviado puro, sem o prefixo `Bearer`. O token é gerado
      por um administrador na plataforma, em Segurança > API > Gestão de Tokens
      v1. O limite é de 2 requisições por segundo, por IP.
  - name: expansao
    description: >-
      Negócios do funil de Expansão e a timeline de cada um, com o endpoint de
      criação de negócio. A API do SULTS é REST sobre HTTPS e responde em JSON.
      Cada requisição leva o token no cabeçalho `Authorization`, enviado puro,
      sem o prefixo `Bearer`. O token é gerado por um administrador na
      plataforma, em Segurança > API > Gestão de Tokens v1. O limite é de 2
      requisições por segundo, por IP.
    x-group: Expansão
paths:
  /api/v1/comercial/pedido/{pedidoId}:
    put:
      tags:
        - Compras
      summary: Editar pedido
      description: >-
        Cancela, reativa ou troca a situação de um pedido na plataforma do
        SULTS.
      operationId: editarPedido
      parameters:
        - name: pedidoId
          in: path
          required: true
          description: Id do pedido
          schema:
            type: integer
          example: 1025
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                cancelado:
                  type: boolean
                  description: >-
                    Se `true`, cancela o pedido; se `false`, reativa o pedido
                    cancelado.
                canceladoMotivo:
                  type: string
                  description: Descrição do motivo do cancelamento
                situacaoId:
                  type: integer
                  enum:
                    - 2
                    - 3
                    - 4
                    - 5
                  description: |-
                    Situação do pedido.

                    | Valor | Significado |
                    | ----- | ----------- |
                    | 2 | Aguardando |
                    | 3 | Faturado |
                    | 4 | Enviado |
                    | 5 | Entregue |
      responses:
        '200':
          description: >-
            Operação concluída com sucesso (status 200, sem corpo). Em caso de
            erro, são retornados detalhes sobre o erro.
        '400':
          $ref: '#/components/responses/ErroValidacao'
        '401':
          $ref: '#/components/responses/TokenInvalido'
        '404':
          $ref: '#/components/responses/NaoEncontrado'
        '429':
          $ref: '#/components/responses/LimiteDeRequisicoes'
        5XX:
          $ref: '#/components/responses/ErroDoServidor'
components:
  responses:
    ErroValidacao:
      description: >-
        Erro de validação ou formato errado nos dados de entrada. A API aponta
        **um campo por vez**: corrija o campo indicado na mensagem, reenvie e
        repita até o 200.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Erro'
          example:
            error: Campo responsavel não pode ser vazio ou nulo.
    TokenInvalido:
      description: >-
        Token ausente ou inválido. Confira: copiado por completo, cabeçalho
        `Authorization` com o nome exato, valor sem o prefixo `Bearer` e gerado
        na **Gestão de Tokens v1** (tokens v2 não funcionam nesta API). Sem
        retry automático. O corpo real é `{"error": "Acesso não autorizado."}`.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Erro'
          example:
            error: Acesso não autorizado.
    NaoEncontrado:
      description: >-
        Recurso ou entidade inexistente (por exemplo, um `{id}` do caminho que
        não existe ou foi excluído no SULTS). Reenviar sem corrigir devolve o
        mesmo erro.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Erro'
    LimiteDeRequisicoes:
      description: >-
        Limite de requisições excedido: **2 requisições por segundo, por IP**. A
        resposta é a página HTML padrão do servidor, não JSON, e não há o header
        `Retry-After`: trate pelo status 429, sem fazer parse do corpo, com
        espera crescente a partir de 1 segundo.
      content:
        text/html:
          schema:
            type: string
            description: >-
              Página HTML padrão do servidor. Não faça parse; decida pelo
              status.
    ErroDoServidor:
      description: >-
        Falha inesperada do servidor (raro). Repita com espera crescente;
        persistindo, acione o suporte com data, hora e endpoint.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Erro'
  schemas:
    Erro:
      type: object
      description: >-
        Corpo padrão de erro da API. Não existe código de erro interno: decida a
        sua lógica pelo status HTTP e use a mensagem apenas para logs e
        diagnóstico.
      required:
        - error
      properties:
        error:
          type: string
          description: >-
            Mensagem legível, em português, descrevendo a falha. O texto pode
            mudar: nunca o use como condição de código.
          example: Campo responsavel não pode ser vazio ou nulo.
  securitySchemes:
    apiKeyAuth:
      type: apiKey
      in: header
      name: Authorization
      description: >-
        Token  gerado através do sistema do SULTS. Deve ser enviado no cabeçalho
        `Authorization` de todas as requisições.

````

This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.