UNPROCESSABLE_ENTITY

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

The body you sent is not valid JSON. The usual culprits are a trailing comma, single quotes instead of double quotes, or sending form-encoded data instead of JSON. Fix the payload so it is strict JSON with the q field present, and set Content-Type to application/json.

serper.dev 400 invalid JSON body

Use this when

• POST https://google.serper.dev/search returns 400 with an invalid-JSON message
• The same query works in curl but fails from your code (or vice versa)
• You are building the body with string concatenation

Not for this skill when

• Serper returns 401/403 (the X-API-KEY header is missing or wrong)
• Serper returns 429 (rate limit; back off instead)
• Results return but are wrong or empty (query wording, not payload shape)

Steps

1. Print the exact raw body bytes you are sending, before headers. Expected: you can see the malformed fragment (trailing comma, single quotes, stray text).
2. Validate it with json.loads in Python or JSON.parse in Node. Expected: the parser points at the exact character offset of the problem.
3. Rebuild the body with a real serializer (json.dumps / JSON.stringify), never string templates. Expected: valid strict JSON every time.
4. Confirm the payload includes the required q field as a string and that Content-Type is application/json. Expected: 200 with a results array.
5. Retry the identical payload from curl with -H 'Content-Type: application/json' -d to isolate client vs server. Expected: if curl 200s and your code 400s, the bug is in your HTTP client setup.

Variant phrasings

serper invalid json body error

Run the body through a strict JSON parser to find the offending character.

serper.dev 400 bad request search

Check Content-Type first: many 400s are form-encoded bodies sent to a JSON endpoint.

Tool/version compatibility

Serper search API v1 (google.serper.dev). Same fix applies to the images, news, places, and scholar endpoints, which share the JSON-body contract.

Why it happens

The endpoint parses the body as strict JSON (RFC 8259): no trailing commas, no comments, double quotes only. Common producers violate this: Python f-string templates, requests.post(data=...) instead of json=..., or curl -d without the JSON content type. The API rejects the body before it ever looks at your key, so auth looks fine while the payload is the problem.

Edge cases / pitfalls

• Non-ASCII queries must be UTF-8 encoded; some clients double-encode and produce mojibake, which can also 400.
• An empty body or a body that is just whitespace 400s the same way.
• Optional fields like gl, hl, num must be the documented types; a string where a number is expected can 400.
• Read keys via os.environ.get("SERPERAPIKEY") and never log or print the value.

Provenance

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

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

Thread query: serper.dev 400 invalid JSON body

TL;DR: The body you sent is not valid JSON. The usual culprits are a trailing comma, single quotes instead of double quotes, or sending form-encoded data instead of JSON. Fix the payload so it is strict JSON with the q field present, and set Content-Type to application/json.

Not specified by the original author.

TL;DR

A Zendesk 422 on ticket creation almost always means the request failed validation, not that the API is broken. The response body names the offending field, and the usual suspects are a missing requester, an invalid custom field value, or a dropdown tag that does not exist. Read the error details first, fix the field, and retry with a minimal payload to isolate which field is wrong.

The query

zendesk api error "422 unprocessable entity" creating ticket via api

Use this when

• POST /api/v2/tickets.json returns 422 Unprocessable Entity
• Bulk imports report per-record 422 failures
• A ticket create that worked in staging fails in production
• You are building or maintaining a Zendesk ticket creation integration

Not for

• 401 Unauthorized (credential or token problems)
• 429 rate limiting (throttling, not validation)
• Tickets failing to create from email or web form
• Agent UI errors when manually creating tickets

Steps

1. Read the error details in the response body

A 422 always carries a details object naming the field and the rule it broke, for example a requester error or an invalid custom field value. Log the full body. The top-level message alone never tells you which field failed.

Expected output: the exact field and rule from the details payload.

2. Verify the requester block

Ticket creation requires a valid requester identity. Confirm the requester email parses, the name is present, and you are not passing both an existing user id and a conflicting email. Anonymous tickets still need the requester object with a name or email.

Expected output: requester email and name confirmed valid, no id/email conflict.

3. Validate every custom field value against its type

Dropdowns accept only defined tag values, dates must be ISO format, checkboxes take true or false. A free-text value sent to a dropdown field is the most common 422. Pull the ticket field definitions and compare each value you send.

Expected output: each custom field value matches its declared type and allowed values.

4. Strip the payload to a minimal ticket and retry

Send only subject, comment body, and requester. If the minimal ticket creates, add fields back one at a time until the 422 returns. That pinpoints the field faster than guessing.

Expected output: a minimal ticket creates successfully, or still 422s (meaning the problem is auth/scope, not fields).

5. Check field permissions and required-on-solve settings

Fields marked required in the admin UI can reject API creates missing them. Confirm the API credential has permission to set every field you send, especially restricted custom fields.

Expected output: required fields identified, permissions confirmed.

Template: the diagnosis checklist

422 on ticket create:
[ ] Response details read: failing field = ____, rule = ____
[ ] Requester email valid, no id/email conflict
[ ] Each custom field value matches its type (dropdown tags verified)
[ ] Minimal payload (subject + comment + requester) retried
[ ] Required and restricted fields checked against API permissions
Fix the named field, retry, then rebuild the full payload field by field.

Variant phrasings

422 creating ticket with custom fields

Step 3 first. Dropdown tag mismatches cause most of these.

zendesk api ticket create validation failed

Steps 1 and 2. The details payload and the requester block.

bulk import 422 errors

Step 4 in a loop: isolate the failing field per record, fix the mapping once.

Why it happens

The tickets endpoint validates the payload against the instance's ticket fields, user records, and permissions before writing anything. Because instances differ (custom fields, required fields, dropdown options), a payload that works on one instance 422s on another. The 422 is the API telling you the payload does not match this instance's rules.

Edge cases

• Sandbox to production drift: dropdown tags and required fields differ between instances. Re-pull field definitions per instance.
• End-user versus agent creates: end-user tokens cannot set some fields agents can. The same payload behaves differently by credential.
• Locale-sensitive date fields: a valid ISO date in one locale format can still fail if the field expects a different pattern.
• Deleted users as requesters: referencing a deleted user id 422s. Resolve to an active identity first.

Provenance

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

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

Thread query: zendesk api error "422 unprocessable entity" creating ticket via api

TL;DR: A Zendesk 422 on ticket creation almost always means the request failed validation, not that the API is broken. The response body names the offending field, and the usual suspects are a missing requester, an invalid custom field value, or a dropdown tag that does not exist. Read the error details first, fix the field, and retry with a minimal payload to isolate which field is wrong.