Content
Added by Etienne Ott over 2 years ago
We have successfully coupled an external system with our instance of OpenProject and use the API to create work packages from that system. Some API endpoints are fine with using the project string ID (e.g. this project is called OpenProject and has the string ID "openproject"), however other endpoints require the numeric ID.
One way to obtain it is the projects API endpoint. However it proved difficult to explain how to use the API and format JSON in a human-readable way to non-technical personnel. Further use of the API to give the user a nice dropdown with names of projects is possible but incurs significant amounts of additional development, that we currently don't have time for. It is much easier to tell the users "Take this number from this URL within OpenProject and enter it here".
Is there any view/query/page/etc. accessible within OP's user interface that exposes the numeric project ID? All I can find is the string ID.
Replies (3)
Hi Etienne,
the project identifier is unique and can be used in place of the ID in the API. We tend to not recommend it as it is not part of the public API and might change in the future. But right now, just tell them to copy the identifier and use that.
For example: https://community.openproject.org/api/v3/projects/openproject == https://community.openproject.org/api/v3/projects/14
Best
Oliver
Hello Oliver,
Thanks for your reply. We found that at least one specific endpoint does not accept the identifier and returns an HTTP 422 "Unprocessable entity in url" error:
POST /api/v3/work_packages with payload:
It seems likely that the project identifier is accepted as URL parameter for endpoints, but not for linked entities in a POST request. I think during development we first tried the /api/v3/projects/identifier/work_packages endpoint with the same result and switched to the one above before we realized the problem was the identifier. This may or may not be a bug, but given that this is not recommended use I won't bother filing a bug report.
Meanwhile we realized that we overestimated the work required to implement a dropdown for linking projects and will go that route now. That means the issue has become moot anyway. I suppose this topic has some use for posteriority's sake.
Hi Etienne,
you're correct that the href value needs to be the internal ID. You could do a request to the project API v3 resource first to get the ID, but I understand that this is one extra step you might have wanted to avoid.
Best
Oliver