Feature request: expose Baileys' `addOrEditContact` / `removeContact` (write a contact's name)
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 65/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- nodejs, typescript
Direzione di ricerca
The issue is about adding contact write endpoints to the Evolution API. Start by examining the existing chat router in src/api/routes/chat.router.ts and the Baileys service in whatsapp.baileys.service.ts. The implementation involves creating a DTO in src/api/dto/chat.dto.ts, adding new POST routes for updateContact and removeContact, and calling the underlying Baileys methods addOrEditContact and removeContact. Ensure the local database (Prisma) and webhooks are updated. Test by verifying the new endpoints work and sync names correctly.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
🎯 Problem Statement
There is no endpoint to WRITE a contact. POST /chat/findContacts/{instance} reads them, and POST /chat/updateProfileName/{instance} changes the connected account's OWN profile name — neither can set the name of another contact.
Checked on our instance (Baileys connection): POST to /chat/updateContact/{instance}, /chat/upsertContact/{instance}, /chat/updateContactName/{instance} and /chat/saveContact/{instance} all return 404. The route list in src/api/routes/chat.router.ts on main confirms it: 23 routes, none of them a contact write. (The "Update Contact" endpoint in the docs belongs to the EvoAI CRM service, a different product that does not touch the WhatsApp instance.)
The result is that any CRM or inbox built on Evolution has a one-way name: the address book and push names flow from the device into the application (CONTACTS_UPSERT / CONTACTS_UPDATE), but a name corrected inside the application can never reach the user's own WhatsApp.
This is not a limitation of WhatsApp. WhatsApp Web renames a contact without touching the phone's address book, because WhatsApp keeps a server-side contact list per account that syncs to every linked device.
💡 Proposed Solution
Expose what Baileys already implements in src/Socket/chats.ts:
const addOrEditContact = (jid, contact) => chatModify({ contact }, jid)
const removeContact = (jid) => chatModify({ contact: null }, jid)
It is an app-state patch (contactAction), so it propagates to all linked devices. The proto message is:
message ContactAction {
optional string fullName = 1;
optional string firstName = 2;
optional string lidJid = 3;
optional bool saveOnPrimaryAddressbook = 4;
optional string pnJid = 5;
optional string username = 6;
}
Note saveOnPrimaryAddressbook: the protocol itself distinguishes "save in WhatsApp's own contact list" from "save in the device's address book".
Suggested API:
POST /chat/updateContact/{instance}
{
"number": "5546999103009",
"fullName": "Ricardo Cavalcante | Ortopedista",
"firstName": "Ricardo",
"saveOnPrimaryAddressbook": false
}
POST /chat/removeContact/{instance}
{ "number": "5546999103009" }
Implementation sketch:
- src/api/dto/chat.dto.ts — UpdateContactDto { number?, remoteJid?, fullName, firstName?, saveOnPrimaryAddressbook? }
- src/api/routes/chat.router.ts — router.post('/updateContact') (+ removeContact), with the usual routerPath / dataValidate / schema pair.
- whatsapp.baileys.service.ts:
public async updateContact(data: UpdateContactDto) {
const jid = createJid(data.number ?? data.remoteJid)
await this.client.addOrEditContact(jid, {
fullName: data.fullName,
firstName: data.firstName ?? data.fullName,
saveOnPrimaryAddressbook: data.saveOnPrimaryAddressbook ?? false,
})
// keep the local cache consistent, otherwise findContacts keeps returning the old name
await this.prismaRepository.contact.updateMany({
where: { instanceId: this.instanceId, remoteJid: jid },
data: { pushName: data.fullName },
})
this.sendDataWebhook(Events.CONTACTS_UPDATE, [{ remoteJid: jid, pushName: data.fullName }])
return { update: 'success' }
}
- whatsapp.business.service.ts (Cloud API) — throw BadRequestException: the official API has no contact list, so this is Baileys-only by nature.
Edge cases:
- Groups are out of scope: renaming a group is updateGroupSubject, which changes the subject for every participant.
- removeContact is destructive (it clears the name on the user's own devices), so it should be a separate endpoint and never an empty fullName falling through updateContact.
- Idempotent: sending the same name twice is a no-op patch.
Happy to open a PR if this shape looks right to you.
🔄 Alternatives Considered
- Probing for an undocumented route: the four plausible names return 404, and the router source confirms none exists.
- Keeping the name local only (what we ship today), with the UI stating explicitly that it does not reach the phone. It works, but it leaves the two sides permanently out of sync.
- The EvoAI CRM "Update Contact" endpoints: different product, edits CRM records, does not touch the WhatsApp instance.
- Running a patched fork of Evolution with this route: doable, but it means maintaining a custom image for one contact name.
📊 Priority
Low - Nice to have
🧩 Component
None
🎯 Use Case
We run an internal CRM/inbox on Evolution: our team answers WhatsApp from inside our own application, with the same number they use on their phones. People arrive from Click-to-WhatsApp ads with no name in the address book, and whoever answers types the real one ("Ricardo Cavalcante | Ortopedista").
Today that name lives only in our database. The same person on the operator's phone is still a bare number, so the phone and the application disagree about who the conversation belongs to — and the correction has to be made twice, by hand, in two places.
Our user put it plainly: "WhatsApp Web doesn't write to anyone's address book, and it renames contacts." She is right, and we had to tell her the bridge we use cannot do it.
📝 Additional Context
Evolution API v2.x, Baileys connection type, self-hosted (Docker).
- Lingua principale
- TypeScript
- Stelle
- 9.6k
- Fork
- 7.3k
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di evolution-foundation/evolution-api
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
evolution-foundation/evolution-api#2723 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100
evolution-foundation/evolution-api#2704 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
evolution-foundation/evolution-api#2702 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
evolution-foundation/evolution-api#2700 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
evolution-foundation/evolution-api#2675 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di evolution-foundation/evolution-api
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
opengovsg/FormSG#10118 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
ai-driven-qa bug claude
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
linagora/twake-calendar-frontend#1434 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Add: MBC kr [Geo-blocked]Apertacheck:passed streams:add
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
iptv-org/iptv#52824 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 Mezza giornata Idoneità per principianti 78/100
jaegertracing/jaeger-ui#4512 ·
I maintainer di solito rispondono entro 1 giorno
-
area:ide documentation enhancement platform:macos platform:vscode
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100
anthropics/claude-code#97389 ·
I maintainer di solito rispondono entro 1 giorno