#idhruv-webhooks

1 messages · Page 1 of 1 (latest)

echo blade
#

Not really sure I understand the issue you're describing. Can you provide some more detail and perhaps some object IDs?

#

Sharing for posterity:

every time an user pays on our platform for monthly bookings, we create a new subscription and a new webhook to call back our webhook endpoint, surprisingly our existing webhook gets changed as soon as this functionality of creating new webhook is triggered.

nimble jungle
#

we_1LXMWnGdNldKu1zmczUTNAJ2
we_1LRj2CGdNldKu1zmPcJsjBkq

echo blade
#

You're creating a unique webhook endpoint per subscription?

nimble jungle
#

yes

echo blade
#

Why? That won't really scale as the limit is capped quite low

nimble jungle
#

thats because each customer can have different duration of booking

#

can you please check both IDs above? what is going on

echo blade
#

I can have a look, but I'm telling you now your solution of 1x webhook per subscriber won't scale

nimble jungle
#

okay understood, but even if limit gets reached i should be receiving some kind of limit reached related problems right, why is it overwriting other webhooks?

#

and how will I serve 100 clients with just one webhook? is it possible?

echo blade
#

I'm not sure what you mean by overwriting webhooks?

echo blade
nimble jungle
#

okk

nimble jungle
#

but as soon as one another client made a booking his subscription was correctly created and it also triggered one unique webhook different than above

#

but his webhook replaced all the configurations, emails, price etc of that previous client

#

i mean in the worst nightmare of the bugs that I have seen I have never saw anything like this. can you please explain how is this possible?

#

and sad part is its happening on live

queen sparrow
#

👋 Taking over this thread. Catching up now

nimble jungle
#

ok thanks

#

i ll wait for clarification

queen sparrow
#

For each webhook event, it has its own unique object ID. For example, Subscription ID (sub_xxx) for subscription related events such as customer.subscription.*. Similar for Customer ID (cus_xxx) where their events will be customer.*. Your system should recognise this ID and map the event details according to these ID.

#

For example, when a customer is created, customer.created event will be sent and it'll include Customer ID which you can store and map to your system. When there's any changes to the same customer next time, customer.updated event will be sent to you with same Customer ID. You can then update the event information accordingly.

When a subscription is created, there will be a Subscription ID returned in the response. Any change to the same subscription will include the same ID and you can identify by its ID accordingly.

nimble jungle
#

const url = ${BASE.URL}/api/payment/create/subscription-paid/${bookingArr[i]._id}; /** trigger webhook for */ const webhookEndpoint = await stripe.webhookEndpoints.create({ url: url, enabled_events: [ 'invoice.payment_succeeded' ] });

everything sums up in these lines and there is no other logic involved while creating webhook, if this code gets called second time it is currently replacing all previously existing webhooks

#

where should I fit customer ID here? i see no role of customer ID in this case. am I missing something?

echo blade
#

Another issue with this approach is every webhook on your account is going to receive every invoice.payment_succeeded event on your account, regardless of what customer/subscription it's related to

#

You need a single webhook and handler/endpoint that has the logic to determine which customer the received event was related to

nimble jungle
#

is it covered in docs?

#

can you give me link to some examples

nimble jungle
queen sparrow
#

Let's step back a bit

#

When you create a webhook endpoint that listens to invoice.payment_succeeded events, all invoice.payment_succeeded will be sent to this endpoint regardless which customer this is for

#

Webhook configuration is based on the event types

#

From the current configuration, it looks like you're using invoice.payment_succeeded to listen whether an invoice of a subscription is paid successfully.

nimble jungle
#

yes;

queen sparrow
#

subscription field is the Subscription ID where the customer's subscription

#

You can use this Subscription ID and update the successful payment of the invoice

nimble jungle
#

this is exactly what i am doing

#

but as you say, because i am always creating webhooks along with new subscription this gets called multiple times based on how many customers i have and that is the source of all the confusion, how exactly can i create webhook then?

queen sparrow
#

Thanks for sharing the code

#

You shouldn't create Webhook endpoints when new subscription is created every time

nimble jungle
#

ohk, so when new subscription is being made then should i just update the webhook which is present in the system?

#

using webhook update api or something

#

or i should just manually create it and leave it as it is, so that everytime my invoice succeeds it automatically calls my endpoint api on my server?

queen sparrow
#

It'll be the latter. You should create ONE Webhook endpoint upfront to listen to all invoice.payment_succeeded events (even before creating any subscription).

After the Webhook endpoint is created, you shouldn't have to update or modify it at all. All the invoice.payment_succeeded events will be sent to this single endpoint once the subscription is paid successfully.