Notification URLs

Stores, checkouts, and subscription platforms tell Botsi about purchases, renewals, and refunds by posting to a notification URL. Every notification URL for an app is built from the same notification key (a UUID that identifies your app), with one URL per provider.

Notification URL Structure#

https://api.botsi.com/v2/notifications/<provider>/<notification-key>

<provider> is one of apple, google, stripe, shopify, custom, web2wave, revenuecat, superwall, or adapty. <notification-key> is your app's notification key, and it's the same in every URL. For example, an app with the key 9b2f6c1e-4d7a-4e3b-8c5f-2a1d0e9b7c64 receives Stripe events at:

https://api.botsi.com/v2/notifications/stripe/9b2f6c1e-4d7a-4e3b-8c5f-2a1d0e9b7c64

The notification key is an address, not a credential. It tells Botsi which app the notification event belongs to, but is not a security credential. Each provider authenticates its own payload with a signature, token, or secret, described on that provider's page.

Notification Webhook Endpoints#

Pick where your billing & checkout actually runs. Each one has its own notification endpoint on https://api.botsi.com, built from your app's notification key.

Responses every notification URL shares#

Each provider's page lists the responses specific to it.

Retrying deliveries#

Every notification URL is idempotent. A redelivered event never double-counts revenue, and a delivery that failed with a 5xx is recorded when the sender retries it.

Using one revenue platform at a time#

RevenueCat, Superwall, and Adapty each report your app's revenue, so only one of them can be enabled for an app at a time. Enabling a second is refused with 400 and the code revenue_source_conflict until you disable the first.

Botsi doesn't stop you from sending App Store or Google Play notifications alongside one of them. When Superwall or Adapty is your revenue source, don't send App Store or Google Play notifications to Botsi as well.