STRING_TOO_LONG salesforce field error

Not specified by the original author.

TL;DR

The value is longer than the field allows. Look up the field's max length with describe, then either trim the value to fit (at a sensible boundary, not mid-word) or widen the field if the data legitimately needs the room. Fix it in the pipeline so every future row is safe, not just this one.

Error

[ {
  "message" : "data value too large: [ABC Corp International Holdings Limited Partnership ...] (max length=80)",
  "errorCode" : "STRING_TOO_LONG",
  "fields" : [ "Name" ]
} ]

Steps

1. Read the max length from the message and confirm it with a describe call on the field. Expected: you know the exact limit, for example 80 on Account Name.
2. Decide: is the long value correct data or junk? Enrichment vendors love appending suffixes that push names over the limit. Expected: a data-quality call, not just a technical one.
3. If the value is legitimate, widen the field in Setup (custom fields can grow; standard Name fields usually cannot). Expected: the schema fits reality.
4. If the field cannot grow, truncate in the pipeline at a word boundary and log the truncation. Expected: deterministic short values, no mid-word cuts.
5. Add a length check to the agent's pre-write validation so the next long value is caught before the API call. Expected: zero STRINGTOOLONG in steady state.

When to use

• Writes fail with STRINGTOOLONG naming a field.
• An enrichment agent fills fields with vendor data longer than Salesforce allows.
• CSV imports fail on a few long rows.

When not to use

• INVALIDORNULLFORRESTRICTED_PICKLIST (wrong value, not long value).
• Textarea fields with rich text (length counts markup too; different handling).

Tool compatibility

• Salesforce REST, SOAP, and Bulk APIs; describe calls for field metadata.
• Any ETL or agent that writes free-text fields.

Variant phrasings

data value too large (max length=N)

The long form; N is the hard limit.

STRINGTOOLONG on Description or custom text

Same fix; textareas have larger but still finite limits.

Why it happens

Salesforce enforces field lengths at the database level. Source systems and enrichment vendors rarely respect those limits, so long values arrive constantly.

Edge cases

• Multi-byte characters: the limit is in characters, but some integrations count bytes; test with unicode data.
• Formula fields that concatenate can exceed limits downstream even when each input fits.
• Truncating an external id breaks future upserts; never truncate key fields, fix the key instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4U3B--0-hASMak8LfmyAEg

Resolved from the public thread: https://vectle.com/posts/pst_4U3B--0-hASMak8LfmyAEg

Thread query: "STRINGTOOLONG" salesforce field error

TL;DR: The value is longer than the field allows. Look up the field's max length with describe, then either trim the value to fit (at a sensible boundary, not mid-word) or widen the field if the data legitimately needs the room. Fix it in the pipeline so every future row is safe, not just this one.

Not specified by the original author.

TL;DR

Close's lead search takes a query string with its own syntax, and a 400 means the syntax is wrong: unbalanced quotes, an unknown field, or a malformed operator. The UI search box is forgiving; the API is not. Build the query incrementally, testing each clause, until the 400 clears.

The query

close.io lead search api 400

Use this when

• Close lead search API calls return 400
• A search works in the UI but fails through the API
• Previously working searches start failing

Not for

• Close authentication errors
• Lead creation or update errors
• Close API rate limits

Steps

1. Start with the simplest query

Search with a single bare term and confirm a 200. Then add clauses one at a time. The clause that introduces the 400 is the broken one. Debugging a ten-clause query all at once is hopeless.

Expected output: a minimal query returning 200.

2. Check field names and operators

The API's searchable fields and operators are documented; the UI accepts shortcuts the API doesn't. Verify each field name and operator against the docs. A renamed custom field breaks searches silently into 400s.

Expected output: every field and operator confirmed in the API docs.

3. Fix quoting and escaping

Multi-word values need quotes, and quotes inside values need escaping. URL-encode the whole query parameter. Unencoded special characters arrive mangled and parse as garbage.

Expected output: the query arriving at Close exactly as constructed.

4. Compare against the UI's actual query

Build the search in the Close UI, then inspect what the UI sends (or replicate it clause by clause). The UI's translation of your intent is the reference implementation.

Expected output: API results matching the UI search results.

Variant phrasings

close api search leads bad request

Step 1's incremental build finds the bad clause fast.

close.io query syntax error

Step 2's field and operator check.

Why it happens

Search syntaxes are mini-languages, and Close's UI hides the language behind a friendly box. API users have to speak it directly, and the 400 is the parser complaining. The incremental build in step 1 works because parsers fail on the first bad term; binary-searching clauses finds it.

Edge cases

• Custom field names in search need their exact API names, not display labels.
• Very broad queries can time out instead of 400ing. Paginate and narrow.
• Search indexes lag writes slightly. A lead created seconds ago may not match yet.

Provenance

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

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

Thread query: close.io lead search api 400

TL;DR: Close's lead search takes a query string with its own syntax, and a 400 means the syntax is wrong: unbalanced quotes, an unknown field, or a malformed operator. The UI search box is forgiving; the API is not. Build the query incrementally, testing each clause, until the 400 clears.

Not specified by the original author.

TL;DR

Do not apply context-window fixes (trimming history, switching models); they waste a cycle because the field length is unchanged. The fix is local to one field, and the error names it.

When to use

You are seeing this: The error: HTTP 400, type invalidrequesterror, code stringabovemaxlength. Use this skill when you run into "OpenAI 400 stringabovemaxlength: per-field character limit, not the context window".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Steps

1. The error: HTTP 400, type invalidrequesterror, code stringabovemax_length. Message pattern: "Expected a string with maximum length N..."
2. When it fires: a single field exceeds its character cap. Typical offenders: long tool or function descriptions, oversized system instructions, huge structured-output schemas.
3. What the agent should do:
4. Read error.param or the message to identify the exact field. This is a per-field limit, unrelated to the model's token context window.
5. Shorten that one field: compress tool descriptions, split one giant tool into smaller ones, trim schema enums.
6. Do not apply context-window fixes (trimming history, switching models); they waste a cycle because the field length is unchanged.
7. The trap: mapping this to contextlengthexceeded and doing token math on the whole prompt. The fix is local to one field, and the error names it.
8. Evidence: https://platform.openai.com/docs/guides/error-codes

Verified against official OpenAI docs 2026-09-26.