#RevenueCat Implementation
6 messages · Page 1 of 1 (latest)
yup, what can I help you?
- Did you use both webhooks and api calls (as recommended in their docs) , or just one way to validate dubscription ?
- Their docs specify that you should return the response and defer the processing, so here comes the question, did you use something like bullmq to process the data that came from webhook ?
- What was your db schema ? Did you store the subscription itself, the hook response ?
- How you and the client side managed the fact that the webhook can come up with a delay of 60 seconds ?
yeah, i used both webhooks and api calls. webhooks handle the real-time updates, and the api's mainly for syncing or double-checking in case a webhook is delayed or missed. I queue the webhook data with BullMQ and process it async. In the db I just store the subscritption info (userid, productid, status, expiry, etc.) plus the last webhook payload for reference. on the client side, we always rely on what the backend says, the webhook delay doesn't really matter then.
okay, got you, thanks a lot. Would love if you could share some pieces of code you used, but if not possible, not a problem, thanks a lot
sure thing! i can share a simplified version later. it's just a small nest endpoint for the webhook that pushes data into BullMQ, and a worker that updates the subscription in the db after verifying with the RevenueCat api. nothing too fancy 🙂. i'll drop a snippet when i get a chance.
could you contact me via dm? could you send me a friend request?