n8n Automation HubThe same failure, twice, on workflows that share nothing
WF - Portfolio Video Publisher and WF-B Daily Portfolio Publisher are two different, independently-built n8n workflows that both happen to cross-post finished portfolio-project videos to Threads as part of a wider social push. One builds its caption from a Google Sheets row's threads_caption field; the other builds it inline in a Code node by concatenating a Groq-generated post_title and a separate threads body field with two newlines in between. Neither shares a node, a credential, or a caption-generation step. Both failed at the exact same HTTP call — POST https://graph.threads.net/v1.0/<user-id>/threads — with the identical n8n-level error text.
What n8n actually shows you
The execution log's headline error for both runs was NodeApiError: The service was not able to process your request, HTTP code 500. That message is n8n's generic fallback wording for this HTTP Request node whenever the upstream API returns a non-2xx status without n8n having a more specific mapped message for it. It's technically accurate and completely useless for diagnosis — it says nothing about which parameter, or why, or how to fix it. Looking only at that top line, both failures looked like a transient Threads outage, the same class of blip already covered by a separate article on this site about a Facebook video-fetch 500 that turned out to be Meta's side glitching, not a real bug.
The real error was one level down, not the top-level message
n8n's execution detail view keeps the actual upstream response body in the error's context.request and messages fields, not in the headline message shown in the workflow canvas. Opening that context on both executions showed the identical Threads API payload: {"error":{"message":"Param text must be at most 500 characters long.","type":"THApiException","code":100,"fbtrace_id":"..."}}. Threads' Graph API does document a 500-character cap on the text parameter for a media-container creation call — it just isn't anywhere in n8n's own node documentation for the generic HTTP Request node, since this node has no Threads-specific awareness at all; it's a plain authenticated HTTP call with a URL and query parameters.
Both real captions were built to look good as long-form social copy: a hook line, a body paragraph explaining the automation, a time-saved stat, hashtags, and in one case a bilingual English/Ukrainian pair separated by a divider. Reasonable for Facebook, LinkedIn, or Instagram — all of which tolerate captions well over 2,000 characters. Threads' own native app caption limit is much higher too (500 was actually Threads' original 2023 launch limit for the consumer app, since raised); the Graph API's text parameter for programmatic posts, however, still enforces the old 500-character ceiling regardless of what the app itself now allows a human to type.
Why this is easy to miss until it actually happens
Every other caption in both workflows' rotation had, by chance, stayed under 500 characters — short single-language captions, or ones without the bilingual pattern. The bug only surfaces on the specific captions long enough to cross the line, which is exactly the kind of intermittent-looking failure that gets mistaken for a flaky third-party API rather than a parameter validation rule that only some inputs happen to trip.
The fix
Truncate (or shorten at the caption-generation step, not after the fact) any Threads-bound text value to 500 characters before it reaches the HTTP Request node — a Code or Set node right before "Threads Create Media" that hard-caps the string length, ideally cutting on a word or sentence boundary rather than mid-word. Neither workflow had this cap; both do now. The generalizable habit: when an HTTP Request node to any platform API fails with a generic "service was not able to process your request" style message, check the execution's raw request/response context before assuming the platform itself is having problems — the specific rejection reason is almost always in there, just not in the headline.