[NOWEB] [GOWS] - ⚠️ Inconsistent API Response Structures Across Engines and Versions — No Versioning, No Notice

[yusoft-app]

I’ve tested multiple WAHA versions and engines in production and noticed a very concerning inconsistency in API response formats — even for the same endpoint.

It seems like the response structure changes across both versions and engines, and this happens without any versioning, documentation, or announcement.

---

🔍 Summary of findings

• Engine: NOWEB

  • Versions 2025.9.4 and below → API response structure A

  • Versions 2025.9.5 to 2025.9.7 → API response structure B (similar to GOWS engine)

  • Versions 2025.9.8 and 2025.10.1 → API response structure reverted to structure A

    • However, /api/sendImage is still broken with Media upload failed on all hosts

• Engine: GOWS

  • Tested on version 2025.10.1 → /api/sendText and /api/sendImage both work correctly,
    but the response format is completely different from the NOWEB engine response.

---

❗ The problem

This inconsistency means that the same API endpoints (such as /api/sendText, /api/sendImage) return different JSON response structures depending on the engine or version — which is unacceptable for production-grade systems.

Applications integrating with WAHA (CRM, ERP, bots, or automation services) rely heavily on a consistent response structure.
Changing it silently breaks those integrations and causes widespread failures in production.

So the questions are:

1. Is the API response intentionally different between engines (NOWEB vs GOWS)?

2. Or is this inconsistency simply a result of missing Quality Control (QC) before release?

If this change was intentional, it should have been announced clearly and tied to an API version (e.g., /api/v2/...).
If it wasn’t intentional, then this represents a serious lack of internal QA/QC that makes WAHA feel unreliable for developers using it in production environments.

---

⚙️ Example evidence

Below is a comparison from my testing (simplified):

Version	Engine	/api/sendText	/api/sendImage	Response structure	Status
2025.9.3	NOWEB	✅ Works	✅ Works	Old format (A)	Stable
2025.9.4	NOWEB	✅ Works	✅ Works	Old format (A)	Stable
2025.9.5–2025.9.7	NOWEB	✅ Works	⚠️ Sends 3x duplicate messages	Changed to new format (B, similar to GOWS)	Unstable
2025.9.8	NOWEB	✅ Works	❌ Fails (Media upload failed on all hosts)	Reverted to old format (A)	Broken
2025.10.1	NOWEB	✅ Works	❌ Fails (Media upload failed on all hosts)	Old format (A)	Broken
2025.10.1	GOWS	✅ Works	✅ Works	New format (B)	Stable

---

🧩 Example of difference

NOWEB (2025.10.1)

{
  "statusCode": 200,
  "id": "true_447000000000@c.us_xxx",
  "message": "Message sent successfully"
}

GOWS (2025.10.1)

{
  "id": "true_447000000000@c.us_xxx",
  "_data": {
    "Info": { "Chat": "447000000000@s.whatsapp.net", "IsFromMe": true, ... },
    "Message": { "imageMessage": { "caption": "example" } }
  }
}

Same API endpoint, completely different JSON layout.

---

🧭 What should happen

WAHA must define and maintain consistent, versioned API responses — regardless of internal engine or implementation.
If the structure differs per engine, it must be clearly documented and versioned.

These silent structural changes without versioning or communication are highly unprofessional, especially for a system used in production with many business-critical integrations.

---

📝 Requests for the WAHA team

1. Please confirm which API response format is the correct and official one (A or B).

2. Clarify whether response differences between NOWEB and GOWS are intentional or due to lack of standardization.

3. Consider introducing API versioning (/api/v1, /api/v2, etc.) or at least documenting response structure differences per engine.

4. Re-test and ensure that /api/sendImage works properly in NOWEB engine (currently broken since 2025.9.8).

---

Consistency is a fundamental part of professional API design.
Right now, these unpredictable response changes — without versioning or notice — make it extremely difficult to maintain stable integrations with WAHA.

[github-actions]

Portuguese

---

Title: [NOWEB] [GOWS] - ⚠️ Estruturas de resposta de API inconsistentes entre mecanismos e versões — sem controle de versão, sem aviso prévio

Testei diversas versões e mecanismos WAHA em produção e notei uma inconsistência muito preocupante nos formatos de resposta da API, mesmo para o mesmo endpoint.

Parece que a estrutura de resposta muda nas versões e nos mecanismos, e isso acontece sem qualquer controle de versão, documentação ou anúncio.

🔍 Resumo das descobertas

• Motor: NOWEB

  • Versões 2025.9.4 e anteriores → Estrutura de resposta da API A

  • Versões 2025.9.5 a 2025.9.7 → Estrutura de resposta da API B (semelhante ao mecanismo GOWS)

  • Versões 2025.9.8 e 2025.10.1 → Estrutura de resposta da API revertida para estrutura A

    • No entanto, /api/sendImage ainda está quebrado com falha no upload de mídia em todos os hosts

• Motor: GOWS

  • Testado na versão 2025.10.1 → /api/sendText e /api/sendImage funcionam corretamente,
    mas o formato de resposta é completamente diferente da resposta do mecanismo NOWEB.

❗ O problema

Essa inconsistência significa que os mesmos endpoints de API (como /api/sendText, /api/sendImage) retornam estruturas de resposta JSON diferentes dependendo do mecanismo ou da versão, o que é inaceitável para sistemas de nível de produção.

Aplicativos integrados ao WAHA (CRM, ERP, bots ou serviços de automação) dependem fortemente de uma estrutura de resposta consistente.
Alterá-lo quebra silenciosamente essas integrações e causa falhas generalizadas na produção.

Então as perguntas são:

1. A resposta da API é intencionalmente diferente entre os mecanismos (NOWEB vs GOWS)?

2. Ou essa inconsistência é simplesmente resultado da falta do Controle de Qualidade (CQ) antes do lançamento?

Se essa mudança foi intencional, ela deveria ter sido anunciada claramente e vinculada a uma versão da API (por exemplo, /api/v2/...).
Se não foi intencional, isso representa uma grave falta de controle de qualidade/controle de qualidade interno que faz com que o WAHA pareça pouco confiável para os desenvolvedores que o utilizam em ambientes de produção.

⚙️ Exemplo de evidência

Abaixo está uma comparação dos meus testes (simplificado):

Versão	Motor	/api/sendText	/api/sendImage	Estrutura de resposta	Status
2025.9.3	AGORA	✅ Obras	✅ Obras	Formato antigo (A)	Estável
2025.9.4	AGORA	✅ Obras	✅ Obras	Formato antigo (A)	Estável
2025.9.5–2025.9.7	AGORA	✅ Obras	⚠️ Envia mensagens duplicadas 3x	Alterado para novo formato (B, semelhante ao GOWS)	Instável
2025.9.8	AGORA	✅ Obras	❌ Falha (falha no upload de mídia em todos os hosts)	Revertido para formato antigo (A)	Quebrado
2025.10.1	AGORA	✅ Obras	❌ Falha (falha no upload de mídia em todos os hosts)	Formato antigo (A)	Quebrado
2025.10.1	GOWS	✅ Obras	✅ Obras	Novo formato (B)	Estável

🧩 Exemplo de diferença

NOWEB (2025.10.1)

{
  "statusCode": 200,
  "id": "true_447000000000@c.us_xxx",
  "mensagem": "Mensagem enviada com sucesso"
}

GOWS (2025.10.1)

{
  "id": "true_447000000000@c.us_xxx",
  "_dados": {
    "Info": { "Bate-papo": "447000000000@s.whatsapp.net", "IsFromMe": verdadeiro, ... },
    "Mensagem": { "imageMessage": { "caption": "exemplo" } }
  }
}

Mesmo endpoint de API, layout JSON completamente diferente.

🧭 O que deveria acontecer

A WAHA deve definir e manter respostas de API versionadas e consistentes, independentemente do mecanismo interno ou da implementação.
Se a estrutura for diferente por mecanismo, ela deverá ser claramente documentada e versionada.

Essas mudanças estruturais silenciosas, sem controle de versão ou comunicação, são altamente pouco profissionais, especialmente para um sistema usado na produção com muitas integrações críticas para os negócios.

📝 Pedidos para a equipe WAHA

1. Por favor confirme qual formato de resposta da API é o correto e oficial (A ou B).

2. Esclareça se as diferenças de resposta entre NOWEB e GOWS são intencionais ou devido à falta de padronização.

3. Considere introduzir o controle de versão da API (/api/v1, /api/v2 etc.) ou pelo menos documentar as diferenças na estrutura de resposta por mecanismo.

4. Teste novamente e certifique-se de que /api/sendImage funciona corretamente no mecanismo NOWEB (atualmente quebrado desde 2025.9.8).

A consistência é uma parte fundamental do design profissional de APIs.
No momento, essas mudanças de resposta imprevisíveis — sem controle de versão ou aviso prévio — tornam extremamente difícil manter integrações estáveis ​​com WAHA.