Hi.
My question is about non-correct REST API work in Jira Data Center v.9.12.
I have a problem with additing Workflow Scheme in project via POST /rest/api/2/project.
I have developed an application for easy project creation. The user selects the types of tasks he needs, and the application creates and configures all the necessary schemas. The application has been tested, and it fills in the schemas correctly, depending on the source data. But there was a problem with the assignment of the workflow schema.
The application's logic is as follows:
1. Before creating project, the necessary workflow scheme is created, based on the selected task types.
2. Then, the necessary WF Scheme id is passed through the command to create the project (as shown in the atlassian documentation for "Create project" -> "Request").
However, for some reason, Jira itself creates another default workflow schema at the time of project creation and additionally binds it to the project.
So there are two active WF Schemas in the system, which leads to critical errors in Jira itself - all workflow schemas are no longer displayed in the system and 500 errors appear.
The Jira log is like this:
Caused by: java.lang.IllegalArgumentException: Passed List had more than one value.
Also the log shows that at first step Jira correctly assign the necessary scheme but then creates and assign a new one too (with default issue types):
2026-08-12 09:08:28 … /rest/api/2/project [c.a.j.r.v2.issue.ProjectWorkflowSchemeAssignor] Assigning requestedWorkflowSchemeId=15755 into new project with projectId=15777
2026-08-12 09:08:28 … /rest/api/2/project [c.a.j.i.f.config.manager.FieldConfigSchemeManagerImpl] ConfigScheme TEST: Issue Type Scheme for tracking simple issues (17830). Created with no associated contexts
2026-08-12 09:08:28 … /rest/api/2/project [c.a.jira.workflow.OSWorkflowManager] User 'test.app(JIRAUSER42601)' updated workflow 'TEST: Workflow Scheme for tracking simple issues.' at 'Wed Aug 12 09:08:28 UTC 2026'
2026-08-12 09:08:29 … /rest/api/2/issuetypescheme [c.a.j.i.f.config.manager.FieldConfigSchemeManagerImpl] ConfigScheme TEST Issue Scheme (17831). Created with no associated contexts
2026-08-12 09:08:33 … /rest/api/2/status [c.a.j.rest.exception.ExceptionInterceptor] Returning internal server error in response
java.lang.reflect.InvocationTargetException
at jdk.internal.reflect.GeneratedMethodAccessor4578.invoke(Unknown Source)
…
at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: java.lang.IllegalArgumentException: Passed List had more than one value.
And finally I have two active schemes: my with id=15755 and Jira with id=15756.
How and why did this happen?
Hola Евгения,
The logs you posted strongly suggest that Jira first creates the project with your requested workflow scheme, then performs a second project configuration operation that creates and associates another scheme.
The sequence is that Jira logs requestedWorkflowSchemeId=15755 during POST /rest/api/2/project, then immediately creates “TEST: Workflow Scheme for tracking simple issues,” followed by a separate POST /rest/api/2/issuetypescheme.
I wouldn’t expect a healthy Jira project to have two active workflow schemes. Atlassian’s Data Center REST documentation treats the workflow scheme as a single project association, and the project creation endpoint accepts a workflowScheme value as part of the project configuration. The workflow scheme API is documented here.
Because the first assignment in your log succeeds, I’d look closely at what your application does immediately after POST /rest/api/2/project. In particular, the later /rest/api/2/issuetypescheme call is worth investigating. If your application creates or assigns an issue type scheme after project creation, Jira may be invoking additional project-template/configuration logic that’s generating the default workflow scheme you see as 15756.
A useful isolation test would be to create one project with only the initial POST /rest/api/2/project request, including workflowSchemeId 15755, and stop the application before any subsequent scheme configuration calls. Then check which workflow scheme is associated with the project. If only 15755 exists at that point, re-enable the later configuration calls one at a time until the second workflow scheme appears.
The Data Center project REST API is here, so I’d also compare the exact request body your application sends against the documented fields for Create project.
If the duplicate scheme is created by Jira immediately after a single isolated Create project request, with no follow-up API calls from your application, I’d treat that as a Data Center defect and raise it with Atlassian Support. Include the complete request body, the two scheme IDs, project ID 15777, the timestamp around 2026-08-12 09:08:28 UTC, and the surrounding application and Jira logs. The resulting “Passed List had more than one value” exception indicates Jira has reached an invalid configuration state rather than something you should try to repair through additional REST calls.
Thanks,
James
Thanks for the reply, James!
Yes, I'll try to test the app only with the POST /rest/api/2/project request and see how the system behaves.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.