> For the complete documentation index, see [llms.txt](https://docs.enate.net/enate-help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.enate.net/enate-help/integrations/enate-integrations/apis/api-enums.md). # API Enums This document contains a list of values (Integer and String equivalent value) for Enate API enumerations, available as at the July 2026 Feature Wave. {% file src="/files/PGIHweSoibBqZ7DRhsK5" %} {% file src="/files/icuPaTQUxhyoQA1YHL57" %} *** #### Previous feature wave API Enumerations {% file src="/files/NOMYLdkLOCwPTjDpK80A" %} Please note that for the 'Status Reasons' method architecturally supports all work items (i.e. Tickets, Cases and Actions), however currently some of them are specific to a Ticket/Case/Action. The specific work Item type that each value is relevant for is noted in the document. {% hint style="info" %} Please note that the enum values are not in chronological order, so comparing the JSON enum response to the Swagger model will not be accurate. Please instead refer to this document. {% endhint %} *** ## How Enums Relate to API Versions Enumerations belong to the version of the API you call with the `api-version` parameter. Once a version has been released the whole of it is frozen, enumerations included, so a value keeps the same number, the same name and the same severity in that version for as long as the version is available. An integration built against a released version won't find a value changing meaning underneath it. New enumeration members are added to the newest version only. That's why adding a member to an enumeration isn't treated as a breaking change, and it's why the enumeration lists are published per version. See the API Changes page for the full list of what Enate does and doesn't treat as breaking: {% content-ref url="/pages/1DH9uE1vBH3GiHRi4vrK" %} [API Changes](/enate-help/integrations/enate-integrations/apis/api-changes.md) {% endcontent-ref %} The downloads above list the version 3 values. Work from the document that matches the version you're calling, rather than assuming the numbers are the same in every version. Enumerations are returned as integers in JSON, not as their names, so `"MessageID": 428812` is what you'll see on the wire. Use the documents above to turn those numbers into names. ## Validation Messages in a Response Validation messages are the enumeration you'll meet most often. Endpoints that create or update an object return the object and a collection of messages in the same envelope, so a 200 response can still carry warnings. Where a message is a failure, the response is a 400 Bad Request carrying the same envelope with `Result` set to null, and nothing is saved. A few messages raise 403 Forbidden or 404 Not Found instead, and where a request raises several messages the most serious status code wins. | Field | Type | Required | Description | | -------------------- | ---------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------ | | `Result` | Object | Optional | The created or updated object. Null where the request failed validation and nothing was saved | | `Messages` | Array of validation messages | Optional | The validation messages raised while processing the request. Absent or empty where there were none | | `MessageID` | Integer | Required | The enumeration value identifying the message, from the list for the API version you called | | `MessageDescription` | String | Required | The English text of the message, with `{0}`, `{1}` and so on as placeholders for the values in `Parameters` | | `Parameters` | Array | Required | The values to substitute into the placeholders in `MessageDescription`, in order | | `IsError` | Boolean | Required | True where the message is a failure and nothing was saved. False where it's a warning and the object was saved | | `RelatedObjectGUID` | GUID | Required | The object the message relates to, which is useful when the message is about a nested object rather than the one you submitted | | `RelatedObjectType` | Integer | Required | The type of the object named by `RelatedObjectGUID`, as an `EnateObjects` value | A version 3 call to enable an Email Route that has an invalid address and hasn't been connection tested returns 400 Bad Request with this body: ```json { "Result": null, "Messages": [ { "RelatedObjectGUID": "8f5a1d2c-9b41-4c6e-9d77-2a3ee0c14b55", "RelatedObjectType": 96, "MessageID": 96246, "MessageDescription": "Email Addresses {0} is not a valid email address.", "Parameters": [ "payroll.support@" ], "IsError": true }, { "RelatedObjectGUID": "8f5a1d2c-9b41-4c6e-9d77-2a3ee0c14b55", "RelatedObjectType": 96, "MessageID": 96277, "MessageDescription": "Route cannot be enabled without a valid connection test.", "Parameters": [], "IsError": true } ] } ``` `RelatedObjectType` 96 is `EmailRoute`, `MessageID` 96246 is `EmailRoute_EmailAddressInvalid` and `MessageID` 96277 is `EmailRoute_SuccessfulTestRequired`, all of which you can look up in the documents above. The first message carries a `{0}` placeholder and a value in `Parameters` to fill it; the second has no placeholder, so `Parameters` is empty. ## When a Value Can't Be Expressed in Your API Version Enate holds one set of values internally and converts them onto the version of the contract you asked for. Where the version you called has no member for the value Enate holds, Enate rejects the whole response rather than returning a number the version doesn't define. | Characteristic | Value | | -------------- | ------------------------------------------------------------------------------------------- | | Status code | 400 Bad Request | | Content type | `text/plain; charset=utf-8` | | Body | A single line naming the value that couldn't be expressed and the enumeration it belongs to | | Retry | No. The same request against the same version will always fail in the same way | The example above raises `EmailRoute_SuccessfulTestRequired`, which version 3 has a member for. Version 1 doesn't, because the message was added after version 1 was released. Send exactly the same request with `api-version=1` and you get this instead: ```http HTTP/1.1 400 Bad Request Content-Type: text/plain; charset=utf-8 'EmailRoute_SuccessfulTestRequired' is not a value that this version of the API can return for ConfigurationValidatorMessage. Use the latest version of the API to read this data. ``` {% hint style="warning" %} **This is a limitation of the older version, not a fault in your request.** Changing the values you send won't fix it, and the response tells you nothing about what was actually wrong with the data, because the message that would have told you is the one that couldn't be expressed. The same request succeeds on a later `api-version`. If you can't move version yet, avoid the endpoints that return the affected enumeration until you can. {% endhint %} Log the message text when you see this response. It names the enumeration that has moved on, which tells you which part of your integration to retest against the newer version. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.enate.net/enate-help/integrations/enate-integrations/apis/api-enums.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.