Developer centerAPI keys

Session Disposition

Overview

Technical name: Disposition · ActionType: 19 · Open in REST Explorer

The Disposition ActionType records the final outcome of a user session or interaction with your application, experience, or service.

A disposition closes the feedback loop for an interaction that began with events such as an Intelligent Call or Intelligent Page session.

By posting a session disposition, your application informs the Intelligent Handshake platform how the session ultimately resolved so performance, attribution, and optimization systems can learn from the result.

Getting Started

  1. Choose a transfer method
    • API (Recommended for real-time feedback)
    • Email (Simple, low-volume use cases)
  2. Select the Session Disposition fields relevant to your application
    • Session outcome (e.g., Convert, Abandon, Customer Service)
    • Session metadata (duration, timestamps, identifiers)
    • Optional context (campaign, agent, channel, etc.)
  3. Define transfer frequency
    • Real-time (recommended for continuous optimization)
    • Near real-time (every few minutes)
    • Batch (hourly, daily, or scheduled uploads)

For API (Real-Time Feedback)

  1. Request your Private API Key if one has not yet been assigned.
  2. Post Session Disposition to the User Action API at the end of each interaction.

For Email

  1. Register the sending email address with Intelligent Handshake®.
  2. Send a sample file for validation.
  3. Activate automated transfer.

When to Post a Session Disposition

A Session Disposition should be posted when a session has reached a meaningful outcome, such as:

  • A purchase was completed
  • A reservation was booked
  • A call was completed
  • A session ended without conversion
  • A session was abandoned
  • A support interaction was resolved
  • A user task ended

Think of this action as the final state of the session.

Session Stitching Modes

Session Disposition supports two ways to associate actions with a session:

  • Explicit session stitching: When the integration supplies a Session ID, all actions with that same Session ID belong to the same session. Session Start Timestamp is the effective time of each action and determines disposition order within the explicitly identified session.
  • Implicit session stitching: When no Session ID is supplied, actions are associated using Session Start Timestamp. Preserve the same Session Start Timestamp for every action belonging to the session.

Multiple Disposition Posts

Each accepted disposition is retained as part of the session history. For an explicit session, actions are grouped by Session ID and the disposition with the latest Session Start Timestamp is the current final outcome. For an implicit session, Session Start Timestamp stitches the actions together and Session Duration establishes their event progression. A delayed post for an earlier event does not replace a newer outcome, and an exact retry is treated as the same logical disposition.

Disposition codes are categories, not priorities, and must not be compared numerically. For example, a later Convert disposition may replace an earlier Cart Abandon or Fulfillment Hold disposition.

An order may post Fulfillment Hold (15), then Convert (10) three days later. In an explicit session, both actions use the same Session ID and Convert uses the later Session Start Timestamp. Session Duration describes the action or interaction duration; it should not include the three-day fulfillment wait.

How it Fits in the Interaction Model

Applications typically follow this pattern:

  1. Session Begins
    • Intelligent Call
    • Intelligent Page
  2. User Interaction Occurs
    • Browsing
    • Conversation
    • Transaction attempt
  3. Session Disposition Posted
    • Outcome of the session recorded

Session Start → User Interaction → Session Disposition

This structure enables:

  • campaign attribution
  • AI model feedback
  • performance analytics
  • journey optimization

Key Fields

Action Type (Encoded in ActionKey)

Use an ActionKey provisioned for Disposition, ActionType 19. The originating interaction can be a call, web visit, app visit, or TV touchpoint; reporting its outcome uses the Disposition ActionKey.

Session ID

Optional application-assigned identifier used for explicit session stitching. It must remain consistent across all actions belonging to that session.

Session Start Timestamp

Timestamp used for session stitching and action ordering. Without a Session ID, preserve the same timestamp across actions in the implicit session. With a Session ID, set it to the effective time of each action so later dispositions can replace earlier outcomes.

Example:

20240614T045120Z

Session Duration

Length of the session in milliseconds.

Example:

65000 (65 seconds)

Session Disposition Code

Represents the final outcome of the session.

See the complete Session Disposition Codes dictionary. Codes represent outcomes within Disposition (19), not separate ActionTypes.

Session Variant

Optional identifier used when running experience experiments or variants.

Example:

  • LandingPage-A
  • CheckoutFlow-B
  • AgentScript-3

Why Session Dispositions Matter

Posting session outcomes enables:

  • conversion attribution
  • experience optimization
  • AI training signals
  • campaign performance measurement
  • user journey analytics

Without session dispositions, the platform can observe activity but cannot learn the outcome of the interaction.

Request Examples

Submit the following JSON object to the shared User Action endpoint, using a provisioned Disposition ActionKey. These are illustrative events, not live credentials.

Minimal outcome

{
  "ActionKeyToken": "YOUR_ACTION_KEY",
  "Values": [
    {
      "SignalValueType": 400,
      "DataType": 0,
      "UnitType": 0,
      "Value": "2026-10-21T12:00:00Z",
      "OptionIDs": {}
    },
    {
      "SignalValueType": 402,
      "DataType": 0,
      "UnitType": 0,
      "Value": "10",
      "OptionIDs": {}
    }
  ]
}

Explicit session with duration

{
  "ActionKeyToken": "YOUR_ACTION_KEY",
  "Values": [
    {
      "SignalValueType": 400,
      "DataType": 0,
      "UnitType": 0,
      "Value": "2026-10-21T12:00:00Z",
      "OptionIDs": {}
    },
    {
      "SignalValueType": 401,
      "DataType": 0,
      "UnitType": 0,
      "Value": "65000",
      "OptionIDs": {}
    },
    {
      "SignalValueType": 402,
      "DataType": 0,
      "UnitType": 0,
      "Value": "10",
      "OptionIDs": {}
    },
    {
      "SignalValueType": 403,
      "DataType": 0,
      "UnitType": 0,
      "Value": "example-session-001",
      "OptionIDs": {}
    },
    {
      "SignalValueType": 43,
      "DataType": 0,
      "UnitType": 0,
      "Value": "12025550123",
      "OptionIDs": {}
    }
  ]
}

Supply the identity and destination signals required by your integration. With explicit correlation, reuse the Session ID; with implicit correlation, preserve the shared start timestamp as described above.

Fields and Results

InputApplicability
ActionKeyTokenRequired: Disposition (19).
SessionStartTimestamp (400)Required by this outcome contract; follow explicit/implicit stitching rules.
SessionDispositionCode (402)Required: choose a supported outcome code.
Session ID (403)Required when using explicit session stitching; otherwise omitted.
Identity, destination and contextual signalsConditional on integration and correlation requirements.

Use the Action Fields dictionary for definitions. Check the API result separately from the reported business outcome. A recorded disposition does not guarantee a new IH Score or immediate completion of downstream work.