ICE API Reference — Chat API, Email API, Chat/Email Data API

Source: https://help.enterice.com/ice/documentation/chat-api/, /email-api/, /introduction-2/ Compiled: June 2026

Coverage note: Every endpoint name/URL below is captured directly from the live site navigation — this is the complete, 100% catalog of all three API products. Endpoints marked [VERIFIED] were fetched in full and their exact request/response JSON is reproduced (paraphrased field descriptions, not copy-pasted prose). All other endpoints follow one of the verified patterns below with extremely high confidence, based on this site's rigorously consistent naming/structure convention — but exact field names for those specific endpoints have not been individually confirmed. Tell me any specific endpoint and I'll fetch it to confirm exact fields if you need that level of precision before integrating.

1. Conventions Verified Across All Three APIs

2. ICE Chat API

Doc root: /ice/documentation/chat-api/ Organized as: Authorization → Admin → {User API, CannedResponses API, Customer API, Survey API, Campaign API, Skill API}

2.1 Authorization

Login [VERIFIED]

POST https://www.enterice.com/ICEAPI/api/Authenticate/Login Allowed for: Admin

Request:

{
  "OrganisationID": 59,
  "UserName": "user@example.com",
  "Password": "Password"
}

Request fields: OrganisationID (int), UserName (string), Password (string)

Success response:

{
  "Message": "Success",
  "Token": "<JWT>",
  "OrganisationID": 59,
  "OrganisationName": "FutureView Technologies",
  "UserID": 738,
  "UserName": "user@example.com",
  "UserFirstName": "Alistair",
  "UserFullName": "Alistair Samuels",
  "Permission": 1,
  "Offset": -360
}

Fail: {"Message": "The request is invalid."}

Note: Offset is a timezone offset in minutes (-360 = UTC-6), useful for client-side time display.

Logout [VERIFIED]

POST https://www.enterice.com/ICEAPI/api/Authenticate/Logout Request: {"UserId": 738, "Token": "<JWT>"} Success: [{"Message": "Success"}] (note: wrapped in an array, unlike most other endpoints) Fail: {"Message": "The request is invalid."}

2.2 Admin → User API

Base path: https://www.enterice.com/ICEAPI/api/ChatAdmin/<Method>

Endpoint Verified? Purpose
CreateUser [VERIFIED] Create agent/supervisor/admin account
GetUserList [VERIFIED] List all users in org
GetUserDetails pattern Single user by ID
UpdateUser pattern Update user fields
ResetPassword pattern Admin-triggered password reset
DeleteUser pattern Remove user
ImportUsers pattern Bulk user import
AddLogoutReason / GetLogoutReasonList / GetLogoutReasonDetails / UpdateLogoutReason / DeleteLogoutReason pattern CRUD for the logout-reason dropdown shown to agents
AddIPWhiteList / GetIPWhiteList / GetWhiteListIPDetails / UpdateWhiteListIP / DeleteWhiteListIP pattern CRUD for IP whitelist (admin login restriction)

CreateUser — full verified detail: POST .../ChatAdmin/CreateUser

{
  "Token": "<JWT>",
  "OrganizationID": 59,
  "Username": "asmith@enterice.com",
  "Password": "Password",
  "Organization": "ICE",
  "Forename": "Andrew",
  "Surname": "Smith",
  "RealForename": "Andrew",
  "RealSurname": "Smith",
  "RoleId": 1,
  "Gender": "Male",
  "ChatLimit": 10,
  "SkillIds": "12,56,79",
  "Volume": 1.0,
  "IsMultiSession": false,
  "RingType": "Sound 1"
}

RoleId: 1=Admin, 2=Agent, 3=Supervisor. SkillIds is comma-separated. ChatLimit caps concurrent chats per agent. Success: {"Message": "Success", "UserId": "654"}

GetUserList — full verified detail: POST .../ChatAdmin/GetUserList Request: {"Token": "<JWT>", "OrganizationID": 59} Success:

{
  "Message": "Success",
  "UserList": [
    {"UserId": 321, "IsEnable": 1, "UserName": "admin@admin.com", "ForeName": "admin", "SurName": "admin", "RoleId": 1, "ChatLimit": 5, "CurrentState": 0},
    {"UserId": 352, "IsEnable": 1, "UserName": "Tiffany", "ForeName": "Tiffany", "SurName": "Pardue", "RoleId": 2, "ChatLimit": 3, "CurrentState": 0}
  ]
}

CurrentState is almost certainly the agent's live presence/availability status code.

2.3 Admin → CannedResponses API (27 endpoints)

Manages the canned-response tree (Menus = folders, Phrases = the actual reusable text snippets agents send).

Group Endpoints
Responses (top-level) CreateCannedResponses, GetCannedResponsesList, GetCannedResponsesDetails, EnableDisableCannedResponses, UpdateCannedResponses, DeleteCannedResponses
Menu (folder) management AddCannedMenu, GetCannedMenuDetails, UpdateCannedMenu, DeleteCannedMenu, EnableDisableCannedMenu, MoveCannedMenuIn/Out/Up/Down
Phrase (leaf) management AddCannedPhrase, InsertCannedPhraseDetails, GetCannedPhraseDetails, UpdateCannedPhrase, DeleteCannedPhrase, EnableDisableCannedPhrase, MoveCannedPhraseIn/Out/Up/Down
Bulk ImportCannedResponses, ExportCannedResponses

This mirrors a typical nested-folder UI: Menus can be nested in Menus, Phrases live inside Menus, and the MoveXIn/Out/Up/Down set reorders/re-parents tree nodes — same idea as drag-and-drop reordering in the Admin → Settings → Chat → Canned Responses screen.

2.4 Admin → Customer API (10 endpoints)

Base path: .../ChatAdmin/<Method>

Endpoint Verified? Purpose
AddIPtoBlock / GetIPtoBlockList / GetIPtoBlockDetails / UpdateIPtoBlock / DeleteIPtoBlock pattern CRUD for blocked visitor IPs
GetChatHistory pattern List of past chats for a customer/criteria
GetChatInformation pattern Metadata for a specific chat
GetChatTranscript [VERIFIED] Download chat transcript
GetChatSurveyInformation pattern Post-chat survey answers for a chat
GetChatNavigationInformation pattern Visitor's page-navigation history during the chat

GetChatTranscript — full verified detail (note: this one is GET, not POST): GET https://www.enterice.com/ICEAPI/api/ChatAdmin/GetChatTranscript?Token=(Token)&ChatId=(ChatId) Request params: Token (string), ChatId (int) Success: {"Message": "Success", "FileName": "transcript.xls"} — the doc notes "pass actual file as output," implying the real response is a file stream/download, with this JSON being the conceptual shape. Fail: {"message": "Failed"}

This is the one confirmed exception to the "everything is POST" rule — worth checking each Customer API retrieval endpoint individually if you're building a client, since Get* endpoints in this category may lean GET more often than the Admin CRUD endpoints do.

2.5 Admin → Survey API (11 endpoints)

CreateSurvey, GetSurveyList, GetSurveyDetails, UpdateSurvey, DeleteSurvey, ActiveInactiveSurvey, AddSurveyQuestion, GetSurveyQuestionDetails, UpdateSurveyQuestion, DeleteSurveyQuestion, PublishSurvey

Two-level structure: a Survey is a container; Questions are added/managed as sub-objects (mirrors Pre-Chat/In-Chat/Exit/Offline Survey builders in Admin UI). PublishSurvey suggests a draft→published lifecycle distinct from ActiveInactiveSurvey (which is presumably a runtime on/off toggle for an already-published survey).

2.6 Admin → Campaign API (5 endpoints)

CreateCampaign, GetCampaignList, GetCampaignDetails, UpdateCampaign, DeleteCampaign — straightforward CRUD, no enable/disable or reordering variant. Maps to Admin → Settings → Common → Campaign.

2.7 Admin → Skill API (11 endpoints)

CreateSkill, GetSkillList, GetSkillDetails, UpdateSkill, DeleteSkill, AddMembersInSkill, AddPushURL, GetPushURLList, GetPushURLDetails, UpdatePushURL, DeletePushURL

A Skill is a queue/routing group (agents are assigned to skills; chats route to skills). AddMembersInSkill attaches users to a skill. The Push URL sub-resource is the "push a URL into the visitor's browser" feature seen in the chat toolbar — scoped per-skill here, suggesting default push URLs can be configured per queue.

3. ICE Email API

Doc root: /ice/documentation/email-api/ Larger surface than Chat API — adds an entire Supervisor and Agent category not present in Chat API (because email is a stateful ticket system, not a live session).

3.1 Authorization

Login, Logout — same shape as Chat API (separate URL namespace: /authorization-2/ vs /authorization/, but functionally identical pattern).

3.2 Admin → User API (6 endpoints)

CreateUser, Get User List, Get User Details, Update User, Reset Password, Delete User — smaller than Chat API's User API (17 endpoints) because Email API's User module doesn't include ImportUsers, LogoutReason CRUD, or IPWhitelist CRUD as part of this module (those concepts are likely shared/global rather than duplicated per-channel — worth confirming if you need email-side IP whitelisting, since it may live under Chat API instead).

3.3 Admin → Canned Letters Set API (27 endpoints)

Direct structural mirror of Chat API's CannedResponses API, renamed for email ("Letters" instead of "Responses"): Create/Get/Update/Delete/EnableDisable Canned Letters Set; Add/Get/Update/Delete/EnableDisable/Move(In/Out/Up/Down) Canned Menu; Add/Insert/Get/Update/Delete/EnableDisable/Move(In/Out/Up/Down) Canned Phrase; Import/Export.

3.4 Admin → Email Web Form API (13 endpoints)

Create/Get/Update/Delete/ActiveInactive Email Web Form, Get Control List, Add/Get/Update/Delete Email Form Control, Get Email Form Control List, Get Email Form Control Details, Publish Email Form.

Two-level structure again: a Web Form is a container, Controls are the individual fields on that form (text box, dropdown, etc.) — maps to Admin → Settings → Email → Email Web Form.

3.5 Admin → Email Filter API (5 endpoints)

Create, Get List, Update, Get Details, Delete Email Filter — straightforward CRUD, maps to Admin → Settings → Email → Email Filtering (rules for routing/categorizing incoming email).

3.6 Admin → Response Template API (6 endpoints)

Get Template List, Create/Get/Update/Delete Response Template, Get Response Template List — maps to Admin → Settings → Email → Response Templates (pre-built email reply templates, distinct from Canned Letters which are shorter snippets).

3.7 Admin → Email Server APIs (6 endpoints)

Create/Get/Update/Delete/Enable-Disable Email Server, Get Email Server List — manages the actual SMTP/IMAP mail server connections ICE polls/sends through. This is the most "infrastructure-level" module in the whole API surface — relevant if you're automating server provisioning.

3.8 Admin → Service Level API (11 endpoints)

Create/Get/Update/Delete/Enable-Disable Service Level, Get Service Level List, Add/Get/Update/Delete SLA Hours, Get SLA Hours List — SLA policies with associated business-hours definitions. Maps to Admin → Settings → Email → Service Level.

3.9 Admin → Campaign API (5) / Skill API (6)

Same shape as Chat API's equivalents, scoped to email. Skill API here is smaller (6 vs Chat's 11) — no Push URL sub-resource, since push-URL is a live-chat-specific browser interaction that doesn't apply to async email.

3.10 Supervisor and Agent (43 endpoints — no Chat API equivalent)

This is the largest single category and represents the actual day-to-day ticket-working operations (vs. Admin's configuration operations). It has no Chat API parallel because chat is live/ephemeral while email is a persistent ticket queue. Grouped by function:

Ticket assignment/routing: Assign Tickets at Login, Get Supervisor List by Org ID, Unassign Tickets at Logout, Get Ticket Count (+ Sup variant), Load Ticket Per Skill (+ Supervisor variant), Load Ticket by Status (+ Sup variant), Pick Tickets, Escalate to Operator / to Supervisor (×2 listed — likely duplicate/legacy) / to Skill

Folder/ticket lifecycle: Update for Move to Folder, Update for Spam to Folder, Delete Tickets, Update Ticket Status without Send, Download Unassigned Tickets, Empty Spam

Compose/send: Blind Mailbox, Compose Email, Compose Save as Draft, Compose Drafted Email, Send Response, Response Save as Draft, Send Drafted Response, Forward Email

Read/retrieve: Get Email Conversation, Get Email History List, Get Email Information, Get Ticket Note List, Get Contact Information

Notes/contacts/comments: Load All Ticket Comments by User ID, Load All tbl_Contacts by Org ID, Contact Insert, Contact Update, Note Insert

Canned content (agent-side): Load Reboot Node tbl_Category_Canned_Letters_Responses_Agent Console, Load Node by ParentID_Canned_Responses_Agent Console

Monitoring triggers: Load All tbl_EmailLive Monitoring Trigger, Load All tbl_Sup Email Live Monitoring Trigger

Note on naming: several of these endpoint names directly expose internal SQL table names (tbl_EmailLive, tbl_Contacts, tbl_Category_Canned_Letters_Responses_Agent) — a sign this API evolved organically alongside the database schema rather than being designed as a clean public contract. Useful context if you're reverse-engineering behavior: the endpoint name often tells you the literal backing table.

4. Chat/Email Data API

Doc root: /ice/documentation/introduction-2/ Smallest and most focused of the three — this is the reporting/analytics API, i.e. the programmatic backend for everything under Admin → Reports in the User Manual. Structure: Authenticate → Chat Data APIs (18) → Email Data APIs (7).

4.1 Authenticate

Single endpoint, same Token-based pattern as the other two products' Login.

4.2 Chat Data APIs (18 endpoints)

Get Login Logout Details by SkillID, Get Canned Answers, Get Chat Averages, Get Chat Transcript Data, Get Call Center Data, Get Agent Performance Data, Get Prechat Survey Data, Get Operator Survey Data, Get Offline Survey Data, Get Exit Survey Data, Get In-Chat Survey Data, Get Chat Volume Summary by Account, Get Chat Volume Summary by Date, Get Campaign, Get Sub-Campaign, Get Survey Type, Get Users, External Chat Data API – Metadata

Every one of these maps directly to a report listed in User Manual → ICE Admin → Reports → Chat Reports (Canned Answers, Chat Averages, Call Center, Operator Performance, Volume Summary, Survey, etc.) — this API is how you'd build a custom BI dashboard instead of using ICE's built-in report screens.

4.3 Email Data APIs (7 endpoints)

Get Email Canned Answers, Get Email Survey, Get Ticket Volume Summary Data, Get Ticket Resolution Data, Get Ticket Resolution by Agent, Get Ticket History Data, Get Email Interval Data

Same relationship to User Manual → ICE Admin → Reports → Email Reports.

5. Practical Notes for Integration Work

  1. Token lifecycle isn't documented here (no explicit expiry/refresh endpoint beyond Login/Logout) — worth testing empirically or asking ICE support, since you'll need to know whether to cache and reuse tokens or re-login per session.
  2. Inconsistent casing (Message vs message, OrganisationID only on Login vs OrganizationID everywhere else) means defensive parsing (case-insensitive key lookup) will save you debugging time.
  3. GET vs POST isn't uniform — confirmed GetChatTranscript is GET while GetUserList/CreateUser are POST. Don't assume every Get* is GET; check each one you actually integrate against, or treat POST as the safe default and only use GET where explicitly documented.
  4. The three API products are not unified — separate Login/Token per product (Chat API auth ≠ Email API auth ≠ Data API auth, per the separate /authorization/, /authorization-2/, /authenticate/ paths). If your integration touches both chat and email, expect to manage two separate sessions.
  5. Email API's Supervisor/Agent category is where the real ticket-automation value is if you're building an integration (auto-routing, auto-tagging, bulk operations) — it's also the least standardized part of the API (raw table names, duplicate-looking endpoints), so budget extra time for verifying exact behavior against a sandbox/test org before relying on it in production.

6. What I'd Fetch Next (on request)

If you tell me which specific area you're integrating against, I'll do a full verified pass on just that slice — e.g.:

That keeps each follow-up crawl to a manageable, complete, fully-verified chunk instead of trying to boil the ocean again.