Pass Multiple parameter to jitsi-meet apt package when installing via dockerfile RUN command

That would be the base URL that will be called when an event happens. The full URL would depend on the event.

For example, if you set:

api_prefix = ""

Then when a room is created it will make a POST call to

See the README for the full list of events and url paths it will use.

No, it will not use JWT.

Authentication is down to you. The typical use case would be that the API endpoint will be protected using some kind of header-based authentication and the headers can be added using the
api_headers config option.

For example, if you used the TokenAuthentication approach with the Django REST Framework, then once you have your token key to be used by the module, you could configure it as such:

api_headers = {
    ["Authorization"] = "Token 9944b09199c62bcf9418ad846dd0e4bbdfc6ee4b";

If you want to use any other kind of API auth, then you’ll need to modify the plugin yourself or run a custom web app locally that accepts the call from prosody and forwards it on to the actual API.

This same applies to the reservations plugin, except it only uses the /conference path. So if you set

reservations_api_prefix = ""

then API calls will be made to

My comments above re authentication applies to reservations module too.

Hello. Thank you for your time and reply. The JSON payload will be authenticated using the method you described above - Sure. But you also referenced a post in your previous post for using JWT as a authentication mechanism which can be used for generating tokens on Django end and validating the same on Jitsi prosody’s side before transmitting the JSON payload ? - Here is the statement from that referenced post

Users authenticate with your own app using whatever mechanism you want, and you decide what room they can join and what rights they have.
You can then generate them the appropriate JWT token and redirect them to the jitsi room

My Django backend is using the Open source stack : OkunaOrg/okuna-api: :robot: The Okuna Social Network API (

I’m building on top of this. They are using a JWT for authenticating users with their front end app.

I was referring to JWT authentication for user access to Jitsi, not the reservations/events APIs.

When your app route users to your Jitsi site, rather than have users having to re-authenticate with Jitsi, your app would already know the user is trusted and can generate a JWT token they can use to access the room in Jitsi.

To highlight the key points in my statement you quoted:

Users authenticate with your own app using whatever mechanism you want, and you decide what room they can join and what rights they have.
You can then generate them the appropriate JWT token and redirect them to the jitsi room

1 Like

Hello again,
So to summarize :

1.Your django app will handle user auth, and to initiate a call you’d generate the room name and JWT token and load the conference in an IFrame.

2.You can get call records back into the app by installing prosody plugins that send room events to your app API. This was briefly discussed in the following post

So I will have to do both the above steps as far as I’ve understood - One for User_Auth and one for events synch and reservation ?

I’m not sure what you mean by “the above steps”. JWT auth, event-sync, and reservations are all independent things that achieve different goals. You can implement any one without the others and they would still do what they are meant to do.

Whether you need them or not really depends on what you’re trying to achieve.

  • JWT was proposed because is the simplest way to integrate Jitsi within another app by delegating user authentication to your app.

  • I suggested the event-sync module because you said you wanted to “manage call records in django alongwith user records”

  • The reservations module I presume you gather from my linked post. That is only required if you want more control over what rooms are allowed to be created and when.

You may need all of these for what you want to build, or only some. But the way you set up each one is independent of the others.

Might I suggest you first tackle the JWT auth bit and get an initial integration with you app working first, then revisit the other aspects later on?

This is my precise use case shawn.
1.I’m dunning Docker containers of Jitsi.
2.I’ll be using the lib-jitsi-meet api for my front end for Flutter - Mobile & Web.(@saghul) gave this as one of the options on my specific use case of custom mobile and web apps.
3.I need to run Jitsi on the backend running concurrently with my Django api with
a. User authentication handled by Django.
b. Meeting & Call records synching with Django API.

→ So the use case from a backend perspective is - Only authenticated users can start a meeting → correct me if my wrong but my front end apps have to hit the the jitsi docker backend and the then django backend for token generation and redirected to Docker Jitsi to initiate the meeting ?

My current understanding is Frontend app first hits the jitsi docker & then Django api for torkn generation —> Authenticated users are passed on to the Jitsi docker with the JSON payload and the meeting starts/ends etc. Further to this, independently, the events synch module will pass data back to the Django api as per the conditions set.

Personally, I would keep the integration as simple as possible and get Jitsi involved only for what it does best which is to handle the Video Conferencing part. In other words, handle all the user journey in your app and embed/connect to jitsi for the VC portion.

Here’s a simplified sequence diagram:

And the way event_sync and reservations gets involved is largely independent of how you integrate your app with Jitsi. Although if you do use the reservations module, your frontend will may need to handle error conditions e.g. when room expires and gets closed, or if the reservation checks fail.

For completeness, here’s another simplified sequence diagram:


Thank you for this. Cheers.