Changes to subscription status do not generate webhook events

When a subscription is paused or cancelled from the end of the current billing cycle this generates an action that causes the subscription status to be updated to the new status at the correct time. However when this action fires it does not generate a subscription.updated webhook nor update the version number on the subscription.

Also no update is generated when the subscription actions are modified such as when a pause is scheduled. This means it’s impossible to know via webhooks that a subscription has been scheduled to be paused and so know to check for the status change at the action time.

The only solution seems to be to constantly poll all subscriptions via the search endpoint to keep in sync. This is problematic in itself because that endpoint intermittently times out with a 504 Gateway Timeout error returned from within Squares infrastructure (we’ve apparently been told this is because we have too many subscriptions in the system, around 2500).

It would be really helpful if ALL changes to the subscription could generate subscription.updated webhook events and version number increments.

1 Like

:waving_hand: I’m Square Dev AI, here to help answer your question!
Based on the information you’ve provided, the following documentation will help answer your question:

Additional Documentation

Square Developer
Use Webhooks to Integrate with a Payroll System
Handle Inventory Event Notifications

If this documentation helped you find a solution, please check the box indicating that this reply solves the problem.
Otherwise one of our Developer Advocates will provide additional assistance shortly.

The Square API currently does not support webhook events for changes in subscription status such as pausing or cancelling. This includes changes to the subscription actions. As a result, the only way to keep track of these changes is to periodically poll the SearchSubscriptions endpoint. However, as you’ve noted, this method can lead to timeouts if you have a large number of subscriptions.

Unfortunately, there is currently no workaround for this limitation. It’s recommended to provide this feedback to Square’s development team for consideration in future API updates.

This answer was reviewed by @Bryan-Square.

Are telling me to provide this feedback? That’s why I sent the message in the first place as there no place to report bugs, and judging from your response you already know the API doesn’t work anyway.

BTW 2500 is not really a large number of subscriptions, especially when this includes those that have been cancelled over the years.

This is just crazy to me, you don’t get a human response. And even the AI doesn’t respond.

Hi @aidansw, all our AI generated responses are approved by someone on our team before they’re sent. This is to avoid any misleading information and to ensure that there is a human element to the response. :slight_smile:

You replied to me, but not to the question… Also can you please clarify why the AI generated answer was incorrect in this case? What are the differences between recurring_price_money and pricing in Subscription Phase - #6 by aidansw

What isn’t clear in the documentation and what kind of a subscription are you trying to create? :slight_smile:

It is not clear whether recurring_price_money is required, and it is

@Square-Dev-AI says:

The recurring_price_money field in the subscription phase represents the price of each billing cycle in the phase. This is the amount that will be charged on a recurring basis for the subscription.

On the other hand, the pricing field is used to define the pricing tiers for the subscription plan. This is useful when you have different pricing options for the same subscription plan. For example, you might offer a subscription plan at a lower price for the first three months and then a higher price for the subsequent months. In this case, you would use the pricing field to define these different pricing tiers.

But both pricing and recurring_price_money are defined on phases within a variation.

@Square-Dev-AI then says:

If you don’t have a trial period or different pricing tiers for your subscription plan, you would still need to include the pricing field in your request with the recurring_price_money field nested inside it. This is because the pricing field is required in the CreateSubscriptionPlan request, and it must contain at least one pricing tier. The recurring_price_money field is then used to specify the price of that tier.

This is doubling untrue, because pricing is not a field of a SubscriptionPlan it is a field of Phases just like recurring_price_money. And recurring_price_money is not a field of pricing. So the confusion is what is does recurring_price_money actually do anything different than pricing other than not being able to be RELATIVE or take discount_ids?

What is the pricing type of subscription your offering? Is it RELATIVE or STATIC? :slight_smile: