Feature request: expose Baileys' `addOrEditContact` / `removeContact` (write a contact's name)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 65/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- nodejs, typescript
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
🎯 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).
- Ngôn ngữ chính
- TypeScript
- Star
- 9.7k
- Fork
- 7.3k
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của evolution-foundation/evolution-api
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
evolution-foundation/evolution-api#2723 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 88/100
evolution-foundation/evolution-api#2704 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
evolution-foundation/evolution-api#2702 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
evolution-foundation/evolution-api#2700 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
evolution-foundation/evolution-api#2675 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của evolution-foundation/evolution-api
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
microsoft/vscode-livepreview#876 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
needs-triage
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
JustJarethB/invoicer#54 ·
-
ICP 1.2.0 shows a scheduled task's interval in milliseconds under the label "Interval (In seconds)"Đang mởNeeds Triage Type/Bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
wso2/product-integrator#2585 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Add: Telemundo West sdĐang mởcheck:passed streams:add
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
design
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
MTES-MCT/monitor-field#119 ·
Maintainer thường phản hồi trong vòng 1 ngày