Custom Fields and Codes
Support for custom fields was added in version 2.0 of the REST API.
They behave exactly like the standard entity fields and can be accessed or updated using the same mechanisms.
All activated custom fields appear in the metadata document.
⚠️ Important:
Whenever a custom field is activated or deactivated in the PROLIN Smart Client Administration Console,
you must restart either the Web module or the entire PROLIN Power Server instance for the changes to take effect.
Custom Codes
Support for custom codes was introduced in version 2.2 of the REST API.
These behave similarly to standard code fields, but they require type annotations since dynamic properties are not statically known.
Usage
All operations involving custom codes must include the @odata.type annotation.
The required type is always:
"#PROLIN.Web.OData.Model.Code"Custom codes can be used in both POST and PATCH operations.
Example: Updating Custom Codes
PATCH http://myserver:5181/odata/ServiceRequest(139239) HTTP/1.1
Content-Length: 48
Content-Type: application/json
{
"ServicecallCode1": {
"@odata.type": "#PROLIN.Web.OData.Model.Code",
"Text": "None"
},
"ServicecallCode2": {
"@odata.type": "#PROLIN.Web.OData.Model.Code",
"Value": 3120234513,
"Text": "Waiting"
},
"ServicecallCode3": {
"@odata.type": "#PROLIN.Web.OData.Model.Code",
"Value": 3094610021
}
}✅ Key Points
| Concept | Description |
|---|---|
@odata.type |
Must always be #PROLIN.Web.OData.Model.Code for custom codes. |
| Field behavior | Same as standard fields once activated. |
| Restart required | Power Server or Web module must restart after custom field configuration changes. |
| Operations supported | Custom codes work in POST, PATCH, and GET requests. |
💡 Tip:
Custom codes are treated as dynamic properties.
Always ensure type annotations are present in your payloads to avoid400 Bad RequestorType mismatcherrors.