Introduction
The PROLIN Power Server REST-based Web API is a service that exposes PROLIN Smart Suite resources and relationships through the Open Data Protocol (OData).
This service can be accessed using programming languages such as C# or Java, or scripting languages like JavaScript.
Interaction with the service is performed through standard HTTP requests:
- HTTP GET → Retrieve data from the service
- HTTP POST, PUT, PATCH, DELETE → Manipulate data
By default, the data is returned in JSON format.
In the remainder of this document, the term REST-based Web API will be referred to as REST API.
Change History
| Rev # | Date | Summary |
|---|---|---|
| 0.1 | June 2015 | Initial revision |
| 1.0 | Mar 2016 | Finalized revision |
| 1.1 | Aug 2016 | Added support for $select clause |
| 1.2 | Oct 2016 | Added support for $expand clause |
| 1.3 | Jan 2017 | Added queries on individual entities |
| 2.0 | Feb 2020 | - Added support for $select and $expand on individual properties - Added support for navigation properties - Added support for OAuth authentication - Added support for attachments, history lines and custom fields - Added OpenAPI explorer endpoint - Added TLS support - Added support for POST, PATCH, DELETE operations - Added support for creating and removing references - Exposed some basic OData annotations in $metadata - Added $ping |
| 2.1 | Jun 2020 | - Date/Time values are always UTC - POST now accepts @odata.bind to add references on creation - $filter=Code/Value eq <id> now supported - Added support for history line attachments - Added support for @odata.bind on PATCH operations |
| 2.2 | Mar 2021 | - Added support for Custom Entity Reference update/delete/assign - Added support for Custom Code properties (Patch, Post) - Added support for nested complex object navigation (e.g., Assignment) |
| 2.3 | Jun 2024 | - Added Codes function endpoint - Added support for Templates |
| 2.4 | Sept 2025 | - Added /Me Endpoint |
| 2.5 | Oct 2026 | - /Codes results are now ordered by their Ordering column - /Codes results now include a Hierarchical flag per code type - Hierarchical code properties on entities no longer inline their full parent chain; use the CodeType metadata annotation and /Codes to look one up - Navigating to a collection (e.g. ServiceRequests(<key>)/HistoryLines) now returns a page of results instead of HTTP 500 - $select=* now returns every property, including custom fields - $expand without $select no longer drops complex properties such as Registration and Assignment - Person.MemberOf, Workgroup.Members and the Changes, Incidents, Problems and Servicecalls of a Configuration Item are no longer declared as containment in $metadata; their entities are identified through their own entity sets - Creating a reference ( POST/PUT on $ref) always returns 204 No Content - A minimal attachment upload response now carries an OData-EntityId header - Template results include their Entity inline - OpeningsSchedule no longer declares SourceID, Folder, Attachments and Registration, which never held data - $filter accepts a code or a single related item compared with null (Status ne null, Caller eq null), not, and comparisons with the value on the left (null ne Status); these returned HTTP 500 - Custom fields on custom code types created in Service Desk, ordered or hierarchical, are now available like standard custom codes: in $metadata, GET, $filter on Value, POST, PATCH and /Codes - A POST writes only the properties its body contains: a property left out keeps the template’s or the server’s value, and an explicit null is written, also over a template value - A service request created with only Caller@odata.bind keeps its caller and gets the caller’s organization; before, a caller who belongs to an organization was dropped - A template can be applied to an existing entity with PATCH and Template@odata.bind - $top=n now limits the total number of entries, as OData 4.0 defines: next links stop after n entries, and $top=0 returns none - A response holds at most 250 entries; larger requests get a next link for the rest - The odata.maxpagesize preference sets the page size and is answered with Preference-Applied - A Deadline sent with a POST or PATCH of an incident or service request is stored as sent; before, setting the priority or impact in the same request replaced it with a calculated deadline - A POST or PATCH that sets a property the server cannot store fails with 400 Bad Request, or 403 Forbidden when the role of the user may not modify it, and stores nothing; before, the value was dropped and the request succeeded - A POST stores the values of complex properties such as Assignment; before, it dropped them |
Intended Audience
Due to the high level of technical details, this document is intended for the following audience:
- Software Architects
- Software Engineers
- Support Engineers
- Technical Consultants