Please note: All new registrants to the Panopto Community Forum must be approved by a forum moderator or admin. As such, if you navigate to a feature that is members-only, you may receive an error page if your registration has not yet been approved. We apologize for any inconvenience and are approving new members as quickly as possible.
Options
viewers thru the API
Yossi Raucher
Tyro
in API
Is it possible to get the number of viewers of every session, thru the API ?
0
Answers
Yes Yossi, this is possible. There are several ways it could be done, but probably the best is to use the Session usage report. You can read more about usage reports on this support article: https://support.panopto.com/s/article/System-Usage-Report-Fields
Please note especially the note at the top about the API, reproduced here:
API documentation regarding report management is available here: IUsageReporting Interface. Example code for this in Python is available at https://github.com/Panopto/python-soap and for C# is available at https://github.com/Panopto/UsageReportingDownloadsExample.
Thanks,
Mark
Thank you Mark.
We built new API client (type: Server Application), got an ID and Secret key, got the token and then,
tried to retrieve sessions information thru the GET command.
There is no error message but only the next answer:
{"Results":[]}
What can be the problem?
Yossi,
I assume you tried to call REST API method GET /api/v1/sessions/{id} or /api/v1/sessions/search. Those methods require user authentication.
Server Application client can only create tokens with no user associated. The access tokens created for a Server Application client would not be authorized for any API calls that require a user or user permission. You need to use other types of OAuth2 token for sessions API, and most of REST API. You may find more explanation at section 1.2.c of this document: https://support.panopto.com/s/article/support-panopto-com-s-article-oauth2-client-setup
I also want to point out that IUsageReporting which Mark pointed out is SOAP API. OAuth2 token does not work for SOAP API. Authentication code for SOAP API is included in the sample code which Mark pointed out.
Thank you Hiroshi.
We don't want the user to log-in to Panopto.
We want to retrieve data by ourselves (IT department).
We are getting the OAuth2 token with no problems.
The only problem is that the results answer is empty and I don't know why.
Yossi,
Server Application type does not work with REST API of your interest. That's the reason why. Please read section 1.2.c of this document: https://support.panopto.com/s/article/support-panopto-com-s-article-oauth2-client-setup about this.
For your scenario, I recommend to create a new Panopto user who has administrator privilege and get other type of Oauth2 token with that user.
Is it possible to get the Usage Report thru SOAP API?
Is it Possible to get Folder/session information (like in the Usage Reports and more fields) thru SOAP API?
Can I have an example how to do it (and please don't send me to look at the documentation) ?
Please help us with a real example. If we could meet on Zoom - It will be great.
Thanks.
We were able to connect and get information from the API about sessions.
But we received information only about recordings that are open to everyone.
The user with whom we have the information has admin permission in Panopto.
Is there a need for special permissions to receive information about the rest of the recordings ?
It is by deign that you may get the publicly accessible session unless you authenticate as an user. To get the system wide information, you need a user who has administrative privilege.
Hi,
We retrieved 2 API data: Folders and Sessions.
It seems that we can’t retrieve data by a range of dates. It’s all or nothing. Is that true?
It doesn't make sense to retrieve all the records every day (it takes many hours) and not to retrieve just yesterday's recordings.
Is it possible to retrieve data by a range of dates?
Thanks, Yossi
Hi Yossi,
We have date filter on SOAP API GetSessionsList.
We do not have it on REST counterpart. We may consider adding it to REST in the future.