Skip to content

[Bug Report: API Field Missing] Support writing additionalEmails via Contacts API (create/update/upsert) #262

@jacobpap

Description

@jacobpap

🐛 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions