I’m working with Jira’s SOAP API in a C# application. I’m building a wrapper tool that lets our development team automatically create bug reports when errors occur in our software.
The issue I’m facing is with getting custom field information. Instead of hardcoding the custom field IDs (which can change), I want to use the retrieveCustomFields() method to dynamically get the field IDs based on their names.
Everything works perfectly, but there’s one major problem: the user account I use to connect to the SOAP service needs administrator permissions for this method to work.
The Jira docs say the SOAP service follows normal security rules, but I can’t find any setting to change this restriction. It seems weird that you need admin access just to read custom field IDs, especially since these IDs are visible in the HTML source anyway.
Has anyone found a way around this? Is there a configuration option I’m missing? Or do I really need to hardcode the field IDs or modify the RPC plugin source code?
Had this exact problem a few years ago on a similar project. Yeah, retrieveCustomFields() needs admin privileges - it’s annoying but that’s how most Jira SOAP API admin functions work. I ended up creating a dedicated service account with minimal admin permissions just for API calls. You can lock it down through Jira’s permission schemes so it only gets what your integration needs while keeping the admin status for SOAP calls. If you can upgrade, definitely consider switching to Jira’s REST API instead. The REST endpoints for custom fields have more granular permissions and don’t always need full admin access. Plus REST is more future-proof since Atlassian deprecated SOAP API ages ago. If you’re stuck with SOAP and can’t get admin access, you might need a caching setup where an admin runs the field retrieval periodically and dumps the mappings to a config file your app can read.
Yeah, this is a known limitation with the SOAP API design. The retrieveCustomFields() method needs admin privileges since it touches system-level metadata that Atlassian treats as sensitive config data. I hit the same wall building integration tools for our QA team. My workaround was a hybrid approach - I built a small utility script that runs daily with admin credentials to grab the custom field mappings and dump them into a local database table. Then my main app reads from that cached data instead of hitting the SOAP API directly. You only need admin access for the scheduled sync job, not every API call your wrapper makes. Field IDs don’t change often enough to need real-time lookups anyway. You could also check Jira’s issue creation screen config to see which custom fields are required for bug reports, then just hardcode those specific ones since they’re probably stable in your environment.
unfortunately that’s just how the SOAP API works - retrieveCustomFields() is hardcoded to require admin permissions. I’ve seen people work around this by switching to the REST API instead (GET /rest/api/2/field) which doesn’t always need admin access depending on your JIRA setup. worth checking if you can switch APIs for just that part of your wrapper.