Question

Do I need to store data in a database


Badge +2

I am writing an app with the choice to subscribe to premium features on a monthly or yearly basis. I’ve been wondering if I need to store webhook data that comes from revenuecat into my database. What would be the benefit of this? I thought that the revenuecat API (i.e. javascript API) lets us see if a user (i.e. alex@mywebsite.com) is subscribed to our iOS/Android/Stripe app. Maybe I’m missing the point somewhere here. If I did store the data in a SQL db, how would the schema be best designed? 

 

I see @ryan from RevenueCat replied to a similar post but I’m not 100% sure how to implement this best. I see the /subscriber endpoint docs mention a subscriber object, entitlement object, subscription object, non-subscription object, subscriber attribute object - would I want SQL tables for each of these?


6 replies

Userlevel 5
Badge +9

Hey @tim g

There’s no requirement to set up a database or store anything on your side. RevenueCat automatically keeps subscription status in-sync server-side so you aren’t missing out on any functionality by not having your own database.

I would say if you don’t have any requirements for webhooks on your end, no point in setting them up. 

Badge +2

@ryan I see. In what scenario do we want to store our users’ webhook info? I think I have a requirement for webhooks because I only want to send push notifications to paying users who have also signed up for notifications in my app.

Badge +2

update on my reply: these notifications will be sent from my backend, all at the same time.

Userlevel 5
Badge +9

Really depends how you want to architect it. If you want to send push notifications in response to an event then webhooks can be a great trigger for that. If you want to send a push notification on a scheduled time to paying users then webhooks could be used to keep the subscription state in-sync on your backend so you don’t need to make any requests to RevenueCat to get the list of all users that should receive a notification. 

The simplest implementation of this could be a table with app_user_id and expiration_date fields. For every webhook except product changes you could update the expiration_date for the app_user_id.

When you go to send your push notification you can get all users with an expiration_date > now() as your active subscribers.

Badge +2

Thanks, I see what you mean @ryan. One other question I have is when can a revenuecat user have multiple app_user_ids? My best guess is if he pays on one device with one email (i.e. test@website.com) and logs out, then signs back in with another email (test1@website.com). The revenuecat user would have the test@website.com app_user_id and test1@website.com app_user_id is my understanding. So both test@website.com & test1@website.com would have premium feature access.

 

So would my SQL table have the most recent app_user_id? Or do I want to store all the app_user_ids? From my understanding I’m supposed to be storing device tokens attached to a user’s email so I can send push notifications. I don’t want to send the same push multiple times to the same user’s device.

Badge +2

@ryan Sorry to bombard you with questions but can I potentially just hook up revenuecat to onesignal and then send push notifications to paying users like that?

Reply