API Change: Pipeline Error Response Format Update
We’ve updated how pipeline errors are returned in the CircleCI API.
What’s changing
Previously, related lines from a single config error were returned as separate objects in the errors array:
"errors": [
{ "type": "config-deprecated-syntax", "message": "Error calling workflow: 'build-test-deploy'" },
{ "type": "config-deprecated-syntax", "message": "Error calling job: 'buggy-orb/exhibit-bug'" },
{ "type": "config-deprecated-syntax", "message": "Referred to a variable that does not exist" }
]
Going forward, all lines belonging to the same error are consolidated into a single object, with lines separated by a newline character (\n):
"errors": [
{ "type": "config-deprecated-syntax", "message": "Error calling workflow: 'build-test-deploy'\nError calling job: 'buggy-orb/exhibit-bug'\nReferred to a variable that does not exist" }
]
Why we’re making this change
This consolidation lays the groundwork for returning multiple distinct errors in a single response. Soon, if your config has more than one unrelated issue, you’ll see each as a separate object in the errors array — so you can identify and fix all problems at once, rather than triggering your pipeline multiple times.
What you need to do
If your code parses the errors array, verify it handles multi-line message values correctly. The number of objects in the array will now reflect the number of distinct errors, not the number of individual error lines.
Affected APIs
v2:
GET /api/v2/pipelineGET /api/v2/pipeline/{pipeline-id}GET /api/v2/project/{project-slug}/pipelineGET /api/v2/project/{project-slug}/pipeline/mineGET /api/v2/project/{project-slug}/pipeline/{pipeline-number}
v3:
GET /api/v3/runsGET /api/v3/runs/searchGET /api/v3/runs/{id}