How to Start a Kaltura Session using the TestMe Console

To start a Kaltura Session

  1. Go to:
  2. Select Session from the Select Service drop-down list.

  3. Select Start from the Select action drop-down list.

Log in the KMC and retrieve the Partner ID and Administrator Secret.

To retrieve information from the KMC

  1. Click the Settings button and then Integration settings. 
  2. Save the following information:(actual information is blurred intentionally)
    1. Partner ID.
    2. Administrator Secret.

      *The numbers and letters are different for each Partner.*

  3. Return to the TestMe Console and paste the Partner ID and Administrator Secret information, and change the type field from USER to ADMIN.

  4. Click Send.
     The output results should contain the KS, a Kaltura Session key.
  5. Copy the KS string and put it in the Kaltura API session (string) field.

    That's it! Your API console is ready to make new API calls now.


The Kaltura API is REST based and stateless. Every call (request) made to the Kaltura API requires an authentication key, the Kaltura Session (aka KS), identifying the account on which the action is to be carried, the authenticated user and its role.

A Kaltura Session can be initiated in 3 different ways:

  1. Calling the session.start action, providing the account Partner ID and an Admin or User secret key.
    $ks = $client->session->start ($adminSecret, $anyUserName, KalturaSessionType::ADMIN, $partnerId);  
  2. Calling the user.loginByLoginId action, providing a User login ID (email), its Password and the account Partner ID.
    $ks = $client->user->loginByLoginId($loginId, $password, $partnerId);  
  3. Creating a session locally - Combine all the Kaltura Session details, and sign them using the shared secret.
    $ks = $client->generateSession($adminSecret, $userId, $type, $partnerId);  

The above examples are using the Kaltura PHP5 Client Library.


Important Security Notes: 

  1. ADMIN type KS provides super admin priveliges to the Kaltura account. If you're creating an application where the session will be exposed to the end-user, make sure that you are using a USER type KS and not ADMIN type. Exposing an ADMIN type KS in non-administrative context will expose your Kaltura account to risks of being used by malicious users with unrestricted access.
  2. Sharing the account API secret keys with 3rd party vendors should be avoided, as secret keys can not be regenerated or blocked for access. Kaltura API based application developers and 3rd party application vendors should build their application to leverage the user.loginByLoginId API and ask the publisher for their email, password and account Id (aka partnerId). Users can be easily created, removed or blocked and their password can easily be changed. 


In This Article
Was this article helpful?
Thank you for your feedback!