Have something to say?

Tell us how we could make the product more useful to you.

Superagent All-App Mode?

Descrição: O Superagent já consegue ler dados de outros apps do mesmo dono via read_user_app_data, mas não pode escrever (criar, atualizar ou deletar registros). Isso quebra qualquer automação end-to-end. O que pedimos: um "All-App Mode" onde o dono do app autoriza o Superagent a ter acesso completo (leitura + escrita) em todos os seus apps — sem precisar de endpoints customizados ou intervenção manual. Caso real: tenho diversos apps e 4 apps (Business Oportunize, GAP 2.0, BasketTeam Pro, meotenisold). Meu Superagent conhece todo o meu negócio mas fica de mãos amarradas na hora de agir. Com acesso completo, ele poderia executar fluxos inteiros de automação autonomamente. Seria o diferencial real do Superagent como agente verdadeiramente autônomo. 🙏 — Hugo Arens, CEO Oportunize Gestão e Negócios

oportunize oportunize About 2 hours ago

💡

Feature Request

Superagent All-App Mode?

👋 Tenho diversos projetos e 4 apps na plataforma (Business Oportunize, GAP 2.0, BasketTeam Pro e meotenisold) e meu Superagent já conhece profundamente o meu negócio — contexto, clientes, estratégia. O desafio é exatamente esse: ele lê tudo, entende tudo, mas na hora de agir nos outros apps, trava. É como ter um assistente genial de mãos amarradas. Com o write_user_app_data funcionando entre apps do mesmo dono, o Superagent poderia: Implementar melhorias de código nos meus apps automaticamente Criar e atualizar registros cross-app sem intervenção manual Executar fluxos completos de automação end-to-end Hoje 90% do caminho é autônomo — esse 10% final quebra tudo. Seria o diferencial real do Superagent como agente verdadeiramente autônomo. 🙏 — Hugo Arens, CEO Oportunize Gestão e Negócios

oportunize oportunize About 3 hours ago

💡

Feature Request

Feature Request: Cross-App Write Access for Superagents

The SuperAgents are great. Really a step forward. Great work. A Superagent can currently read data from other apps owned by the same user via read_user_app_data, but cannot write to them (create, update, or delete entity records). This means that tasks which could otherwise be fully automated still require manual intervention for the final step. Proposed solution Add a section in each app's Settings called something like "Connected Superagents", where the app owner can select which Superagent(s) are allowed to write to that app. The connected agent would then receive admin-level access to that app's entities — the same way it already works for the agent's own app. Why not a custom endpoint? A custom endpoint (e.g. via a Function) only partially solves the problem: You'd need to build a separate endpoint for every action → high maintenance The agent doesn't learn the app's data structure or logic Internal automations and business logic in the app wouldn't be triggered Direct entity access is cleaner, more powerful, and consistent with how the platform already works. Concrete use case My Superagent receives an email with an attachment → retrieves and uploads the file → needs to add it as a document to the correct grant application in my GrantWise app → and mark the related task as done. Right now, 90% of this is automated but it breaks at the write step. Suggested implementation Add a connected_agents field to app configuration When an agent request comes in with a matching agent ID → grant admin-level entity access Expose a write_user_app_data tool alongside the existing read_user_app_data This seems relatively straightforward to implement and would unlock true end-to-end automation across apps — which I think is a compelling use case for any power user on the platform. Thanks for considering it!

ET4ever About 11 hours ago

💡

Feature Request

StoreKit/IAP Integration for Apple and Google to sell digital and have subscriptions. You don’t need it. Use stripe!!!! This is HUGE.

payment + review flow Legal background (Epic v. Apple) Case: Epic Games, Inc. v. Apple Inc., Case No. 4:20‑cv‑05640‑YGR (N.D. Cal.). Result: Apple cannot block or punish apps for sending users to an external website (like Stripe) to pay instead of using Apple’s in‑app purchase system, for US App Store users. Apps are allowed to: • Show prices and “subscription” language inside the app. • Redirect users to a web page for payment (e.g., Stripe Checkout). • Return users to the app afterwards. How this works with Base44 + Stripe The app itself is built in Base44 (web app wrapped for iOS/Android). Inside the app you: • Show subscription options and pricing. • When the user taps “Subscribe,” show a clear message like: “You are leaving the app to complete payment on our secure website (Stripe).” • Then redirect them to a Stripe Checkout URL in the browser / in‑app web view. • After payment, Stripe redirects back to a URL or deep link that re‑opens the app with the user marked as subscribed. Because the payment is processed on the web via Stripe, Apple and Google do NOT take the 15–30% cut; you just pay normal Stripe fees. What we do in practice Build everything in Base44 (RealShield AI app). Integrate Stripe for subscriptions. Implement a “leaving the app to pay on the web via Stripe” confirmation box before redirect. Submit the wrapped app to: • Google Play (AAB file). • Apple App Store (IPA file). If Apple rejects the app Sometimes reviewers still apply old rules and say you “must use in‑app purchases.” In that case, we DO NOT change the payment flow. Instead, we appeal. In the appeal, we: • Cite Epic Games, Inc. v. Apple Inc., Case No. 4:20‑cv‑05640‑YGR. • Explain that: – The app uses a clearly disclosed external web payment (Stripe). – Users see a neutral notice that they are leaving the app to pay on the web. – No Apple IAP is being used or hidden; the flow is consistent with the court decision and Apple’s updated US rules. Typical pattern: Submit with Stripe + external redirect notice. If Apple approves: done. If Apple rejects on payments: file an appeal referencing the Epic case and clarify that this is an allowed external payment flow. Short version: Epic v. Apple opened the door for external web payments (Stripe) in US apps. A Base44 app can show prices and subscriptions, then send users to Stripe on the web and back. If Apple says “no,” you appeal and point to the Epic ruling instead of rebuilding the app or ripping Stripe out. I have also consulted with my lawyer and he confirms this. Im working out a few bugs on my app and turning into Apple and Google today. I’ll post on here what happens, if it gets approved or rejected.

Israel Mudder About 22 hours ago

💡

Feature Request