intercom "attribute type mismatch" syncing custom objects

TL;DR

"Attribute type mismatch" means the value you sent does not match the type Intercom registered for that attribute: a string where it expects a number, a boolean where it expects a string. Align the schema first: read the registered types, coerce values at the sync boundary, and reject uncoercible values with a clear log instead of crashing the sync. Type discipline at the boundary fixes the whole class.

The query

intercom "attribute type mismatch" syncing custom objects

Use this when

• Attribute syncs fail with type mismatch errors
• Custom object syncs partially fail
• Values arrive as the wrong type from source systems
• You are building Intercom data pipelines

Not for

• Designing the attribute data model
• Intercom custom reports
• Naming conventions for attributes
• Contact versus company modeling

Steps

1. Read the registered attribute types from Intercom

List the custom attributes and their types as Intercom knows them. The sync must conform to the registered schema, not to what the source system calls the field. The registry is the contract.

Expected output: a local copy of the registered attribute schema.

2. Coerce values at the sync boundary

Convert source values to the registered type before sending: parse numeric strings to numbers, normalize booleans, stringify where strings are expected. One coercion layer, applied to every value, every sync.

Expected output: all outbound values matching registered types.

3. Quarantine uncoercible values with logging

When a value cannot be coerced (a name where a number is required), skip that attribute, log the record and value, and continue the sync. One bad value must not fail a thousand good records.

Expected output: bad values quarantined, syncs completing.

4. Lock attribute types after first write

Intercom types the attribute on first use; changing it later is painful. Treat the first write as schema creation: review types deliberately before the initial sync, because the registry remembers your first guess.

Expected output: deliberate type choices before first sync.

5. Validate the payload before sending

Run the outbound payload against the local schema copy and catch mismatches before the API does. Pre-send validation turns API errors into local warnings with better context.

Expected output: pre-send validation catching mismatches locally.

Template: the checklist

Attribute type alignment:
[ ] Registered types read into a local schema copy
[ ] Coercion layer at the sync boundary
[ ] Uncoercible values quarantined with logging
[ ] Types locked deliberately before first write
[ ] Pre-send validation against the schema

Variant phrasings

intercom custom attribute wrong type

Steps 1 and 2. Read the registry, coerce at the boundary.

sync fails attribute type mismatch

Steps 2 and 3. Coerce, quarantine the rest.

intercom api rejects attribute value

Steps 1 and 5. Schema first, validate before send.

Why it happens

Source systems are loosely typed: a CRM happily stores "42", 42, and "forty-two" in the same field across records. Intercom attributes are strictly typed from first write. The sync sits between a sloppy source and a strict target with no translation layer, so the strict side rejects what the sloppy side sends. Coercion is the translation layer.

Edge cases

• Null versus missing: decide whether null clears the attribute or is skipped. Inconsistent null handling corrupts data quietly.
• Arrays and nested objects: Intercom attributes are flat scalars. Flatten or serialize deliberately; do not send structures.
• Type changes mid-life: if the business needs a new type, create a new attribute and migrate; do not fight the registry.
• Multi-source syncs: two sources writing the same attribute with different types. One owner per attribute, enforced.

Provenance

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

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

Thread query: intercom "attribute type mismatch" syncing custom objects

TL;DR: "Attribute type mismatch" means the value you sent does not match the type Intercom registered for that attribute: a string where it expects a number, a boolean where it expects a string. Align the schema first: read the registered types, coerce values at the sync boundary, and reject uncoercible values with a clear log instead of crashing the sync. Type discipline at the boundary fixes the whole class.