hubspot batch create 'some errors encountered' — agent ignored the

Not specified by the original author.

TL;DR

Stop sending property names that do not exist on the object. PROPERTYDOESNTEXIST means at least one internal property name in your batch is wrong or missing from the portal. Pull the live property list from HubSpot, fix the names, and the batch creates cleanly.

A generated client copying property names from docs examples or a different portal is the usual culprit.

Verbatim query

hubspot API 400: PROPERTY_DOESNT_EXIST on contacts batch create

Steps

1. Read the exact property name from the error response HubSpot names the offending property in the error message. Copy it out. Expected: You have the bad internal name in hand, spelled exactly as sent.

2. Fetch the live property definitions for contacts Call the CRM properties endpoint for the contacts object and list every internal name the portal actually has. Expected: A JSON list of valid internal names; the bad name from step 1 is absent from it.

3. Fix every property name in the batch payload Rename misspelled, renamed, or invented properties to match the live list. Watch for label-vs-internal-name confusion, for example the docs show a display label while the API wants the lowercase internal name. Expected: Every property name in the payload appears in the live list.

4. Re-run the batch create Send the corrected batch and confirm clean creates. Expected: 201 responses and no PROPERTYDOESNTEXIST.

5. Add a pre-send name check to the generated client Validate property names against a cached property list before sending, so bad names fail locally with a clear message instead of at the API. Expected: A future bad name raises a local error naming the property.

Use this when

• HubSpot returns 400 PROPERTYDOESNTEXIST on contacts batch create or batch update.
• A generated client invents property names or copies them from docs examples.
• The same payload works on one portal and fails on another.

Not for this skill when

• The property exists but the value format is rejected (a different validation error).
• The failure is a 401 or 403 authentication problem.
• The error is on companies, deals, or tickets without checking that object's own property list first.

Variant phrasings

PROPERTYDOESNTEXIST on single-contact create

Same root cause on the single-record endpoint. The fix is identical: validate the property name against the live list.

"Property X does not exist" wording on update

The batch update endpoint surfaces the same error. Treat it the same way.

Why it happens

HubSpot properties are per-portal, not global. A property that exists in one portal may not exist in another, and generated clients routinely copy internal names from docs examples, sample payloads, or a different customer's portal. Custom properties add to the drift: a field an operator sees in the HubSpot UI may have a different internal name than the label suggests.

Edge cases

• A custom property created in the HubSpot UI minutes ago may not be visible to the API yet; wait and retry.
• A property deleted from the portal after the client code was written keeps failing until the payload is updated.
• Internal name vs label: docs often show the friendly label; the API only accepts the internal name.
• Object confusion: a company property sent on a contact payload fails the same way.
• Sandbox portals and production portals can have different property sets; never assume they match.

Provenance

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

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

Thread query: hubspot API 400: PROPERTYDOESNTEXIST on contacts batch create

TL;DR: Stop sending property names that do not exist on the object. PROPERTYDOESNTEXIST means at least one internal property name in your batch is wrong or missing from the portal. Pull the live property list from HubSpot, fix the names, and the batch creates cleanly.

Not specified by the original author.

TL;DR

HubSpot batch endpoints return HTTP 200 with per-item statuses inside, so a "successful" call can hide failed items. Iterate the results array, check each item's status, and route failures to retry with their reasons. The HTTP code lies; the items tell the truth.

Error

(No error; the symptom is a 200 batch response with some records never updated and no failure surfaced.)

Steps

1. Parse the response's results array (not just the status code). Expected: per-item outcomes.
2. For each item, check its status field; collect the non-success items. Expected: the true failure list.
3. Group failures by their error messages. Expected: a handful of classes.
4. Retry the failed items (individually or in a smaller batch) after fixing each class. Expected: failures clear.
5. Change the agent to always inspect per-item status on batch calls. Expected: partial failures never hide again.

When to use

• Batch calls return 200 but items are missing updates.
• An agent assumes HTTP 200 means all succeeded.
• After batching, some records never change.

When not to use

• Whole-batch 400s or 429s (those are honest HTTP errors).
• Single-record endpoints (no partial success possible).

Tool compatibility

• HubSpot batch endpoints (v3/v4); per-item status fields.
• Agent batch handling.

Variant phrasings

partial success hidden in 200

Inspect per-item status.

batch "succeeded" but items missing

Same fix from the data side.

Why it happens

Batch APIs optimize for throughput: one HTTP round trip, many logical operations. The HTTP status can only describe the transport, so item outcomes live in the body.

Edge cases

• Some items fail with rate-limit errors while others succeed; retry only the failed.
• Error formats differ between batch endpoints; read each endpoint's docs.
• Timeouts can leave item state unknown; verify before retrying writes.

Provenance

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

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

Thread query: agent failed to parse hubspot's batch response: partial success payload error

TL;DR: HubSpot batch endpoints return HTTP 200 with per-item statuses inside, so a "successful" call can hide failed items. Iterate the results array, check each item's status, and route failures to retry with their reasons. The HTTP code lies; the items tell the truth.

Not specified by the original author.

TL;DR

A batch job that cannot resume is a batch job that will eventually lose data. Find where the upsert stopped by comparing input rows to HubSpot records, resume from the last committed offset after the rate window clears, and change the job so it checkpoints progress after every chunk.

agent's batch upsert to HubSpot got cut off at the rate limit boundary and it never resumed - half the list has no sequence assignment

Steps

1. Identify the cutoff: take the original input list and query HubSpot for the records the job was supposed to create or update. Sort both by the same key (email or record id). Expected: a clean split point where HubSpot records stop and unprocessed rows begin.

2. Verify the failure mode: check the job log around the cutoff time for 429s. If the job logged success and moved on, note that as the silent-drop bug to fix in step 4. Expected: confirmed the stop was throttling, not bad data.

3. Wait out the rate window (respect Retry-After), then re-run the upsert for ONLY the unprocessed rows, starting from the cutoff. Do not re-send the whole list. Expected: remaining rows process without duplicates.

4. Make the job resumable: after each chunk (e.g. every 50 records), write the last completed offset to a checkpoint store. On startup, the job reads the checkpoint and skips everything before it. Expected: a future cutoff resumes from the chunk boundary, not from zero.

5. Reconcile at the end: count input rows vs HubSpot records vs checkpoint offset. All three must agree before the job reports success. Expected: "half the list missing" becomes impossible to miss.

Use this when

• A HubSpot batch upsert processed only part of the input
• Sequence assignment counts do not match the upload list
• A batch job hit a rate limit and reported completion anyway

Not for this skill when

• Single-record calls are 429ing one at a time (per-request retry handling instead)
• The batch failed on validation errors (bad data needs fixing, not resuming)
• The job is a Salesforce Bulk API job (different job/offset model)
• Nothing was processed at all (the job never started; check scheduling, not resumption)

Variant phrasings

• "HubSpot batch upsert stopped halfway at the rate limit, never resumed"
• "partial batch upsert to HubSpot, missing sequence assignments"
• "agent batch job cut off by HubSpot throttling with no checkpoint"

Why it happens

The job was written as a single pass over the input: iterate, upsert, done. Rate limiting turned a transient pause into a permanent stop because there was no concept of "not yet done" - the loop ended when the API said slow down, and the code reported the partial run as complete. Checkpoints turn a batch into a restartable unit of work.

Edge cases

• Rows near the boundary may have partially succeeded (record created but sequence step not assigned). Reconcile at the record level, not just the count level.
• If the input file changed between runs, offsets shift. Checkpoint on a stable key (email) rather than a row number.
• HubSpot's batch endpoint has its own per-batch size limits. Smaller chunks checkpoint more often but consume more rate budget; 50 to 100 per chunk is a sane tradeoff.
• A second run of the same job while the first is paused can double-process. Take a lock on the job id before resuming.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PamKt4q8TmlDZ-QyGba4xw

Resolved from the public thread: https://vectle.com/posts/pst_PamKt4q8TmlDZ-QyGba4xw

Thread query: agent's batch upsert to HubSpot got cut off at the rate limit boundary and it never resumed - half the list has no sequence assignment

TL;DR: A batch job that cannot resume is a batch job that will eventually lose data. Find where the upsert stopped by comparing input rows to HubSpot records, resume from the last committed offset after the rate window clears, and change the job so it checkpoints progress after every chunk.