How to build a crowd plugin?

[Ashley]

I'm relatively new to building plugins and I need some guidance on how to move forward on editing my Crowd based plugin. I've already set up my environment and downloaded the Atlassian SDK, but now I am just a bit lost on what to do next to modify my plugin towards how I want it to be like. I created a REST API plugin module for it and now I am unsure of how I can configure it or where I should be making changes to it. I've seen a lot of documentation on Jira plugins, but not for Crowd. Any insight would be greatly appreciated! (My plugin is for acquiring data from the Crowd database regarding the users so would REST API even be the right plugin module to go for?) I get that each plugin module is for each function, but how do I even start to tackle it? What is the process of implementing these changes to the plugin?

[LynnG]

Yes, a REST API plugin module can be the right choice, but only if your goal is to add a custom endpoint inside Crowd that exposes the user data you need. If your goal is simply to fetch existing Crowd user/group data from another system, you may not need a plugin at all because Crowd already exposes REST APIs for user authentication, retrieving users, groups, memberships, attributes, and search. [developer....assian.com]

How to think about it

Option A: Use Crowd’s existing REST API

Choose this if you only need to read normal Crowd user/group data from an external app.

Crowd’s REST APIs are intended for applications connecting to Crowd and can retrieve users, groups, attributes, memberships, and perform searches. One important difference from Jira/Confluence REST APIs is that Crowd REST authentication uses the application name and password, not an individual username/password. [developer....assian.com]

This is usually the best first option if you are “acquiring data from Crowd regarding users.”

---

Option B: Build a Crowd plugin with a REST module

Choose this if you need something custom, for example:

• exposing a custom REST endpoint
• combining data in a way Crowd’s built-in REST API does not provide
• adding logic inside Crowd
• adding UI/menu/admin functionality inside Crowd
• reacting to Crowd events

Atlassian’s Crowd developer docs say there are two main ways to develop with Crowd: use the remote API if integrating Crowd with another application, or develop a plugin if you want to add capabilities to Crowd. [developer....assian.com]

The REST plugin module is specifically used to expose services and data entities as REST APIs, and Crowd supports REST plugin modules. [developer....assian.com], [developer....assian.com]

Where you make changes

In a typical Atlassian SDK plugin, you usually work in these places:

1. atlassian-plugin.xml

This is where you declare the plugin module.

For a REST module, it looks like this:

XML

1

<rest key="userDataRest" path="/userdata" version="1.0">

2

<description>Provides custom Crowd user data services.</description>

3

</rest>

Show more lines

The path and version values determine the URL structure. Atlassian documents the REST resource URL pattern as:

Plain Text

1

http://host:port/context/rest/api-name/api-version/resource-name

Show more lines

where api-name and api-version come from the REST module configuration in atlassian-plugin.xml. [developer....assian.com]

So if your Crowd context is /crowd, your endpoint may look something like:

Plain Text

1

http://localhost:8095/crowd/rest/userdata/1.0/users

Show more lines

2. Your Java REST resource class

This is where you implement the endpoint logic using JAX-RS annotations like:

Java

1

@PatH("/users")

2

@Produces({MediaType.APPLICATION_JSON})

3

public class UserDataResource {

4

5

@get

6

public Response getUsers() {

7

// Fetch user data here

8

return Response.ok(...).build();

9

}

10

}

Show more lines

The REST plugin module uses JAX-RS/Jersey annotations such as @PatH, @get, @post, and providers/resources are discovered by scanning plugin classes annotated with @PatH or @Provider. [developer....assian.com]

3. Your service/helper classes

Do not put everything inside the REST resource. A cleaner structure is:

Plain Text

1

src/main/java/com/example/crowd/plugin/rest/UserDataResource.java

2

src/main/java/com/example/crowd/plugin/service/UserDataService.java

3

src/main/java/com/example/crowd/plugin/dto/UserDto.java

Show more lines

A common beginner pattern is:

• REST resource handles HTTP request/response
• service class handles business logic
• DTO/model class controls what JSON is returned

Suggested implementation process

Here is a practical way to move forward:

Step 1: Confirm whether built-in Crowd REST already gives you the data

Before writing custom plugin code, check whether Crowd’s existing REST API already exposes the user data you need. Crowd’s REST API supports retrieving users, user attributes, groups, group memberships, nested group memberships, and search. [developer....assian.com]

If it already does, use that instead of building a plugin.

Step 2: If custom behavior is needed, keep your REST module

A REST module is appropriate if you want your plugin to expose a custom endpoint. Atlassian’s REST plugin module documentation says it is used to expose services and data entities as REST APIs. [developer....assian.com]

Step 3: Add or edit the REST module in atlassian-plugin.xml

Example:

XML

1

<rest key="crowdUserRest" path="/crowd-user-data" version="1.0">

2

<description>Custom REST API for Crowd user data</description>

3

</rest>

Show more lines

Step 4: Create a resource class

Example skeleton:

Java

1

package com.example.crowd.plugin.rest;

2

3

import javax.ws.rs.GET;

4

import javax.ws.rs.Path;

5

import javax.ws.rs.Produces;

6

import javax.ws.rs.core.MediaType;

7

import javax.ws.rs.core.Response;

8

9

@PatH("/users")

10

@Produces({ MediaType.APPLICATION_JSON })

11

public class CrowdUserResource {

12

13

@get

14

public Response getUsers() {

15

return Response.ok("{\"message\":\"User endpoint is working\"}").build();

16

}

17

}

Show more lines

Then test:

Plain Text

1

/crowd/rest/crowd-user-data/1.0/users

Show more lines

Step 5: Replace the dummy response with real Crowd user lookup logic

At this point, your next task is not really “REST configuration” anymore. It becomes: which Crowd Java service/API should my plugin use to fetch users?

That depends on your Crowd version and what data you need. Avoid querying the Crowd database directly unless you have no supported API alternative. Direct DB access can make your plugin fragile across upgrades.

Step 6: Run locally and iterate

The Atlassian SDK docs include development-cycle topics such as creating a plugin skeleton, modifying a plugin, running it in the container, QuickReload, SDK commands, working with Maven, and using the REST API Browser. [developer....assian.com]

For a beginner, the loop usually looks like:

Shell

1

atlas-run

Show more lines

Then make code changes, rebuild/reload, and test the REST endpoint in the browser or with curl/Postman.

So, is REST the right module?

Yes, if you want to expose your own API from the Crowd plugin.

No, or maybe unnecessary, if you only want to consume existing Crowd user data from another system. In that case, start with Crowd’s built-in REST API first. Crowd’s own docs position the remote API as the likely choice when integrating Crowd with another application, while plugins are for adding capabilities to Crowd. [developer....assian.com]

A good next target

Start very small:

1. Make your REST endpoint return "hello world".
2. Change it to return one hard-coded user DTO.
3. Change it to return one real Crowd user.
4. Then add filtering, paging, permissions, and error handling.

That keeps you from getting stuck trying to solve plugin configuration, REST design, Crowd APIs, and database access all at once.