Understanding BETA Apps on OttoKit

If you’ve browsed through OttoKit’s app directory or added apps inside the workflow builder, you’ve probably noticed that a good number of apps are marked as BETA. This is intentional, and this guide explains what that tag means, why it’s there, and when it gets removed.

What does BETA mean on an app?

A BETA tag on an app means the integration is live and usable, but it’s still being refined based on real-world usage. We ship apps in BETA for two main reasons:

1. We want real-world feedback. Some apps are in beta because we want people actually using them in their workflows to tell us what works and what doesn’t. This helps us fine-tune the actions and triggers so they match how you actually work, not just how the API documentation suggests they should work.

2. The app has external constraints we need to test across setups. Others are in beta because of region-specific behavior, account-level restrictions, or API limitations that need broader testing across different user setups before we can call them stable.

In short: a BETA app might occasionally not behave as expected, or might return unexpected responses, because it hasn’t yet been battle-tested against the full range of user scenarios.

Why some apps stay in BETA longer

Not every app behaves the same way across every user, region, or plan. Here are some common reasons an app needs extended beta testing:

Region-specific restrictions. TikTok-based apps, for example, have restrictions in India, which makes accessing and using the API more difficult. Apps like these need feedback from users across multiple regions to confirm behavior.

Account verification requirements. Some apps require real PAN, SSN, UTR, tax IDs, or similar identity/financial verification to create an account or authenticate via their API. These apps need feedback specifically on how they behave once those verification inputs are in place, since we can’t always replicate every account configuration in testing.

API rate limits and plan-based quotas. Some apps enforce daily API call limits, or the limits shift depending on the user’s plan tier with the third-party provider. Real-world usage helps us understand where users typically hit these walls and how to handle them gracefully in workflows.

Undocumented API behavior. Some APIs behave differently in production than their docs suggest, especially around edge cases, error responses, or specific endpoint combinations. Beta usage surfaces these quickly.

How to check if an app is in BETA

It’s easy to spot. Any app currently in beta will have a BETA tag attached to its name.

You’ll see this tag in two places:

• When searching for the app in the app directory
• When adding an app from the app flyout inside the workflow builder

If there’s no BETA tag, the app is stable and has graduated out of beta.

When is the BETA tag removed?

We remove the BETA tag once we’ve received enough feedback confirming that the full list of actions and triggers work reliably across real user workflows and use cases.

There’s no fixed timeline on this. It depends entirely on user feedback. An app with heavy usage and consistent positive feedback can graduate quickly. An app with niche usage, or one where users keep surfacing edge cases, will stay in beta until those are resolved.

How you can help

Your feedback is what pushes an app from BETA to rock solid. If something feels off, a field isn’t working the way you expect, a trigger isn’t firing, or you think an action is missing, tell us. That’s the fastest way to make these integrations sharper and get them out of beta.

You can share feedback directly by reaching out to support. Feedback on BETA apps is prioritized and acted on faster than standard requests, since it directly shapes whether the app graduates to stable.