Docs: quoted reply (`quoted` field on /send/*) is functional but undocumented + reminder about #28 reactions

[VictorNascimento14]

Summary

The quoted field on POST /send/text (and likely on all /send/* endpoints) is fully functional but completely undocumented in the public docs and in the Context7/llms indexes. I discovered the correct payload format only after extracting the Swagger definition from the running container itself (GET /swagger/doc.json).

This issue reports the documentation gap for quoted replies AND emphasizes that the related POST /message/react bug (issue #28) is still blocking reaction synchronization with WhatsApp. Context: I built a production CRM integration on top of Evolution Go, and both features share a common theme — the docs don't match the server.

---

Part 1 — Quoted Reply (quoted field) is undocumented

Where the docs point today

Public docs at docs.evolutionfoundation.com.br/evolution-go/* and the Context7-indexed README list POST /send/text with only these fields:

{
  "number": "string",
  "text": "string",
  "delay": 0
}

No mention of quoted, mentionAll, mentionedJid, or id.

What the server actually exposes

The live Swagger spec, served at http://localhost:4000/swagger/doc.json, contains the full TextStruct:

{
  "$ref": "#/definitions/github_com_Zapbox-API_evolution-go_pkg_sendMessage_service.TextStruct",
  "type": "object",
  "properties": {
    "delay":        { "type": "integer" },
    "id":           { "type": "string" },
    "mentionAll":   { "type": "boolean" },
    "mentionedJid": { "type": "string" },
    "number":       { "type": "string" },
    "quoted":       { "$ref": "#/definitions/...QuotedStruct" },
    "text":         { "type": "string" }
  }
}

And QuotedStruct:

{
  "type": "object",
  "properties": {
    "messageId":   { "type": "string" },
    "participant": { "type": "string" }
  }
}

Working payload (tested on v0.7.0)

curl -X POST http://localhost:4000/send/text \
  -H "Content-Type: application/json" \
  -H "apikey: <instance_token>" \
  -d '{
    "number": "5511999999999",
    "text": "replying to your message",
    "quoted": {
      "messageId": "3AC274851C9DFE69A18D",
      "participant": "5511999999999@s.whatsapp.net"
    }
  }'

Confirmed behavior (end-to-end)

Response:

{
  "data": {
    "Message": {
      "extendedTextMessage": {
        "text": "replying to your message",
        "contextInfo": {
          "stanzaID": "3AC274851C9DFE69A18D",
          "participant": "5511999999999@s.whatsapp.net",
          "quotedMessage": { "conversation": "" }
        }
      }
    }
  },
  "message": "success"
}

Message arrives on the recipient's WhatsApp with the quote card visible above the reply text, exactly as expected. Works reliably, ~700ms end-to-end, no usync hang.

What I had to discover by trial and error

Before finding the Swagger spec, I tried several wrong formats based on Node/Baileys conventions (see also #28):

Format tried	Result
{ "key": { "remoteJid", "fromMe", "id" }, "message": { "conversation" } } (Baileys-style)	200 response, but quote not attached — silently ignored
{ "quotedMessage": {...} }	200, quote not attached
No quoted field at all	200, quote not attached

Only { "quoted": { "messageId", "participant" } } works. This is non-obvious because the webhook payload the server emits uses the contextInfo.stanzaID / quotedMessage structure (Baileys-compatible), so users naturally assume the inbound payload should mirror the outbound format.

Additional undocumented behavior — stanzaID casing in webhooks

Related: the webhook payload for incoming quoted replies uses stanzaID (PascalCase ID) while Node/Baileys and most docs/examples show stanzaId (camelCase). This caused my webhook ingest to silently miss all incoming quote metadata until I added a dual-case guard:

const stanzaId = contextInfo?.stanzaId ?? contextInfo?.stanzaID;
const participant = contextInfo.participant ?? contextInfo.Participant;
const quotedMsg = contextInfo.quotedMessage ?? contextInfo.QuotedMessage;

If this casing is intentional (Go proto serialization), a note in the webhook docs would save developers hours.

Suggested documentation changes

1. Add quoted, id, mentionAll, mentionedJid, delay to every /send/* endpoint reference.
2. Add a dedicated "Quoted Reply" section with:
   • The exact QuotedStruct schema
   • How to resolve participant (JID of the original message's author, with @s.whatsapp.net suffix)
   • Note that the quoted outbound format is not the same shape as the webhook contextInfo inbound format
3. Document the stanzaID casing in incoming webhooks.
4. Expose the /swagger/doc.json endpoint publicly in the README as the authoritative reference.

Once I had these three pieces of info, the feature was trivial to implement. Without them, it's effectively hidden.

---

Part 2 — Reactions still broken (reminder of #28)

While we're on the topic: POST /message/react continues to hang for 75 seconds and return HTTP 500 on v0.7.0 (stable). Details and full logs are in #28.

TL;DR from that issue:

• The payload format is correct per the server's own Swagger (ReactStruct = { id, number, reaction })
• sendIQ with namespace=usync is sent, never receives a response, times out at 75s
• Same instance, same contact, same minute, /send/text with the quoted reply above (which also uses usync) returns in ~200ms ✅
• So the issue is specific to the React handler's usync query construction, not to usync in general

My CRM stores reactions locally in its own DB and attempts Evolution delivery as best-effort — meaning the app UX already works for both users on my side. But to propagate reactions back to the recipient's WhatsApp (which is the whole point), I depend on /message/react getting fixed.

If there's a PR fix in flight for #28 I'd be happy to beta-test it against a production instance.

---

Environment

• Evolution Go v0.7.0 (stable, image evoapicloud/evolution-go:0.7.0)
• Docker Compose + Traefik
• AlmaLinux 9 VPS
• whatsmeow lib as shipped with 0.7.0
• Connected production WhatsApp instance with active LID migration visible in logs

Happy to provide full logs, Swagger dumps, or reproducers for either part.