#devchris
1 messages ยท Page 1 of 1 (latest)
Hi there
No you create a static endpoint
Can you tell me more about the use-case here?
Why do you want a dynamic endpoint?
Hey ๐
So we have a SaaS app that starts to get some traction and we have an enterprise client that likes to have its own server etc. So we basically run the same app on a different server for them with a dedicated subdomain. So now if a client of theirs pays, the sucessfull webhook goes to the main server instead of the enterprise server for our client
This app works as a plugin? Or are you using Connect?
It's using connect
Gotcha. If you want to completely separate out that Enterprise user then you would need to create a new platform and just have that Enterprise user associated. Otherwise, you just filter events to your Connect Endpoint based on the Connected Account in the Event. But there is no way to stop Events from being sent to every endpoint that listens to that Event type.
Hm... if I were to create a new platform, would this also include new secrets?
Yes it would
You would basically duplicate your integration in this case and just have a standalone integration for that platform/connected account (enterprise) user.
Would be a bit of a pain
Wouldn't necessarily recommend it. But only way really to accomplish what you are asking for.
It is... plus it doesn't scale really well
We are planning on onboarding a few more of such enterprise users on their dedicated servers
Can't always just create a new platform for that
Let's say we do have 50+ dedicated servers, would it still work to receive every webhook to every single server? With a couple hundred payments per day per client? Seems like we would start hitting rate limitations pretty fast like this? ๐ค
Yeah agreed it doesn't scale which is why I don't recommend
Mostly you just filter events based on the Connected Account ID in the Event
When you receive an Event you should respond with a 200 and then you queue it to handle the necessary actions on your end so that you don't hit rate limits.