Sessions Offered and Sessions Remaining

I’m trying to find API access to the Sessions Offered and Sessions Remaining fields of pricing plan subscriptions. I’ve looked through the documentation for bookings, pricing plans, and orders. I see that there is something called a subscriptionId, but there doesn’t seem to be an API to use to get details about a subscription. The queries for orders and pricing plans don’t return either of these values as far as I can tell.

Clearly this information exists, because I can go to the subscriptions dashboard page and look at the details for a subscription, where both numbers are displayed. I can also adjust the number of sessions offered for a specific subscription from that dashboard page. Also, when I define a Pricing Plan in Wix there is a place to enter the number of sessions offered.

I’m thinking there must be a way to access this information via JS and I’m just missing it. Can someone please help direct me there?

Thanks.

This post should point you in the right direction:

Wix doesnt have an API where we can view remaining sessions.

There is also no API to adjust sessions remaining.

I believe we requested this back in …… 2018? 2019?

@Quentin_Plomteux right? This still doesn’t exist?

Yes I believe so :stuck_out_tongue:

But anthony seems to have found a solution :slight_smile:

1 Like

Anthony’s solution isn’t related to what I’m looking for, and this issue is not solved. Cycles aren’t the same as sessions. See the two screenshots. One is from manage subscription, showing that a subscription in which there are 4 of the original 10 sessions remaining. The second is a screenshot from the Velo debugger in which I console.log() output the order for that same subscription. Nowhere in this data do I see either the 4 or the 10.


1 Like

I don’t think that is a solution for the Sessions.

The API Anthony provided is for Pricing Plan cycles to find out how many payment cycles are left. The number of cycles a person is simply how many more months they have remaining on their plan, not the number of Sessions they have available to use within a month for Wix Bookings purposes.

1 Like

Yeah, I’m sorry. I don’t think Wix has a solution for this. It is a very big API flaw for Wix Bookings.

1 Like

Thanks, codequeen. I don’t mind too much if canned Wix doesn’t do everything that everybody needs. But it is a big flaw if they don’t expose some data fields so that people can add features that Wix hasn’t (yet) implemented. It should be high on their priority to expand the API to expose all of the data that isn’t already exposed.

By the way, I think there is a very kludgy (and error prone) method to do what I want. First, sessions offered is something I know for each pricing plan (10 in my example above), so I can hardcode it in my function. This is error prone, because an admin can easily have changed that number from the dashboard for a particular subscription. Second, I think I can calculate sessions redeemed by doing a query of all confirmed bookings for the member, and then counting up the ones in which the orderId matches the one I’m looking at. Sessions remaining would be the difference between the two. I haven’t tried it yet, but I think it should work (and be slow).

1 Like

Yes, there are several possible “clunky” was of retrieving the information.

Like … attendance. Person purchases a plan, you store it in a database, then check their attendance and check if they used a Session.

But … that’s probably as far as you can take it.

Because there is still not way of adjusting the Session count via code if that was the goal.

The Admin of the website would still have to manipulate session count manually via the Wix settings.

Luckily I don’t want to change the session count. I just want to know which subscriptions are still active. Logically to me (and the way our organization uses it), when all of the offered sessions have been used on a pricing plan subscription it should be expired. That member can no longer use it. I shouldn’t have to go through all kinds of code gymnastics to figure that out. But, since Wix doesn’t handle this the “logical” way, they do force me to write the code to do it myself. And, they don’t even give me access to the data required to write that code.

It seems like a reasonable minimum requirement to Wix that they expose via API any data that can be accessed via the dashboard or by the user.

Well, I figured this out! The API documentation is incomplete and just flat out wrong, but through trial and error I got this working. The trick is to use the wix.bookings.frontend functions that are normally used by a logged in user when booking a session.

First, you need to find at least one upcoming session of the service you are interested in. This must be done in a backend module. Something like this:

  1. Use services.queryServices() to find one or more services that you are interested in finding the user’s sessions remaining relative to. [See wix-bookings.v2]

  2. Get the schedule IDs associated with those services.

  3. Find an upcoming session on that schedule, using sessions.querySessions(). Use .hasSome(“scheduleId”, [ ]). .ge(“end.timestamp”, new Date()).limit(1) to specify the schedule on your desired service and only return the first future session. [See wix-bookings-backend]

Once you have the upcoming session, you will need to find the contact(s) for which you need to determine the sessions remaining for the contact’s pricing plan relative to that session. I used contacts.querryContacts(), which is another backend function.

The rest of this is done on the frontend, on a dashboard page. The functions are defined in wix-bookings-frontend.

First you need to convert the session to a slot. To do this you use getServiceAvailability(). The first parameter is the ID of the service, retrieved by the backend function described above. The second parameter includes the start and end time of the session from above. This function returns a list of slots, but there should only be one in the list, and I just look at the id of the first element in the returned array.

Now, you can use getCheckoutOptions() from the same module. It takes two parameters. The first is the slot ID, and I just use the ID from the [0] element of the slot array. The second parameter is described in the documentation as userId. I could find no documentation for this. In fact, the example code suggests importing WixUsers from ‘wix-users’, and this module doesn’t seem to exist, nor is there any documentation for it. I used contactId here and it seems to work. [FYI, I’ve also found that contactId and memberId seem to be identical for site members, so I think you can use them interchangeably.]

The documentation says that this function returns an array of type checkoutOptions. The documentation is wrong. If you try to reference the elements of that array your code will fail. Instead of checkoutOptions[i], you must specify checkoutOptions.checkoutMethods[i]. The code editor will flag this as an error, saying “property checkoutMethods does not exist on type ‘checkoutOption[ ]’.” Ignore this error, and the code should work. (It does for me.)

The elements in this array specify all of the ways that the specified user can pay for the specified session. When the type field of the checkoutMethod is “package”, it means that a package-type pricing plan is available. In that case, the object also includes fields such as planName, totalCredits, and remainingCredits, which were the whole reason I went down this rabbit hole.

I hope this works for anyone else who needs this feature.