SMeet Mini Apps

Rules for mini app authors

Version 1 of 17 October 2026. Everyone who creates a mini app for their bot accepts these rules, and accepts the current version again every time they submit the app for review.

About these rules#

A SMeet mini app is an author's web page that opens in a SMeet window and is connected to the author's bot. The page and its server are run by the author, outside SMeet (except SMeet's own apps, rule 4.2). The author of an app is the owner of the bot it belongs to.

The rules apply to every mini app in SMeet's public space and in organisations, to its production and test versions, and on every device where it opens: in the web app and in SMeet for iOS, iPadOS and macOS. They add to the SMeet Terms of Use and Privacy Policy and do not replace them.

Every rule has a number. SMeet decisions to refuse publication or to block an app name the number of the rule that was broken, for example "rule 2.1".

1. Content and age category#

1.1. Forbidden content. An app may not contain, offer or encourage:

• illegal content and calls for illegal acts;
• sexual content and nudity;
• violence and cruelty;
• harassment, threats, insults, discrimination and incitement to hatred;
• gambling, betting and their simulation;
• alcohol, tobacco, drugs and weapons;
• fraud and phishing, and posing as SMeet, Scrile or another person or company;
• malicious code, hidden mining and attempts to get around the protection of SMeet or of the user's device;
• spam;
• content that infringes the rights of others: copyright, trademarks, privacy.

1.2. Age category. Every app has one category: 4+, 9+, 13+, 16+ or 18+. People see it before they open the app. All of the app's content, including what is available only after signing in, must fit it. The category may not be higher than the App Store rating of SMeet itself. SMeet is rated 4+ now, so only the 4+ category is accepted: the app's content is suitable for any age. An app with a higher category cannot be saved, submitted for review or published. SMeet does not check users' age, so content above the category is not allowed for anyone.

1.3. Description. The title, description and icon say truthfully what the app does. The app works as described, and a reviewer can go through its main scenario.

1.4. Content from users. If people who use your app see what others write or upload, you filter out objectionable content, let people report it and cut off the offender's access, and respond to reports in good time.

2. Payments#

2.1. Digital goods. An app may not sell digital goods or services: subscriptions, paid features, in-app currency, access to content. It may not show buttons, links or texts that lead to such purchases, including through external links (openExternalLink). App stores require their own in-app purchase for such purchases, and mini apps have none.

2.2. No payments in this version. An app accepts no payments in any form, donations and tips included: it shows no payment forms, does not ask for bank card details and does not lead to payment pages. People may place a request or an order in the app; if goods or a service have to be paid for, payment happens outside the app and outside SMeet.

3. User data#

3.1. What SMeet passes. After the person agrees, SMeet passes to your server the person's SMeet user ID (the same one your bot and every other bot sees), the interface language, and the display name only if the app asks for it. Before every launch SMeet shows the person these data and warns that loading the app shows your server their IP address and device information. Along with them your server gets the launch details: the space (SMeet's public space or an organisation), the person's chat with the bot and the parameter of the link or button. Your bot receives the person's display name and @username anyway, in Bot API events. Ask for the name only if you really need it.

3.2. Only for the stated purpose. Data from SMeet and everything the person enters in the app are used only for the purpose stated in the app's description and in your privacy policy. They may not be sold, passed to third parties for those parties' own purposes, used for advertising, for tracking across services or for building profiles, or matched with other data to learn more about the person than they told you themselves.

3.3. A privacy policy is required. Its https:// link opens without signing in. The policy says which data from SMeet and from the app's forms you receive, why, how long you keep them, whom you pass them to, and gives a contact and the procedure for deleting data. You carry out deletion requests as your policy describes. Revoking access in SMeet does not delete data on your side: the person asks you to delete it.

3.4. Support is required. An https:// link to a page or address where the person gets an answer from you.

3.5. Data protection. Protection is no weaker than in the SMeet privacy policy: everything over HTTPS; the author server key (smac1_...) is kept only on the server and never appears in the page, in addresses or in logs; the mini app session (smas1_...) is received and kept only by your server and never reaches the page; the page keeps your app's own session in memory only, and before every protected operation the server checks the mini app session with SMeet (checkSession). If a key leaks, revoke it in the app settings at once.

3.6. No unnecessary requests. Do not ask the person for their SMeet password, sign-in codes or other SMeet secrets, and do not draw screens that look like SMeet's own (sign-in, consent, send confirmation). Do not try to reach the camera, microphone, location or other device features around the SMeet window: they are off in mini apps, and only the person can pick a file. The system file picker may let the person take a photo or video; the page gets only the resulting file.

4. Addresses, embedding and security#

4.1. Your own addresses. The app lives at https:// addresses under your control: the production and test versions have different origins, port 443 or 8443, no IP addresses. You confirm that you control the domain with the file /.well-known/smeet-mini-app.txt holding the app's token.

4.2. The SMeet domain is not available. Addresses on scrile.com and its subdomains are not available to authors. Only SMeet's own apps run at https://messenger.scrile.com/mini-apps/. Rules 1-3, 4.4 and 5-8 apply to them, and instead of rules 4.1 and 4.3 SMeet sets their addresses and headers: the entry points /mini-apps/<name>/app/ and /mini-apps/<name>/app-test/ and the embedding headers on them. The code of these apps is reviewed as SMeet code (review in the repository, no third-party scripts or CDNs, a strict CSP, no user or third-party HTML).

4.3. Embedding in SMeet only. Every page of the app sends the header Content-Security-Policy: frame-ancestors https://messenger.scrile.com (with 'self' added if the app embeds its own pages: frame-ancestors 'self' https://messenger.scrile.com) and does not allow embedding on other sites. Without this header, with any other source in the list or with embedding in SMeet refused, the app cannot be submitted for review or published.

4.4. No third-party HTML on your origin. The app's origin may not serve user or third-party HTML. The SMeet bridge trusts every document of this origin, nested frames of the same origin included, and such a page would get sign-in, sending to the bot and external links on the person's behalf. Serve users' files from a different origin or with the header Content-Security-Policy: sandbox. Third-party scripts you include on the app's origin run with the same powers as your own code, and you answer for them as for your own.

5. Changes after review#

5.1. Settings in SMeet. Any change to the settings of a published app creates a new draft, which goes through review again. Until it is published, the previous version keeps working.

5.2. Changes to the site. The app's site can change without SMeet knowing. A substantial change after review (a different purpose, new data collected, content of another category, new external links) needs a new submission before it goes live; otherwise the app is blocked. Fixes of bugs, design and texts that do not change the app's purpose need no new submission.

5.3. Test version. Only you, the testers you invite and the people reviewing your submission open the test version. The window tells the person that SMeet has not reviewed this version. Do not hand the test version out as the production one, and do not use it to get around review.

6. The author's responsibility#

6.1. You are responsible for the whole app: its content, the work of its server, the processing of users' data, the third-party code and services you use, and compliance with the law, including personal data and consumer protection law.

6.2. SMeet reviews an app before publication, but not every change to your site. SMeet is not responsible for your processing of data and cannot delete data from your servers.

6.3. You answer people through the support link and answer SMeet's requests about reports and review.

7. Review, moderation and blocking#

7.1. Review before publication. An app can be submitted for review once both addresses are confirmed, embedding is limited to SMeet (rule 4.3), the policy and support links are given, the category is not above the allowed one and the current rules are accepted. Apps of SMeet's public space are reviewed by SMeet platform administrators. An organisation's app is approved by the organisation's owner and administrators, and only its members can open it. The reviewer checks that nothing sells digital goods or links to purchases, that the policy names the data from SMeet and a contact for deletion, that the content fits the category and that the scenario works. A refusal names the number of the rule that was broken.

7.2. Reports. People report an app from the menu of its window or from the bot's profile and choose a reason: spam, abuse or harassment, fraud or scam, illegal content, privacy violation, other. Reports are reviewed by SMeet platform administrators within 24 hours. Organisation administrators do not see reports.

7.3. Blocking. SMeet administration can block one app, all apps of an author (their bots and chats keep working), or switch mini apps off altogether for a while. A block takes effect at once, without warning: it closes the app's open windows for all users, ends its sessions and cancels sends the bot has not received yet. The author gets a letter with the reason and can dispute the decision through support (rule 7.5).

7.4. A blocked app cannot be deleted, and a new app for the same bot is created blocked. An organisation can switch mini apps off for itself.

7.5. Send questions about a SMeet decision to support@scrile.com.

8. Versions of the rules#

8.1. The rules have a version number and a date. Version 1 of 17 October 2026 is in force. You see the version number in SMeet when you accept the rules, and SMeet records which version you accepted and when.

8.2. We publish a new version on this page with its date and a list of changes. You can create an app or submit it for review only after accepting the current version. A published app keeps working; if a new version changes what is required of published apps, it names the date by which they must comply.

Version history#