URL-Based CRM Integration with Ameyo

overview url‑based toolbar integration invokes crm pages inside ameyo’s embedded browser at defined lifecycle events—login, connect, preview, and dispose—passing identifiers like session, campaign, call, and user extension as url query parameters to maintain context across pages the approach supports multiple disposition patterns (crm‑only, ameyo‑only, forced dispose, or dual) and recommends disposing in crm before ameyo to prevent premature tab closure and agent wrap delays session management can be unauthenticated, cookie‑based, or single sign‑on, with sso attaching the crm session token to all subsequent crm urls and issuing a logout on agent sign‑out key benefits seamless screen‑pop across inbound, outbound, manual, preview, and callback flows by invoking crm pages with call and agent context parameters, reducing context switching for agents flexible disposition handling with crm‑initiated dispose callbacks or ameyo forced/dual dispose, ensuring agents are freed for the next call without waiting for wrap time when crm notifies ameyo streamlined session experience via cookie‑based or single sign‑on options, appending the crm session token to all customer/preview/dispose urls and invoking crm logout at agent sign‑out simple, low‑overhead integration using https get query parameters for knowledge base, customer, preview, and dispose urls configured per campaign, avoiding heavy sdks or custom adapters end‑to‑end workflow control from the crm using built‑in apis manual dial, dispose‑and‑manual‑dial, and voice log download, enabling dialing, dispositioned redials, and recording retrieval within the crm queue‑aware crm behavior using queueid and queuename to render different pages or processes per queue for more tailored agent guidance in inbound scenarios consistent traceability with identifiers like sessionid, campaignid, crtobjectid, usercrtobjectid, and customerid for linking crm records to ameyo call and recording artifacts security alignment through https support and identity mapping where crm user‑id equals ameyo user‑id for sso while ameyo continues to authorize by ameyo roles web based third‑party crm integration via configurable urls invoked at agent login, call connect, and disposition events manual dial api to dial a specific number from crm for a specific agent session and campaign dispose and manual dial api to dispose a call and immediately redial from crm with the appropriate campaign disposition voice logs api to download recordings for a call by ameyo call identifier in wav or mp3 formats optional sso with crm managed authentication and session propagation into ameyo url query parameters how it works ameyo server handles agent activities and call context while emitting configured crm and knowledge base urls at defined lifecycle events ameyo client hosts the agent user interface, including an embedded browser for knowledge base and crm tabs that receive parameterized urls from the server crm browser renders third‑party crm pages and persists navigation while in call, driven by url parameters including session and call identifiers crm server provides customer data, accepts login/logout for sso, and may receive dispose callbacks from ameyo integration approach agent login ameyo sends a preconfigured knowledge base url to the embedded browser for agent reference at login, optionally requiring authentication as per crm design agent call handling url based screen‑pop occurs for incoming, auto‑dial, manual dial, preview, and callback scenarios with call identification and agent context parameters agent call disposition supported patterns include crm only, ameyo only, forced dispose from ameyo (with crm notification), or dual entry, with the recommendation to dispose in crm before ameyo to avoid crm tab closure agent ux overview the interface includes a telephony palette, a workbench with tabs, an embedded knowledge base, and an embedded crm tab that is populated per call and may be read‑only in preview flows based on configured urls when a call is disposed in ameyo, the crm tab can be closed by the client as the agent returns to wait status for the next call, so crm disposition and data save should occur first if using dual entry core communication flows and functions url formats general \<protocol> //\<domain>/\<port>?\<key1>=\<value1>&\<key2>=\<value2>… with protocol typically http or https; use https where possible for transport security knowledge base url parameters userid and sessionid for identification and continued session parameter updates from ameyo customer url parameters sessionid, campaignid, crtobjectid, usercrtobjectid, userid, customerid (outbound optional), phone, queueid, queuename as applicable preview url identical to customer url but triggered during preview to allow crms to render read‑only views if desired dispose url parameters sessionid, campaignid, crtobjectid, usercrtobjectid, userid, customerid, disposition, and dispositionattribute for callbacks where applicable session management no authentication crm simply renders data on screen pop, not commonly used due to security constraints cookie based authenticate at login (e g , using knowledge base url) and rely on browser cookies within the embedded browser across the session; ensure crm logout before ameyo logout to avoid stale sessions single sign on authenticate via crm‑provided http api at ameyo login to obtain crmsessionid and append it as query parameters on subsequent crm/knowledge base urls; send logout to crm at ameyo logout crm url configuration admin configures crm base url per campaign as \<domain port> //\<crm server ip>/\<crmdirectory>/\<crmpage> in administrator settings on call connect, ameyo appends dacx parameters via get to form \<domain address> //\<crm server ip>/crmdirectory/crmpage?\<key1>=\<value1>&…; crms should read via get expected params sessionid sessionid campaignid campaignid crtobjectid crtobjectid usercrtobjectid usercrtobjectid userid userid customerid customerid phone disposition handling ameyo expects a disposition indication to return the agent to wait and enable the next call, which can be driven from crm via a dispose callback url or via ameyo force dispose with prior crm save disposition url format http //ameyo server ip 8888/ameyorestapi/disposecallforuser with request data including campaignid, sessionid, crtobjectid, usercrtobjectid, customerid, phone, userid plus disposition code and optional disposition attr for callbacks disposition attr examples include local \<date time>, customer \<date time>, after \<date time>, and selfcallback flags to control scheduling semantics and ownership a sample shows callback scheduling with session identifiers and selfcallback=true; ensure the disposition code exists in the campaign’s disposition plan curl location 'https //demoprawin ameyoemerge in 8887/ameyorestapi/voice/disposecallforuser' \\ \ header 'content type application/json' \\ \ header 'authorization 12345abc' \\ \ data '{ "userid" "vaptuser1", "dispositioncodename" "sale", "dispositionparams" {"isselfcallback" "false", "callbacktime" "", "phone" "7004281599"}, "requestid" "8989898989", "notes" "" }' single sign on api provide a single crm api endpoint at http //\<crm server ip> \<port>/\<some path>/login logout accepting post parameter request for both login and logout commands login send command=login with userid and password; on success receive crmsessionid to be appended on subsequent crm requests; failures return status=failed with message logout send command=logout with crmsessionid when the agent logs out of ameyo; crm should terminate the crm session and return status notes authorization remains ameyo‑role based and ameyo does not continuously validate crm session freshness; crm user‑id should equal ameyo user‑id for role alignment manual dial api purpose initiate an outbound call from crm for a specific agent session within a campaign via ameyo web access endpoint format http //\<applicationserverip> \<port>/ameyowebaccess/command/?command=clicktodialwithtokenasync \&data is passed in request body with content type application/json required parameters campaignid, phone, and customerrecord when the campaign uses a custom table or primary key other than phone1 response json with result and reason, returning success or failed with an explanatory reason on error sample request token will be shared by support or professional services team curl location 'https //ameyoserverdomain ameyoe in 8887/ameyowebaccess/command/?command=clicktodialwithtokenasync' \\ \ header 'hash key ameyogeneratedtoken' \\ \ header 'requesting host setup ameyo net' \\ \ header 'policy name token based authorization policy' \\ \ header 'content type application/json' \\ \ data '{ "userid" "agent", "campaignid" "1", "shouldaddcustomer" false, "phone" "9911337923", "additionalparams" { "recordid" "0015g00000z04cfaab" } }' sample success response json{ "result" "success", "reason" "success" } dispose and manual dial api purpose dispose the current call in ameyo and immediately redial from crm with an appropriate disposition tied to the campaign endpoint format http //\<applicationserverip> \<port>ameyorestapi/voice/disposeandmanualdial & data is sent in request body required parameters campaignid, usercrtobjectid, crtobjectid, customerid (for customer context), dispositioncode, and phone response json with result and reason, with detailed error responses for missing disposition assignment, invalid crtobjectid, or invalid sessionid sample request and success response curl location 'https //demoprawin ameyoemerge in 8887/ameyorestapi/voice/disposeandmanualdial' \\ \ header 'sessionid;' \\ \ header 'content type application/json' \\ \ header 'cookie metadata =0ab6aca4 8f2d 4b85 98a9 9730aed1f6e8' \\ \ data '{ "campaigncontextid" 8, "usercrtobjectid" "d202 5b4d83c1 ses agent vmvuggpb 1 uce 5", "crtobjectid" "d202 5b4d83c1 vce 5", "dispositioncode" "sale", "phone" "465456", "customerid" " 1", "requestid" "dcf7eec5 0c8f 86c1 8d2f c9f31db9ae8c" }' { "result" "success", "reason" "success" } sample failure responses disposition not in plan, invalid crtobjectid, invalid sessionid with status and reason fields for diagnostics voice logs api purpose download voice recordings by ameyo call identifier in a specified format (wav default, mp3 supported) via http commands command downloadvoicelog with json‑encoded data including crtobjectid and optional targetformat, passed via get or post request parameters request sample curl location globoff 'https //demoprawin ameyoemerge in 8887/ameyowebaccess/command?command=downloadvoicelog\&data=%7b%22crtobjectid%22%3a%22d865 68dbb572 vce 22%22%2c%22targetformat%22%3a%22mp3%22%7d' behavior on success, the voice log download starts; failures return a json message indicating the recording could not be found parameter reference sessionid unique ameyo agent session identifier used across communications and url query strings campaignid identifier for the current campaign for routing and process identification crtobjectid unique call identifier in ameyo for linking voice logs and crm records usercrtobjectid identifier for the specific active agent voice extension when multiple are possible userid unique ameyo user identifier, also used to align sso identities where crm user‑id should match customerid unique customer record identifier in ameyo for outbound and contact uploads when available phone caller id or dialed number provided to crm and used in dispose and dialing commands queueid/queuename inbound routing context to allow crm page variation per queue disposition/dispositioncode code configured in the campaign’s disposition plan that must match exactly for successful dispose dispositionattribute attributes for callback scheduling such as local, customer, after, and selfcallback flags crmsessionid session token issued by crm on sso login and appended to subsequent crm urls until logout configuration and examples configure crm and knowledge base urls in administrator campaign settings and ensure crms read parameters via get when the url is thrown on call connect example screen‑pop shows sugarcrm integrated with ameyo via url based method using the embedded crm browser a complete sample dispose url illustrates callback scheduling and session scoping across user and call identifiers for traceability and workflow actions operational notes if crm handles disposition but does not notify ameyo, the agent will not be freed until wrap timeout; ensure the crm invokes ameyo’s dispose url or rely on ameyo forced dispose with prior crm save for cookie based sessioning, authenticate early via knowledge base url and advise agents to logout of crm before logging out of ameyo to avoid stale cookies in the embedded browser for sso, remember that ameyo uses crm api only for authentication and continues to authorize by ameyo roles; ameyo does not continuously validate crm session freshness sample json for sso login request and response structure with method = post & content type application/json {"password" "agent","userid" "agent","command" "login"} login request and response structure with method = post & content type application/x www form urlencoded request={"password" "admin","userid" "admin4","command" "login"} sso api response should be in below format with method = post & content type application/json {"status" "success","crmsessionid" "crm sess norah 123 434343","message" "message"} logout request and response structure response includes command=logout with crmsessionid, and status indicates success or failure for crm session termination method = post request { "command" "logout", "crmsessionid" "crm 1234 hjsdch" } response { "status" "success/failed", "message" "" } security considerations use https for crm and dispose endpoints when available since the url format supports both http and https, and include only necessary identifiers in query strings to minimize exposure align identities across ameyo and crm for sso by keeping the same user‑id, and ensure crm sessions are invalidated on ameyo logout via the logout command to avoid orphaned sessions testing checklist validate knowledge base url loads at agent login and, where applicable, establishes cookie or sso‑based sessions with crm confirm customer and preview urls carry correct session, campaign, call, and user extension identifiers and render expected crm views, including read‑only behavior for preview exercise all disposition modes and verify agent state returns to wait upon crm‑initiated dispose with valid codes configured in the campaign’s disposition plan execute manual dial, dispose and manual dial, and voice logs apis, asserting success responses and enumerated failure responses for invalid disposition, crtobjectid, and sessionid cases