The on-device denylist
A hard-coded list of Android package names smartordercapture refuses to automate. Enforced three times: at workflow save, at marketplace publish, and on-device before any UI action.
How enforcement works
- The API validates every workflow create and update against the list.
- The marketplace review worker scans templates before they are published.
- The on-device Kotlin interpreter checks again before dispatching any UI action, so a workflow that somehow reached the phone still cannot run.
What gets a workflow into the denylist gate
Any package-name reference, whether it sits on a trigger or an action — for example trigger.appOpened.packageName or action.openApp.packageName.
The current list
Gig delivery driver apps (10 packages)
Automating offer acceptance violates these platforms' ToS, exposes drivers to account deactivation, and takes work from other drivers.
- com.dd.doordash
- com.doordash.driverapp
- com.ubercab.driver
- com.ubercab
- com.walmart.androidsparkdriver
- com.amazon.rabbit
- com.instacart.shopper
- com.instacart.client
- me.lyft.android
- com.lyft.android.driver
Ticket purchase platforms (3 packages)
Automated buying is prohibited by these platforms and, in many U.S. jurisdictions, by the federal BOTS Act of 2016.
- com.ticketmaster.mobile.android.na
- com.stubhub
- com.seatgeek.android
Ad-network SDKs (4 packages)
Workflows targeting these SDKs are typically attempting to simulate views, clicks, or installs for ad fraud.
- com.google.android.gms.ads
- com.facebook.ads
- com.applovin.sdk
- com.unity3d.ads
More on why these are blocked, and whether anything ever comes off the list, in the FAQ and the Acceptable Use Policy.