30. 06. 2025 Giuseppe Di Garbo Atlassian, Service Management

Creating Jira Service Management Requests from a Public Website? Here’s the Secure, No-API Way

If you’ve ever tried integrating an external system or website with Jira Service Management (JSM), you’ve probably hit one or more roadblocks, especially when it comes to creating requests on behalf of end users without using the default Jira Service Management portal.

The good news? You don’t need to hand over admin access or build a fragile, permission-heavy API integration. There’s a smarter way, and it’s already built into Jira: Automation + Webhooks.

Let me walk you through a real-world case, how I tackled it, and how you can replicate it.

Use Case – External Web Form, Internal JSM Handling

Your company already uses JSM as an IT Service Desk to handle internal workflows like incident reporting, service requests, and change approvals.

It works well, especially via the standard customer portal, where employees or internal users can log in, choose request types, and track their tickets.

But now there’s a new need, coming from outside IT.

The marketing team wants to collect complaints and suggestions directly from the public website, using a custom-designed form that blends with the brand’s style. No redirects. No JSM interface. Just a native-looking form built into your company site.

The website is managed by an external supplier who has no access to your Jira instance.

Despite that, the supplier needs to:

  • Capture basic user data (first name, last name, email, phone)
  • Submit a complaint or suggestion
  • Trigger the creation of a ticket in your JSM project
  • Ensure the ticket is created on behalf of the actual user who submitted the form

In short: you want your supplier to push structured data into your JSM queue without exposing internal systems or admin permissions.

Options on the Table

Option 1: Issue Collector

The Issue Collector is meant to embed a form on a website, but unfortunately, it doesn’t support Jira Service Management (JSM) projects.

After several attempts, it became clear that this feature does not support request types, customer creation, or JSM-specific flows. It fails silently, or returns cryptic errors.

Option 2: REST API

The REST API is a solid plan. With it, you can:

  • Create a customer
  • Raise a request
  • Set custom fields
  • Control everything programmatically

BUT, to create a customer, the API caller must have Jira Administrator Global permission!

To run POST /rest/servicedeskapi/customer, your integration must act as a global admin.

And that’s a deal-breaker if you’re delegating this to an external supplier or third-party service.

The Better Way: Webhook-Powered Automation

Here’s the winning pattern we used instead – built entirely with JSM Automation.

We exposed a webhook that the supplier could call from their frontend. The webhook triggers an automation rule that:

  1. Creates the customer, if they don’t exist
  2. Creates the request, with the correct request type and fields
  3. Assigns the customer as the reporter, just like if they had submitted via the portal

What’s a Webhook?

A webhook is an HTTP endpoint (URL) exposed by JSM Automation that can receive data from external systems (like your custom form). It’s asynchronous, secure (via URL Token + Secret), and doesn’t require any JSM credentials.

When triggered, the webhook activates an Automation rule in JSM that processes the incoming data. You control everything through Jira’s no-code Automation engine.

Example Payload Sent to Webhook

{
  "projectKey": "COMPLAINTS",
  "summary": "Feedback on recent service experience",
  "description": "I booked a home installation service for May 15, but the technician never showed up. No call, no email. I’d like to understand what happened and reschedule as soon as possible.",
  "requestType": "Complaint",
  "reporter": {
    "email": joe.doe@example.com",
    "displayName": "Joe Doe"
  },
  "customFields": {
    "complaint_category": "Home Installation",
    "scheduled_date": "2025-05-15",
    "mobile_phone": "33312345332"
  }
}

Automation Rule in Jira Service Management

The rule consists of these key steps:

  1. Trigger: Incoming webhook (Work item criteria: No work items from the webhook)
  2. The incoming JSON payload is parsed and checked to ensure that the data matches the expected structure and agreed criteria – for instance, the rule continues only if the "requestType" field is "Complaint"; otherwise, it stops
  3. Action: “Add service project customer"
    • Automatically checks if the customer exists
    • Creates them if not
  4. Action: Create work item with request type
    • Creates the actual request
    • Fills in the fields from webhookData
    • Sets Raise on behalf of using “Customer created by this rule”

No global permissions. No API tokens. No admin handover. Just a webhook and a rule.

Security Tips

Since JSM webhooks always return 200 OK, it’s essential to design your own security layer.

Reverse Proxy or API Gateway

Don’t expose the JSM webhook URL directly.

Instead, route external requests through a reverse proxy (like NGINX) or an API Gateway. From there, you can:

  • Filter IPs (allow only known senders)
  • Enforce rate limits and request throttling
  • Inspect the payload (e.g. schema validation, required fields)
  • Require a shared secret or token
  • Block malformed requests

Only after a request passes all checks should your proxy forward the call to the real JSM webhook URL.

Optional Callback Verification

For high-sensitivity use cases, send a POST back to the supplier’s system for confirmation (e.g., “did you really send this?”) before proceeding.

This adds another layer of trust and allows for dispute handling or duplicate detection.

The Results

With this approach, you’ve built a smart and secure bridge between your external website and JSM, without compromising control or maintainability.

You’ve enabled an external system to submit structured requests, ensured they’re properly attributed to real users, and done it all without exposing admin privileges requested APIs.

No admin rights needed. No external plugins.

Just clean, declarative automation – exactly how JSM intended it.

Conclusion

When your workflows extend beyond your internal teams, the ability to collect structured data from the outside – safely and efficiently – becomes essential.

This approach gives you exactly that:

  • A single, secure webhook as the entry point
  • Full automation of customer creation and request handling
  • Clean separation of responsibilities – your supplier sends the data, JSM does the rest
  • All built natively within JSM, with no external dependencies or elevated permissions

It’s scalable, maintainable, and easy to monitor.

Whether you’re collecting complaints, processing service feedback, or opening tickets on behalf of users – this is a robust and elegant solution that fits right into your existing JSM environment.

No complexity. Just smart automation that works.


Here are the key resources mentioned throughout this article:

These Solutions are Engineered by Humans

Did you find this article interesting? Does it match your skill set? We’re often presented with problems that need customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix.

Giuseppe Di Garbo

Giuseppe Di Garbo

Consultant at Würth Phoenix
Hi everybody. I’m Giuseppe and I was born in Milan in 1979. Since the early years of university, I was attracted by the Open Source world and operating system GNU\Linux. After graduation I had the opportunity to participate in a project of a startup for the realization of an Internet Service Provider. Before joining Würth Phoenix as SI consultant, I gained great experience as an IT consultant on projects related to business continuity and implementation of open source software compliant to ITIL processes of incident, change and service catalog management. My free time is completely dedicated to my wife and, as soon as possible, run away from Milan and his caotic time and trekking discover our beautiful mountain near Lecco for relax and lookup the (clean) sky.

Author

Giuseppe Di Garbo

Hi everybody. I’m Giuseppe and I was born in Milan in 1979. Since the early years of university, I was attracted by the Open Source world and operating system GNU\Linux. After graduation I had the opportunity to participate in a project of a startup for the realization of an Internet Service Provider. Before joining Würth Phoenix as SI consultant, I gained great experience as an IT consultant on projects related to business continuity and implementation of open source software compliant to ITIL processes of incident, change and service catalog management. My free time is completely dedicated to my wife and, as soon as possible, run away from Milan and his caotic time and trekking discover our beautiful mountain near Lecco for relax and lookup the (clean) sky.

Leave a Reply

Your email address will not be published. Required fields are marked *

Archive