Upcoming SmartThings API Usage Limits for SharpTools Rules

[josh]

SmartThings recently announced changes to its API program, requiring paid API access for both individual developers and commercial integrations. In response, SharpTools will introduce monthly allowances for SmartThings API usage from SharpTools Rules beginning October 1, 2026.

Nothing is being limited yet. Monthly allowance enforcement begins October 1, 2026.

Rather than introducing separate usage-based charges for SmartThings API access, the allowances are designed to accommodate normal Rule Engine usage across all SharpTools plans.

We’ve also made significant improvements behind the scenes to reduce the number of SmartThings API calls SharpTools Rules need to make. As a result, most users are already comfortably within their allowance and won’t need to make any changes.

For users with Rules that generate unusually high SmartThings API usage, we’ve added new tools to identify where that usage is coming from and help make adjustments before the monthly allowance takes effect.

What changes on October 1?

The monthly allowance applies to SmartThings API calls generated by your SharpTools Rules.

• SmartThings API calls from SharpTools Rules are subject to a monthly usage allowance.
• Premium accounts include significantly higher monthly allowance than Free accounts.
• Usage is shared across all Rules and SmartThings locations on your SharpTools account.
• SharpTools Dashboards, device synchronization, and other normal platform activity do not count toward this allowance.

If your Rules reach the monthly allowance, additional SmartThings API calls from Rules will pause until the allowance resets the following month. Dashboards and other SharpTools functionality will continue working normally.

Check your SmartThings usage from Rules

From the Rule Engine, select the ⋯ menu in the upper-right and choose SmartThings Usage.

You’ll see:

• Your monthly usage as a percentage of your allowance
• The Rules contributing the most usage
• This month, Last 7 days, and Latest day views

The shorter time ranges are especially useful after making changes to a Rule.

If SmartThings Usage shows a Temporary allowance, it gives your account additional time to make adjustments. It does not replace your standard plan allowance, so use Plan usage as your long-term target.

Note: Latest day represents the most recently completed UTC day, so changes made today may not be fully reflected yet.

Ways to reduce high usage

If you’re approaching or exceeding your allowance, start with the Rules at the top of the usage list.

Common patterns worth reviewing include:

Frequent or rapidly changing triggers

A Rule that runs every few seconds, or reacts to a value that changes very frequently, can generate a large amount of SmartThings API traffic over time.

Consider whether every change needs to result in a SmartThings command or whether updates can happen less frequently.

Refresh or ping commands

Many devices do not need to be refreshed after every command.

In particular, avoid automatically sending Refresh immediately after another device command unless you know the device or integration requires it.

Mirroring rapidly changing values

Continuously copying changing values into SmartThings virtual devices can generate significant API usage.

If the value is primarily used by SharpTools Rules, consider using a SharpTools Variable instead.

If it needs to be mirrored into SmartThings, consider only updating it when the value actually changes or when the change is meaningful.

Rules that trigger themselves

Watch for Rules where an action causes the same Rule or another Rule to trigger again.

These feedback loops can be intentional, but an uncontrolled loop can generate a very large number of API calls quickly.

Large numbers of device commands

A Rule that controls many SmartThings devices at once will naturally use more API calls than one controlling a single device.

That’s perfectly reasonable in many automations, but Rules that both run frequently and control many devices are worth reviewing.

Duplicate or unnecessary commands

Look for multiple Rule paths that ultimately send the same SmartThings command or perform the same update.

Removing unnecessary duplicate actions can reduce usage without changing the behavior of your automation.

Do I need to change anything?

For most users, no.

If your SmartThings Usage page shows that you’re comfortably within the monthly allowance, you can continue using your Rules as you do today.

If your Plan usage is approaching or exceeding the standard allowance, we recommend reviewing your highest-usage Rules before October 1, even if your account currently has a Temporary allowance.

We’ll also reach out directly to users whose recent activity indicates they’re likely to exceed the new allowance.

If you’re seeing high usage and aren’t sure what’s causing it, feel free to post in the community and we’ll be happy to help you review your Rules.

[Andrew_Galietta]

Well this doesn’t seem like a fun thing for me to have to keep track of.. I know it’s not you, but damn.

[Nezmo]

I’m already in timeout .

[Nathan_Maxwell]

I am so utterly fatigued of these announcements. It’s either: “Hey! This thing you spent hours setting up doesn’t work anymore! You’re welcome!” or “Hey! This thing you used to do now costs 300% more! Tada!”

Unfortuately the fact that SmartThings/Samsung imposed (“enhanced”) these circumstances and that SharpTools is simply responding to the situation is genuinely irrelevant: if I can’t trust whether a SmarthThings rule will fire, I can’t trust SharpTools.

Apparently I do not fit into the “most users” category. How can I put my rulebase on an API diet when you’re lumping almost all the calls into an “other and unattributed” category? Should I just hunt and peck through all 57 rules and hope I find the culprit?

[josh]

I hear you guys and I’ve been feeling the frustration and stress of this as well, so I can empathize!

@Nezmo

I’m already in timeout .

Enforcement is scheduled to start October 1, so you should just be seeing the warning, but no actual limitations.

I wanted to get the notices out as early as a reasonably could, but there’s still some rough edges. Lots of work to get to this point and with the timeline from SmartThings, I still feel like I’m pushing things out a bit earlier than ideal to try to give everyone enough time to not be caught off guard last minute. (more on that in my reply to Nathan below)

@josh

…made significant improvements behind the scenes to reduce the number of SmartThings API calls SharpTools Rules need to make.

I’ve been working hard in the background to reduce SmartThings API calls as much as possible. A bunch of work around enabling more detailed attribution, and metrics around API calls. Then analyzing and finding areas of opportunity for reduction. A bunch of work behind the scenes to seamlessly transition conditions and device state reads in rules to set up event subscriptions so we could read that state from the local database instead of API calls.

But there are still fundamentally some patterns that cause higher usage and impact the top few percent of SmartThings users.

To that point, this specifically impacts SmartThings API calls based on the change of SmartThings is rolling out. Other integrations like Homey, Home assistant, and Hubitat are not impacted.

I also built a local SharpTools Bridge with a bunch of LAN integrations like Phillips Hue, TP Link Kasa, Lutron, Fully Kiosk, and Matter.

SharpTools Bridge private alpha is starting

Using one of those alternatives that isn’t directly impacted could be useful for some cases.

---

@Nathan_Maxwell

How can I put my rulebase on an API diet when you’re lumping almost all the calls into an “other and unattributed” category? Should I just hunt and peck through all 57 rules and hope I find the culprit?

I should I have clarified how to use the Usage reporting and the current limitations. The warning you see in amber is a key point:

This time range includes days without rule level tracking. Treat it as directional.

The overall usage shown in the top bar has been in place since before the beginning of the month.

The attribution per rule was only added August 14 which is why you see the amber warning on the month range selection. September should be the first month with full rule level usage tracking where that amber warning will disappear.

In the meantime, if you filter to the latest day, you should get more accurate rule level tracking.

And similarly, once August 23 rolls around, the seven day usage should be complete.

—

My apologies as I know it’s not ideal. I felt it was important to get out whatever metrics we had available as early as possible, even with the rule level attribution being incomplete at the monthly level.

—

From a quick review, a few opportunities:

1. House Off Fanout: One execution fans out across roughly 60 devices. Moving the bulk shutdown into a SmartThings Scene (Manual Routine) and executing that Scene from SharpTools could turn dozens of SharpTools API calls into one.

2. Motion Rules: Lights On @ Active repeatedly resend commands to groups of devices on motion events. State guards could prevent commands when the lights are already in the desired state. A SmartThings Scene could also reduce each multi-device execution to one SharpTools API call.

3. Fade Rules: long sequential fade macros generate repeated level commands. Conditional usage, sparingly using these, or single level transitions would reduce usage.

[Paul_Oliver]

@josh Do you know if SmartThings is going to change individuals who use SharpTools?

They have kept us in dark how this is going to work.

I only know that they will charge for integrations with Home Assistant because Home Assistant has informed us of that fact

[josh]

@Paul_Oliver

Do you know if SmartThings is going to change individuals who use SharpTools?

No, SmartThings will not charge individuals for usage from SharpTools

(SmartThings API usage from SharpTools is covered by the commercial relationship directly between SmartThings and SharpTools.)

[Nathan_Maxwell]

1. House Off Fanout
2. Motion Rules
3. Fade Rules

Thanks @josh for your response.

It seems like #1 makes sense in any case… there’s no reason to have SharpTools toggling things off when all I really need is its rule logic horsepower. (Except it’s 100x easier to mass-select devices in SharpTools than the ST app.)

For #2, it’s always seemed more “correct” to first check a device’s state before sending what could be a redundant request - “Hey, are you already on?” Now the effeciency matters.

I figured #3 would be the prime suspect… the thing is those are some of our house’s favorite daily automations.

But is it correct that every service integration with ST will always be subject to this new “enhancement?” It sure sounds that way from the ST announcment. And the announcement here notes that SharpTools integrations with other platforms (Hubitat, HA, etc.) are unaffected. It seems like the hard reality is that migrating away from ST to some other platform (that has some insulation from a similar fate) is the only definitive solution to the problem.

[josh]

I’ve made some improvements to the SmartThings Usage tool based on feedback from this thread.

1. Added a notice clarifying that allowance is not enforced
2. Added a ‘Temporary Allowance’ display for impacted users (see more below)
3. Adjusted the Top Rules listing so percentages are based on rule-attributed usage

Note that you may need to refresh the page to pull in the latest frontend version with these improvements.

Allowance Not Enforced notice

As noted in my reply above, enforcement is scheduled to start October 1.

The warning messages and usage tools are intended to help people get an early start on things, but if anyone saw the new usage indicator and had not seen this community thread, they wouldn’t know that!

Temporary Allowance

I applied temporary overrides to premium members who were already over the limits when I ran the analysis earlier this month. Basically two different groups:

• 2x over the standard limit, but under 2x
• 5x over the standard limit and 2x, but under 5x

These are intended to be temporary allowances to give existing premium users whose usage was over the limits some extra time to refine their rules.

I previously missed the cohort who was using more than 5x and I applied a temporary 5x override for them as well earlier today. That being said, many of the most egregious cases have rules that fundamentally need cleanup per the common anti-patterns noted above.

Top Rules (by Attribution)

The percentages for Top Rules are now calculated only from rule-scoped attribution making it easier to understand their consumption of the broader allowance.

Keep in mind that rule-attribution started August 14th, so the August ‘This Month’ view may not perfectly reflect rule attribution if your rule usage has changed significantly, but this change seems more intuitive for most people.

You can always adjust to ‘Last 7 days’ or ‘Latest Day’ to filter to more recent usage patterns.

As you make changes to rules to refine your usage, keep in mind that you will need to wait a full day to see the ‘Latest Day’ reflect those improvements.

[Andrew_Galietta]

I’m legit more confused than ever before. My plan usage is 77 percent? My temporary allowance is 15? However yesterday my usage was 13 percent ..

[josh]

@Nathan_Maxwell

But is it correct that every service integration with ST will always be subject to this new “enhancement?” It sure sounds that way from the ST announcment. And the announcement here notes that SharpTools integrations with other platforms (Hubitat, HA, etc.) are unaffected. It seems like the hard reality is that migrating away from ST to some other platform (that has some insulation from a similar fate) is the only definitive solution to the problem.

As far as I’m aware, every third-party integration will be impacted by SmartThings making their APIs paid. The Home Assistant team was pretty direct that their users would be impacted and would have to use the SmartThings paid personal plans to keep SmartThings integrated with HASS.

And yes, the SmartThings API allowance being enforced by SharpTools only applies to SmartThings. Other integrations like Home Assistant, Hubitat, Homey, or even our new first-party SharpTools Bridge that has LAN integrations with Philips Hue, TPLink Kasa, Lutron, Matter and more don’t have limits.

[josh]

@Andrew_Galietta

I’m legit more confused than ever before. My plan usage is 77 percent? My temporary allowance is 15? However yesterday my usage was 13 percent ..

The single usage bar you were seeing yesterday was against the currently effective allowance, but I realized it wasn’t labeled and didn’t communicate the real percentage that users with temporary allowances should care about.

I updated the main usage indicator to make it more clear that the real target is the base allowance included with the plan… and explicitly labeled the ‘Temporary Allowance’ accordingly along with the multiplier and expiration.

When the allowances are enforced on October 1st, you will not be rate limited if you stay under your temporary allowance. But the goal is to get under the standard Plan Usage allowance. When the temporary allowance expires at the end of the year, the base Plan Usage is what you’ll need to stay under to avoid rate limiting.

---

You have a 5x temporary allowance.

• Your current usage is 77% of the base Plan Usage
• You have a temporary allowance of 5× Plan Usage
  • So the same usage is only 15% against your temporary 5× limit
  • 77% ÷ 5x = 15.4%

If the community has suggestions on how to make this more clear, I’m all ears.

[Nezmo]

Ouch.

[josh]

At over 5x, you’re in the very top of the top of usage!

Have you checked against the patterns mentioned above? On the upside, it’s looks like more than half of the usage is from a single rule. And a big chunk from the next 3-4 rules.

[Nezmo]

@josh

Have you checked against the patterns mentioned above? On the upside, it’s looks like more than half of the usage is from a single rule. And a big chunk from the next 3-4 rules.

Yeah, I know where the issue is. I’m working on it.

[Zach_Imler]

@josh will we be given the opportunity to just pay for our overage if we can’t or don’t want to figure out how to trim our rules?

[Rick_VB]

Thanks for the email and the opportunity to update things, much appreciated!

As to the limits, what are they set at? I have 2 simple temperature rules to turn on/off a plug based on temp sensor. 2 devices, 2 rules.

sensor updates and > 130f, turn plug off

sensor updates and <125F, turn plug on

From what I can tell from ST, i’m getting around 10 temp updates an hour, and it’s turning the plug on or off maybe 2-4x an hour. Too much?

Or are device updates to my dashboard included as well? or are other updates to devices not being used included as well?

[Brian_Taylor]

I have 2 rules dominating one that turns lights off when we leave or go to sleep, and one that turns lights on a floor off when there is no motion. The only way to lower these is to add a restriction on the trigger which sharptools does not support. Restriction for the leave rule would be and a light is on, and restriction on turn lights off would be and nightime is on. Thoughts on this.

[Bas_van_Rens]

Hi Josh,

Sorry you had to do all this work. Is is a bummer for all of us, but it is what it is. I am at 975% of my allowance, so I have some work ahead of me ;-).

Quick question: In my rules (some of which run every 5 mins) I turn off a device even though it is already off. This results in an api call, right? Now asking for the device status would also result in an api call, correct? So my approach would be to store the state in a (sharptools) variable and then only update it the device setting actually needs to change. The underlying assumption being that checking a variable does not create an api call (correct?).

Would you agree this is a better approach? I can imagine more people use this pattern since there is a single source of truth (the status of the device) and less convoluted than keeping track of a state, but given the cost of api calls nowadays …

Many thanks,

Bas

[Andrew_Galietta]

I’m guessing any time a change occurs as a result of Sharptools that’s a API call? I’m not sure there’s anything I can really change..I’m guessing MOST is coming from my virtual master dimmers/toggle rules… and yeah I don’t want to change those…