-
Notifications
You must be signed in to change notification settings - Fork 52
Description
🐛 Describe the Bug
The additionalEmails field is fully supported in the GHL UI (up to 10 additional emails per contact) and is returned in API responses (GET contact, search contacts), but it is not accepted as a writable field in any of the following endpoints:
POST /contacts/(Create Contact)PUT /contacts/:id(Update Contact)POST /contacts/upsert(Upsert Contact)
📍 API Endpoint
/contacts/upsert
✅ Expected Behavior
additionalEmails should be accepted as a writable field in create/update/upsert endpoints, consistent with how it is already exposed in read endpoints.
💻 Screenshots or Code Samples
Attempting to pass additionalEmails in the request body returns:
{
"message": ["property additionalEmails should not exist"],
"error": "Unprocessable Entity",
"statusCode": 422
}Product Area
API
📋 Use Case
We are building a direct integration between our system and GHL. Contacts in our system can accumulate multiple email addresses over time (e.g. same phone number, different email on each application). We need to sync these additional emails to GHL to preserve the full email history of a contact, which is exactly what the additionalEmails feature was designed for.
🚨 Why Should This Be Prioritized?
The additionalEmails feature already exists in GHL, it works in the UI, it's returned in API responses, but it cannot be written via the API. This is an inconsistency between what the platform supports and what the API exposes, which forces developers to implement dirty workarounds (eg.: custom text fields) that degrade data quality and defeat the purpose of the feature entirely.
This is not a new feature request: the underlying capability already exists. This is simply exposing existing functionality to the API, which should be a low-effort, high-impact change.
Any developer building a serious CRM integration will eventually hit this wall. Contacts accumulate multiple emails over time, and without write support, there is no clean way to sync this data programmatically. This directly impacts the reliability and completeness of data for any team using GHL as their primary CRM alongside an external system.
🧠 Additional Context
No response