Automating jira cloud project creation

Question

Currently we are fetching information of projects details and doing the manual project creation process

idea is to create a project automatically when one of the operation team entered the details in the ticket and submit the request once verified by one transition click need to create a project with custom template.

Evelin Bayer - codefortynine · Answer

Hi @rajeswari saravanan ,

Building on what @Marc -Devoteam- , @James Gamble and @Andrey - Guenov Labs described - it sounds like you want to create a new space that reuses the configuration of an existing one. That's exactly what the Space Clone via API in our Deep Clone app does.

(Note: Atlassian recently renamed "projects" to "spaces" - I'll use the new terminology throughout.)

Unlike the native Jira API approach (which requires multiple calls and manual scheme assignments), our Deep Clone Marketplace App sets up your new space in one single API call. Your existing space acts as the template, no extra setup needed.

It supports exactly the automation flow you described: via its REST API, you can trigger a space clone from a Jira Automation rule using Send web request - fired by the approval transition on your ops ticket. The cloned space picks up the full configuration of your template (workflows, schemes, components, versions), without copying any work items.

The request itself is minimal - just three fields:

* sourceProjectId
* targetProjectKey
* targetProjectName

One call, and the new space is ready.

One caveat: this works for company-managed spaces only. If you're using team-managed spaces, this won't cover that case - as Andrey pointed out, you'd need a different approach there.

Disclosure: I work at codefortynine, the team behind Deep Clone for Jira.

Best
Evelin - codefortynine

Tomislav Tobijas · Answer

Hey @rajeswari saravanan ,

Piotr explained this pretty well a while back and here is the article link https://community.atlassian.com/forums/Automation-articles/Let-s-automate-project-creation-using-Jira-Automation/ba-p/2075145

I think we built a solution around this and it ended up really well. :)

Cheers, Tobi

Andrey - Guenov Labs · Answer

Building on Marc and James — the shape they describe is right (trigger on the approval transition → Send web request → project-template endpoint). Four things that tend to bite once you actually build it:

1. Send web request doesn't authenticate as your rule actor. This surprises people. Calling your own site's REST API from Automation still needs an explicit Authorization: Basic <base64 of email:api-token> header — the actor setting governs what the rule does inside Jira, not what your outbound HTTP call is allowed to do. And Automation has no secrets store, so that credential lives in the rule config, visible to anyone who can edit rules. Lock down who can edit that rule accordingly.

2. That credential needs Administer Jira. Creating a project is a global permission, not a project one. So whatever account backs the token is effectively a site admin, and every project your ops team requests gets created by it. Worth deciding deliberately rather than discovering it at go-live — a dedicated service account (not a person's, so it survives them leaving) is the usual answer.

3. Validate the project key before you POST. A key that's malformed or already taken is the most common 400 here, and Automation won't recover gracefully. Add a GET /rest/api/3/project/{key} first — a 404 means the key is free; anything else means stop and comment back on the request instead of firing the create. If ops types the key by hand, that check is doing a lot of work for you.

4. Check what "custom template" means for you. The project-template endpoint creates from a template definition — it isn't "clone project ABC". If what you actually want is "same workflows, screens and fields as our standard project", that's a different job: for company-managed projects, schemes are shared objects, so you create the project and then point it at the existing schemes and the configuration comes along. For team-managed, config is per-project, and you'd be looking at a Marketplace configuration-manager tool. Worth settling this before you write the rule, because it changes the whole approach.

One last thing: creation is asynchronous, so the POST returns a task, not a finished project. Poll /rest/api/3/task/{taskId} before doing anything downstream, then write the resulting project key and URL back as a comment on the original request and transition it to Done — or to a failed status with the error body if it didn't work. Your ops team will thank you the first time something goes wrong.