I’m currently working on integrating Epicor ERP using REST APIs and have a few questions regarding the usage of the CallSettings header in API requests. The Epicor documentation mentions that this header can accept multiple key-value pairs, such as {"Company": "EPIC06", "Plant": "SvcParts"}. However, I’m looking for some clarification on the following:
Valid key-value pairs for CallSettings: What are the acceptable combinations that can be used in the CallSettings header? Are there any guidelines or a full list of valid keys and values?
Observed behavior with different key-value combinations: I’ve tested various combinations in the CallSettings header and have observed the following behaviors. Can someone confirm if these are expected?
{"Company": "000000"} - Results in an invalid URL error (likely due to an invalid company name).
{"Plant": "MfgSys"} - Works correctly.
{"Plant111": "MfgSys"} - Also works, even though “Plant111” appears to be an invalid key.
{"Plant": "MfgSys1"} - Works, despite “MfgSys1” not being a valid plant as far as I know.
{"Company": "EPIC06"} - Works correctly with a valid company name.
Given these results, I’m wondering how the system is validating the key-value pairs in the CallSettings header. Is the behavior intentional, or is there supposed to be stricter validation in place for these values?
Additionally, I’d appreciate any insights on when it’s beneficial to use CallSettings in a REST request. Are there specific use cases where using this header is particularly useful?
When we say the transactions “Work”, do we mean that it doesn’t return an error or that it actually returns valid data from a different value. For example, does using “Plant”: “MfgSys1” return valid data(?) or data from the currently logged in plant? Also, are there errors in the AppServer or other logs?
When I say the request “worked,” I mean that it successfully hit the correct URL and did not return any errors, even when invalid keys or values were used in the CallSettings.
I am currently working with REST APIs, and this is where I observed this behavior.
The API I tested was: https://{{host}}/{{site}}/api/v1.
The request headers included the following:
Authorization: Basic {{token}}
keep-alive: false
Content-Type: application/atom+xml
Accept: application/atom+xml
CallSettings: {"Plant111":"0101"}
The request worked without issues, despite using "Plant111" (which appears to be an invalid key in CallSettings).
I am trying to understand:
The exact behavior of CallSettings.
When CallSettings should be used.
Why no error occurred for the invalid key in the request.
From a security perspective, APIs often do not return descriptive errors to the client without extra configuration. One could argue that the call should return a 400 without indicating a bad parameter (like “Plant111”) was sent. Did you check the AppServer error log in Event Viewer to see if indeed any errors were thrown?
On the other hand, using {“Plant”:“MfgSys1”} SHOULD return a 404 since that resource does not exist. I would report that to Epicor if it is failing silently.
The REST Services Guide from EpicWeb indicates the usage of the CallSettings. In addition to switching company or plant, you can also choose the Language and FormatCulture.
As an integrator, you will find OData endpoints not always reliable. The Custom (RPC) endpoints are fairly solid. Using Epicor Functions and the BAQSvc endpoints will make integrations less brittle and more performant.
