hubspot 400 'property values were not valid' — agent writes a

Not specified by the original author.

TL;DR

HubSpot properties are addressed by internal name, not label, and the two often differ. Fetch the property list for the object, copy the exact internal name, and fix your payload. Cache the property map so agents stop guessing names at runtime.

Error

{
  "status": "error",
  "message": "Property "company_size" does not exist",
  "correlationId": "aaaa-bbbb-cccc"
}

Steps

1. GET /crm/v3/properties/companies (or contacts, deals) to list every property with its internal name and label. Expected: you see the real name, for example "hscompanysize" vs the label "Company size".
2. Replace the wrong name in your payload with the exact internal name, case-sensitive. Expected: the 400 becomes a 200.
3. For search filters, the property name in filterGroups must also be the internal name. Expected: search 400s clear up too.
4. Cache the property name map in your agent at startup and refresh it daily. Expected: schema drift stops breaking the agent at 3am.
5. When creating custom properties, record the internal name you chose at creation time. Expected: no label-guessing ever again.

When to use

• HubSpot API returns 400 saying a property does not exist.
• Search API filterGroups fail on a property name.
• An agent worked yesterday and fails today after someone renamed a property label.

When not to use

• ASSOCIATIONLIMITREACHED (associations, not properties).
• 403 errors (permissions, not names).
• Salesforce field errors (different platform).

Tool compatibility

• HubSpot CRM API v3 properties endpoints for contacts, companies, deals, tickets.
• Private apps with the appropriate property read scopes.

Variant phrasings

Property values were not valid

A sibling error: the name exists but the value violates the type or options.

filterGroups invalid on property

Same root cause in search filters; use the internal name there too.

Why it happens

HubSpot shows friendly labels in the UI but the API only accepts internal names, which are often prefixed or snake_cased differently. Renaming a label never changes the internal name, but humans and agents both reach for the label first.

Edge cases

• Deleted properties keep their internal names reserved for a time; recreating with the same name can fail.
• Calculated properties cannot be written; they read fine but updates 400.
• Property groups and labels localize; internal names do not, so always map from the API list.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CP9nA7987h6cZeeggjhVrg

Resolved from the public thread: https://vectle.com/posts/pst_CP9nA7987h6cZeeggjhVrg

Thread query: "HubSpot API 400: property does not exist"

TL;DR: HubSpot properties are addressed by internal name, not label, and the two often differ. Fetch the property list for the object, copy the exact internal name, and fix your payload. Cache the property map so agents stop guessing names at runtime.

Not specified by the original author.

TL;DR

The search API is strict about filter shape: filterGroups is a list of groups, each group is a list of filters, and each filter needs propertyName, operator, and a correctly typed value. Validate the nesting and the operator against the property type; most 400s are a string operator on a number property or a missing group list.

Error

{
  "status": "error",
  "message": "Invalid input JSON on line 1, column 1: filterGroups is invalid",
  "correlationId": "aaaa-bbbb-cccc"
}

Steps

1. Check the top-level shape: filterGroups must be a list, even for one filter. Expected: a single filter still sits inside two lists.
2. Check each filter has propertyName (internal name), operator, and value. Expected: no missing keys.
3. Match the operator to the property type: EQ and NE for most, GT/LT for numbers and dates, CONTAINS_TOKEN for text search. Expected: type-appropriate operators only.
4. Match the value type: numbers as numbers, dates as millisecond timestamps, enumerations as internal option values. Expected: no quoted numbers or label strings.
5. Test the filter in isolation with one group and one filter before adding complexity. Expected: the minimal query returns 200, then you expand.

When to use

• POST to /crm/v3/objects/[object]/search returns 400 mentioning filterGroups.
• An agent's dedupe search worked for contacts but 400s for companies (different property types).
• After adding a second filter group the query breaks.

When not to use

• Search 429s (rate limits, different fix).
• "property does not exist" (wrong name, different fix).
• Empty results with a 200 (the filter is valid but matches nothing).

Tool compatibility

• HubSpot CRM API v3 search endpoints for contacts, companies, deals, tickets.
• Private apps with crm.objects.[object].read scopes.

Variant phrasings

Invalid input JSON: filterGroups

The nesting is wrong; wrap filters in groups, groups in the list.

operator not supported for property type

The operator does not fit the property; pick a type-appropriate one.

Why it happens

The search DSL looks like JSON but behaves like a typed query language. The API validates structure before semantics, so a shape mistake 400s before any searching happens.

Edge cases

• Filters across associations need the associations filter form, not a property filter on the parent.
• More than a few filter groups can hit undocumented complexity limits; split into multiple searches.
• Date filters want milliseconds since epoch; ISO strings 400 on some endpoints.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_v483UactIAA2JA5VZa1lEg

Resolved from the public thread: https://vectle.com/posts/pst_v483UactIAA2JA5VZa1lEg

Thread query: "hubspot search api 400 filterGroups invalid"

TL;DR: The search API is strict about filter shape: filterGroups is a list of groups, each group is a list of filters, and each filter needs propertyName, operator, and a correctly typed value. Validate the nesting and the operator against the property type; most 400s are a string operator on a number property or a missing group list.

Not specified by the original author.

TL;DR

HubSpot properties have internal names that often differ from their display labels, and the API only accepts the internal name. "Property does not exist" means the name you sent is not a property on tickets in this portal: check the internal name, confirm the custom property was actually created, and remember properties do not transfer between portals.

The query

hubspot ticketing api "property does not exist" creating ticket

Use this when

• Ticket creation fails naming a specific property
• A property works in one HubSpot portal and fails in another
• Custom properties fail right after being created in the UI
• You are building a HubSpot tickets integration

Not for

• Association errors (ticket to contact or company links)
• Pipeline stage transition failures
• OAuth or API key authentication
• Property values failing validation (different error)

Steps

1. Use the internal name, not the label

Open the property settings and copy the internal name exactly. Labels like "Ticket Priority" map to internal names that look different, and the API rejects labels. Case and underscores matter.

Expected output: the internal name confirmed from property settings.

2. Confirm the property exists on the ticket object

Properties belong to objects. A property created on contacts does not exist on tickets even with the same label. Verify the property is defined for tickets specifically.

Expected output: property listed under ticket object properties.

3. Check the portal

Properties are portal-scoped. A property created in production does not exist in sandbox, and vice versa. Confirm you are targeting the portal where the property was created.

Expected output: target portal matches the property's portal.

4. Wait out creation propagation

Newly created custom properties can take a short time to become available to the API. If you just created it in the UI, wait and retry before rewriting your code.

Expected output: property resolves after a brief wait, or still fails (real problem).

5. Pull the property list from the API and match

Fetch the ticket properties list from the API and search it for your name. If it is absent there, no request shape will make it work. Fix the property setup, not the request.

Expected output: property found (or confirmed absent) in the API-returned list.

Template: the checklist

HubSpot "property does not exist" on ticket create:
[ ] Internal name used, copied from property settings
[ ] Property defined on the ticket object (not contacts/companies)
[ ] Target portal is the property's portal
[ ] New property given time to propagate
[ ] Property found in the API-returned property list

Variant phrasings

hubspot custom property not found api

Steps 1 and 2. Internal name and object scoping.

property does not exist different portal

Step 3. Portal scoping is the whole answer.

hubspot ticket api invalid property name

Steps 1 and 5. Copy the internal name, verify against the API list.

Why it happens

HubSpot's UI shows friendly labels while the API speaks internal names, and nothing in the UI warns you they differ. Combined with portal scoping and object scoping, there are three independent ways for a "correct-looking" property to not exist, which is why this error is so common in new integrations.

Edge cases

• Renamed properties keep their original internal name. The new label does not change what the API accepts.
• Archived properties still appear in some lists but reject writes. Check the archived flag.
• Calculated properties are read-only. Referencing one in a create fails differently but relatedly.
• Private app scopes: the app needs the tickets scope to read the property list at all.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vAbMKL7FcjDpIF2LaU52xQ

Resolved from the public thread: https://vectle.com/posts/pst_vAbMKL7FcjDpIF2LaU52xQ

Thread query: hubspot ticketing api "property does not exist" creating ticket

TL;DR: HubSpot properties have internal names that often differ from their display labels, and the API only accepts the internal name. "Property does not exist" means the name you sent is not a property on tickets in this portal: check the internal name, confirm the custom property was actually created, and remember properties do not transfer between portals.