Core capabilities

• Session initialization with optional conversation history and optional routing to a specific user/team via specific_user_id.
• Chat messaging with delivery/read acknowledgments and typing indicators.
• Voice / video calling including accept/reject flows, mute/unmute, start/end lifecycle events.
• Screen sharing with accept/reject and start/end events.
• Cobrowsing start/stop plus custom cobrowse data push and license-related events.
• Document sharing via URL-based transfer (HTTPS recommended).
• Location sharing via latitude/longitude plus a static map image URL.
• External data push to enrich sessions (product, geo, device, analytics fields, etc.).
• Custom CSS via external CSS file URL applied to the widget.
• SDK version retrieval via a version method and callback event.

High-level security architecture (conceptual)

The documented security architecture follows a layered model:

• Client layer: End user browser & host web application; widget SDK runs inside the host page.
• Transport layer: HTTPS (TLS) and WSS/HTTPS used for network communication.
• Widget gateway: API key validation, domain/IP restrictions, rate limiting & throttling, request authentication.
• Session & identity layer: session token validation, unique user mapping, message sequencing, replay prevention.
• Communication services: chat; voice/video (WebRTC / LiveKit); screen share / cobrowse; document & location exchange.
• Security & compliance controls: TLS encryption in transit; PII masking & redaction; consent enforcement; file validation & scanning; audit logging.
• Backend & data storage: encrypted session data and transcripts; access-controlled logs; configurable retention policies.

Session & chat methods

Start session

Initializes a new session with a chatbot and attempts to connect the session to a live agent. Accepts an input JSON object which may include prior conversation history.

• Method calling: let return_value = jodosessioninit();
• Return value: Not specified in source document
• Primary callback media/eventtype: session / (e.g., widgetInit, plus allocation states)

{
  "eventdata": {
    "type": "WS",
    "media": "session",
    "eventtype": "widgetInit",
    "systemcallid": "56238452374573443",
    "loadmethod": "custom",
    "startwithmedia": "chat",
    "timestamp": "2025-08-21 11:52:49",
    "msg": "Session Connected to Emma"
  }
}

Send chatbot data

Pushes chatbot context (visitor identity and conversation array) into the session.

• Method calling: let return_value = ChatBotDataPush(data);
• Input: data is a JSON array.
• Return codes: 0 (Empty data), 1 (Success), 3 (Invalid JSON)
• Callback: session / ChatBotDataPush

{
  "eventdata": {
    "media": "session",
    "eventtype": "ChatBotDataPush",
    "messageid": "56238452374573443",
    "timestamp": "2025-08-21 11:52:49"
  }
}

Send chat message

Sends a chat message through the active session.

• Method calling: let result_value = jodoInitBOT.SendChatMessage("Hello");
• Input: Text (max 255 characters)
• Return codes: 1 (Success), 2 (Invalid chat data), 3 (Message exceeds 255 characters)
• Callback: chat / messagesent

{
  "eventdata": {
    "media": "chat",
    "eventtype": "messagesent",
    "Status": 1003,
    "timestamp": "2025-08-21 11:52:49",
    "messageid": "56565gjhkhkj56t"
  }
}

End session

Ends the current session.

• Method calling: jodoInitBOT.EndSession();
• Callback: session / ended

{
  "eventdata": {
    "media": "session",
    "eventtype": "ended",
    "status": 1003,
    "timestamp": "2025-08-21 11:52:49",
    "msg": "Session Ended"
  }
}

Send message read acknowledgments

Sends read receipts for multiple messages at once by passing an array of message IDs.

• Method calling: jodoInitBOT.SendMessageReadACK(messageidsArray);
• Parameters: messageidsArray (Array<string>) – An array of unique message IDs to mark as read.
• Return codes / callback: Not specified in source document

Voice, video, screenshare methods

Start voice call

• Method calling: jodoInitBOT.StartVoiceCall();
• Return codes: 1 (Success), 2 (Failure)
• Callback: voice / start

End voice call

• Method calling: jodoInitBOT.EndVoiceCall();
• Callback: voice / End

Start video call

• Method calling: jodoInitBOT.StartVideoCall();
• Callback: video / start

End video call

• Method calling: jodoInitBOT.EndVideoCall();
• Callback: video / End

Start screensharing

• Method calling: jodoInitBOT.StartScreenshareCall();
• Callback: screenshare / start

End screensharing

• Method calling: jodoInitBOT.EndScreenshareCall();
• Callback: screenshare / End

Start voice call directly

Starts a voice call directly without following a chat-first flow.

• Method calling: jodoInitBOT.StartWithVoiceMedia();
• Callback: voice / start

Start video call directly

Starts a video call directly without following a chat-first flow.

• Method calling: jodoInitBOT.StartWithVideoMedia();
• Callback: video / start

Accept / decline voice call request

• Accept: jodoInitBOT.AcceptVoice();
• Decline: jodoInitBOT.DeclineVoice();
• Callback: voice / accepted or rejected (request events documented); sample blocks in source show inconsistencies and should be treated as illustrative only.

Accept / decline video call request

• Accept: jodoInitBOT.AcceptVideo();
• Decline: jodoInitBOT.DeclineVideo();
• Callback: video / accepted or rejected

Accept / decline screenshare request

• Accept: jodoInitBOT.AcceptScreenShare();
• Decline: jodoInitBOT.DeclinescreenShare();
• Callback: screenshare / accepted or rejected

Document, location, and external styling/data methods

Send document (URL-based)

Sends a document by URL.

• Method calling: jodoInitBOT.SendDocument(docURL);
• Input: docURL (Text) – URL of the document.
• Return codes: 1 (Success), 2 (Invalid URL)
• Callback: documentpush / sent

Send location

Sends a location using latitude, longitude, and a static map image URL.

• Method calling: jodoInitBOT.SendLocation(latitude, longitude, staticMapImage);
• Return codes: 1 (Success), 2 (Invalid URL)
• Callback: locationpush / sent

Apply external CSS

Loads an external CSS file URL to customize the widget UI styling.

• Method calling: jodoInitBOT.GetExternalCSS(CSS_FILE_URL);
• Parameters: CSS_FILE_URL (string) – Full URL path to the custom CSS file.
• Return codes / callback: Not specified in source document

jodoInitBOT.GetExternalCSS("https://jodostaging.avhan.com:4443/widget_test/chatbotext.css");

CTA clicked

• Method calling: jodoInitBOT.CTAClicked();
• Return codes / callback: Not specified in source document

Send external session data

Pushes external data into the session (product, geo, analytics, etc.).

• Method calling: jodoInitBOT.sessionextdata(data);
• Return codes / callback: Not specified in source document

jodoInitBOT.sessionextdata({
  "name": "Satej",
  "conversation": [
    {
      "product": "Canon EOS 1300D 18MP Digital SLR Camera",
      "product_price": 23385,
      "products_available": "Camera, Electronics, Kids, Phone, Sports,Books and moreCamera, Electronics, Kids, Phone, Sports,Books and more",
      "city": "Mumbai",
      "state": "Maharashtra",
      "zip_code": "400099",
      "google_analytics": 0,
      "location_type": "GEO",
      "gps_postal_code": "400028",
      "gps_country": "India",
      "gps_state": "Maharashtra",
      "gps_city": "Mumbai",
      "gps_country_code": "IN",
      "gps_latitude": 19.0251008,
      "gps_longitude": 72.843264,
      "gps_formatted_address": "12, West, Kasaravadi, Dadar, Mumbai, Maharashtra 400028, India",
      "startmedia": "chat",
      "startmediaid": 8
    }
  ]
});

Get SDK version

• Method calling: jodoInitBOT.getVersion();
• Callback: session / SDKVERSION
• Return codes: Not specified in source document

Cobrowsing methods

Start cobrowsing

• Method calling: jodoInitBOT.StartBrowsing();
• Callback: cobrowse / start

Stop cobrowsing

• Method calling: jodoInitBOT.StopBrowsing();
• Callback: cobrowse / stop

Send custom cobrowse data

Sends custom data during a cobrowse session.

• Method calling: jodoInitBOT.setCustomCoBrowseData(data);
• Callback: cobrowse / customdata_success (or customdata_fail)

jodoInitBOT.setCustomCoBrowseData({
  "Secretdat": "fgdufvhsdfviuhsdfkvsdfkvjsbdfkjvbsdf"
});

Transport & network security

• All communication between the client SDK and servers MUST use HTTPS (TLS 1.2 or higher).
• WebSocket connections are established over secure WebSockets (WSS).
• Plain HTTP or unsecured WebSocket connections are not supported.
• Certificate validation is enforced by default to prevent man-in-the-middle (MITM) attacks.

Authentication & authorization

akey (API Key) and skey (Service Key) are unique credentials issued by JodoWorld and identify the integrating application and authorized services.

• API keys must never be hard-coded in public repositories.
• Keys should be domain restricted and IP restricted (where applicable), and rotated periodically.
• Recommended architecture: generate short-lived, signed session tokens from your backend and use the backend-issued token to initialize the widget instead of exposing long-lived keys directly.

Session security

• Each session is uniquely identified using systemcallid and messageid.
• Sessions are ephemeral and terminate on explicit EndSession(), network disconnect, timeout, or system failure.
• Session IDs are validated server-side.
• Replay attacks are mitigated using unique message IDs and event sequencing.
• Session re-use across users is not permitted.

User identity & data validation

• uniqueuserid is used for session routing and agent mapping.
• Encoding (e.g., Base64) is used for transmission but does not constitute encryption.
• Recommendation: use cryptographically signed identifiers (JWT or equivalent) with expiry timestamps and audience/issuer validation.
• Avoid transmitting raw customer identifiers when not required.

Data protection & privacy

• All payloads are encrypted in transit using TLS.
• The SDK may transmit PII, location data, device/browser metadata, and conversation transcripts.
• Best practice: minimize PII transmission, mask/redact sensitive fields (passwords, OTPs, government IDs, payment details), and avoid logging sensitive data on the client side.

Media security (voice, video, screenshare) & cobrowsing controls

• Media sessions require explicit user consent through accept/reject events.
• Media streams are session-bound, time-limited, and automatically terminated on session end.
• Host application should mask sensitive UI elements (passwords, OTP fields) during screenshare and cobrowsing.
• Cobrowsing should be restricted to allowed domains and pages.
• Users can terminate screenshare or cobrowse sessions at any time.

Document & file transfer security

• Document sharing is URL-based and must use secure (HTTPS) endpoints.
• The SDK does not store documents permanently on the client.
• Recommended controls: file type allowlists (PDF, PNG, JPG), file size limits, malware scanning, and time-bound or signed URLs.
• Avoid sharing publicly accessible URLs containing sensitive data.

Rate limiting & abuse prevention

• Server-side rate limiting is applied to session creation, message sending, and media initiation.
• Recommended enhancements: client-side throttling for rapid message submission and repeated call initiation attempts; monitor abnormal patterns for abuse detection.

Error handling & secure failures

Security-relevant events include APINotConnected, APITimeout, WebSocketNotConnected, and invalidLicenseKey.

• No sensitive data is exposed in error responses.
• Sessions are safely terminated on critical failures.
• Clients should display generic error messages to users.

Logging, auditing & compliance

• System events and session activity are logged for troubleshooting, auditing, compliance, and security monitoring.
• Recommendations: define log retention policies, mask PII in logs and analytics, ensure compliance with applicable regulations (DPDP, GDPR).

Key security design principles

• Zero Trust at client layer
• Least privilege access
• Consent-driven media sharing
• Short-lived sessions
• Defense-in-depth controls
• Audit-first architecture

Security FAQs

Q1. How is data secured during transmission?

All communication is encrypted using HTTPS (TLS 1.2+) and WSS. Unencrypted connections are not supported.

Q2. Are API keys exposed on the client side?

API and service keys are required for SDK initialization. For enterprise deployments, use backend-issued short-lived session tokens, apply domain/IP restrictions, and rotate credentials periodically.

Q3. How are users authenticated and identified?

Each session is associated with a unique session identifier (systemcallid) and a unique user identifier (uniqueuserid). For higher security, use signed identifiers (JWT or equivalent) with expiry and validation checks.

Q4. Is any Personally Identifiable Information (PII) stored?

The SDK may process PII only when explicitly provided by the integrating application (e.g., name, location, device metadata, chat transcripts). Best practice: minimize PII collection, mask sensitive fields, avoid storing unnecessary personal data.

Q5. How is voice, video, and screensharing secured?

Media requires explicit user consent (accept/reject), is session-bound and time-limited, and terminates automatically when the session ends. Screensharing/cobrowsing should exclude sensitive fields (passwords, OTPs).

Q6. Can agents access user data without consent?

No. Interactive features require explicit user initiation or acceptance. Users can terminate sessions at any time.

Q7. How is document sharing secured?

Documents are shared via secure HTTPS URLs. Recommended controls: file type allowlisting, file size limits, malware scanning, time-bound/signed URLs. The SDK does not permanently store shared documents on the client.

Q8. How does the platform prevent session hijacking or replay attacks?

Controls include unique session IDs per interaction, message sequencing and validation, and automatic session termination on disconnects or errors.

Q9. Are logs and audit trails maintained?

Yes. System events, session activity, and error conditions are logged for troubleshooting, audit/compliance, and security monitoring. Logs should be access-controlled, masked for sensitive data, and retained per defined policy.

Q10. How does the SDK support DPDP / GDPR compliance?

The SDK supports data minimization, purpose limitation, consent-based processing, and secure data handling. The integrating organization remains the Data Fiduciary / Controller and defines retention periods, erasure workflows, and cross-border transfer policies.

Q11. What happens in case of a security incident?

For API failures, network issues, or security-related errors, the SDK terminates sessions safely, does not expose sensitive data, and triggers specific error events for handling. Incident response and regulatory notifications follow organizational policies.

Q12. Is the SDK compliant with ISO 27001 or SOC 2?

The SDK architecture and controls are aligned with ISO 27001 and SOC 2 principles. Formal certification depends on the hosting environment and operational controls of the deploying organization.

Q13. Can security controls be customized for enterprise deployments?

Yes. Enterprise deployments can enable custom authentication mechanisms, restricted domains and IPs, enhanced logging and monitoring, and custom data masking rules.

Q14. Who owns the customer data?

The integrating organization retains full ownership of customer data. The platform processes data only to deliver requested services and does not use it for unrelated purposes.

Q15. How often are security controls reviewed?

Security controls are reviewed periodically, updated to address emerging threats, and improved through monitoring, testing, and audits.