Updating company email domains with a value that includes a host portion silently strips that host portion

Product
,
1

For example:
Submitting this (mock) request+payload:

PUT /api/v2/companies/00000000000/
{
  "domains": ["www.example.com"]
}

…receives a 200 response, while the email domain that was actually saved to the company profile is in fact example.com. What’s especially egregiously bad is the response body from this operation uses the original as-submitted domain value in the company representation - ie, from the above call, this is the (mocked) response returned:

{
    "id": 00000000000,
    "name": "Example Company",
    "description": "",
    "note": null,
    "domains": [
        "www.example.com"
    ],
    "custom_fields": {
        "unique_external_id": "123456789"
    },
    "created_at": "2025-05-21T20:56:33Z",
    "updated_at": "2025-05-21T20:56:33Z",
    "health_score": null,
    "account_tier": null,
    "renewal_date": null,
    "industry": null
}

…but the actual company record looks like this now:

GET /api/v2/companies/00000000000/
{
    "id": 00000000000,
    "name": "Example Company",
    "description": "",
    "note": null,
    "domains": [
        "example.com"
    ],
    "custom_fields": {
        "unique_external_id": "123456789"
    },
    "created_at": "2025-05-21T20:56:33Z",
    "updated_at": "2025-05-21T20:56:33Z",
    "health_score": null,
    "account_tier": null,
    "renewal_date": null,
    "industry": null
}

I agree with the underlying behavior: the values in question should only be domains, but at a minimum the API documentation should note this behavior and in particular that it is applied silently.

What makes the current implementation especially egregiously frustrating is that the 200 response body itself from this operation includes the original submitted domain in the company representation - which is just plain wrong and should be fixed.

1 Like