Neblla

Groups of users with a role each (a team, a client), for rows that belong to a group: neblla.db.save(data, { table, group }). Roles and their rights per table are declared with neblla_update_app({ roles }). Actions: "create" { name }, "delete" { name } (with its members; its rows stay), "add" { group, user, role } (user: the user id in the app, as neblla_list_users gives it; adding again changes the role), "remove" { group, user }, "list" (the groups, or { group } its members), "of" { user } (their groups). An employee and a client are different roles in the same group. Also from the admin API and from the developer's server (never a Fog).

The app's API secrets: name, baseUrl, headers, query, limits and fromClient. Never the values.

List all apps owned by the authenticated developer. `shared`: the apps of other developers whose team they are on (neblla_team), with their paper (`access`: partner, support, viewer or screens) and what it lets them do on each area (`can`: read | write | null), and `invitations` waiting for them to accept (in the panel, «Compartido contigo»). On a shared app, use the tools its paper allows; the rest answer not_allowed.

The app’s automations with their schedule, action, next run and the result of the last one.

List communications across ALL users of an app, filtered and sorted. The most useful tool for triaging an inbox: show only unread, only messages from users (not the dev), only flagged-important, or only those mentioning a given email. Returns flat items with userId so you can follow up via neblla_send_communication on each thread.

List the community entries (user-published content, neblla.community) of an app from the backoffice, any status. Use it to triage the moderation queue: status "pending" is what awaits approval in review mode. Returns indexed metadata only (title, summary, category, tags, contentType, owner, status, moderation record, and stats: favorites, rating, reviews, uses, upvotes, downvotes, score); fetch a payload with neblla_get_community_entry. Paginate with `cursor` = the previous `next`.

The users who asked, from inside your app (neblla.auth.requestErasure), that you erase the data they gave it. Erase one with neblla_erase_user (its userObjectId); that closes the request. Pending ones by default.

List the files of an app's pre (what is being edited; neblla_promote "diff" says how it differs from what the users have). Returns path, mimeType, size, and timestamps for each file.

The app’s Fog cases, newest first: when the Fogs running a room’s server file computed different states, Neblla compared them, the majority won, and the odd one’s user was flagged. Each case: room, seq, status (flagged | undecided | reassigned | annulled), fogs (userId, appUserId, leader, verdict: majority | odd | missing | undecided), diff (only the paths that differ), flagged. Undecided: no majority (two Fogs, or three different states) — nobody was flagged.

The app’s incoming webhooks: name, to, room. Never their tokens (make one again for a new URL).

List the app-level moderators (per-app user ids). App moderators manage rooms of any type and moderate the community. They are the members of the app's reserved group `moderators`, which lives in its data: a pre on pro's data has pro's, a pre with its own data its own (empty at first; env "pre" to see it).

List all products for a Neblla app.

List the gallery reviews of an app (a review id — pass it as reviewId to neblla_reply_review, rating 1–5, text, language, author display name, the developer's reply) plus the average, count and 1–5 distribution. Newest first.

List the persistent / predefined rooms of an app with their type, owners, whitelist, moderators, data, message count, last activity, their own inactivity days (`ttlInactivity`, null = the app's per-type value), how many players follow each one (`followers`: they get a notice when someone writes while they are away) and how many users are in each one right now.

List end users of an app — the people who connected through the SDK, NOT the developer's own account. Use this as the entry point for the backoffice flow: it returns a paginated list with each user's mongo `_id` (needed for every other backoffice tool), email, name, language, and stats. Pass `withCommunicationsOnly: true` to get only users who have communication threads — useful when triaging support.

The app’s last outgoing webhook deliveries (neblla_update_app({ webhooks })), newest first: event, secret, path, at, ok, and the endpoint’s status or the error.

Moderate a community entry as the app owner: approve or reject a pending entry, remove a published one, suspend a published one while a case is open, or restore a rejected/suspended/removed one. `suspend` hides the entry but is reversible and keeps everything; `remove` is the final one. `reject`, `remove` and `suspend` require a `reason` from the fixed taxonomy; the author receives the reason and your `message` live (communityUpdated) and in their own list. `reason` is one of: copyright, inappropriate, hate, harassment, spam, illegal, privacy, other. Note which queue you are working: the automatic action at the report threshold leaves the entry with status `pending` and `moderation.by = "reports"`, alongside entries merely awaiting first approval. `remove` keeps the entry and its payload so an appeal can be honoured.

Rename or move a file within an app. oldPath is the current path, newPath is the destination. In an app linked to its own repo, one commit on pre's branch.

The developer's payout account (Stripe Connect), needed to sell products inside their apps. "status": none | pending | active | restricted, with chargesEnabled / payoutsEnabled. "onboarding_link": the neblla.com page where Stripe's own onboarding opens inside the developer's Neblla session, where they verify identity and add a bank account (a human must do it; never ask for bank details or documents in the chat: Stripe collects them there, Neblla never sees them); the first time it opens the account. A developer who already uses Stripe signs in with it there. Paid products waiting for the account publish by themselves once it is active. "dashboard_link": the developer's own Stripe Dashboard (payments, payouts, refunds, disputes, taxes); they sign in with their Stripe login. The account is the developer's: Stripe's fees, refunds, disputes and any negative balance are on it, not on Neblla. "disconnect" stops Neblla selling on their behalf and HIDES every paid product from users; the Stripe account itself is kept, so reconnecting later returns to the same one. It needs confirm: true, and only when the developer asked for it in as many words. Products stay hidden from users until the status is active. Commission: Neblla takes 1 % of each sale, before tax; Stripe's own fee is separate and paid by the developer's account (the charge is made there: the developer is the seller).

Who else may open the app's PRE (its private test version at play.neblla.com/pre/<slug or id>/). The developer always can. Two ways in: Neblla accounts by email (they sign in on the pre page), and links with a password for people without an account. Either can have an expiry. Once in, a person keeps a pass for 4 hours even if they sign out, so they can play as a guest; removing someone stops new passes, not one already given. Actions: "list"; "add" (email, expiresAt?) — let an account in, or change its expiry; "remove" (email); "link" (password?, expiresAt?, label?) — a new link; without a password one is generated. The password is returned ONCE: give it to the developer and never store it; "revoke" (linkId); "renewLocalKey" — a new local key, the old one stops working. Each action returns the current list. The list also has `local`: { key, tag }, the app's local key. A page on localhost (the developer's machine) opens only the app's PRE, and only with the tag that carries it: <script src=".../connect/app/_<appId>?pa=<key>">. Give the tag to the developer for their local index.html; never put the key in a page that is published.

Which data the app's PRE (its private test version) plays with. "own" (the default): its own users, saves, tables, inbox and community, empty at first and apart from the users'. "pro": the users' real data, read and written for real. Rooms are always pre's own, so testers never share a live room with users. Changing it signs out whoever is signed in to pre. Without "use", returns the current one. Switching to "pro" lets pre's unreleased code write the users' data: only when the developer asked for it.

Whether the app's PRE sells through Stripe's TEST mode: on by default, so testers buy with Stripe's test cards and nothing is charged. Pre always sells the app's own products (one catalogue); in test mode it also lists the ones not published yet. Test purchases are marked as such: pro never counts them, not even when pre plays with pro's data (neblla_pre_data), and there they give no credits. Without "on", returns the current value. Also says "testMode" ("separate": the developer needs a test account of their own, opened at onboardingUrl with Stripe's test data; "same": this server is in test mode and the payout account serves; "off": no test mode here, so pre test purchases fail) and "account" (the state of that account). Turning it off makes pre charge real money on the payout account: only when the developer asked for it.

Every app has two environments. PRE is where every change from this MCP and the dashboard lands (files, modules, rooms, theme, AI…); the developer plays it at a private link. PRO is what the users have: it never changes until this tool sends pre to it. Actions: "diff" — what would change (files added/changed/removed, settings that differ; differs:false means pro already matches; `promotedAt` is when the users last got a version; `queued` is null, except for a send made before publishing became instant that has not landed yet: { at, files, nextBatchAt, capped, failed, deployed }, which Neblla lands on its own within minutes); "promote" — "Pasar a pro": pre's files, server code and settings, as they are now, reach the users all at once, right now (returns { queued: false, live: true, promotedAt, files, message }; `settingsOnly: true` when only settings changed). Tell the developer: "Publicado: ya se ve" (published, the users see it now). Behind the scenes Neblla serves it at first and moves it to the CDN in a later batch without anything visible changing; nothing to wait for or report. A promote costs no credits. Confirm with the developer first; a rooms change that discards saved data needs confirmRoomsChange. "reset" — throw away pre's changes and go back to what the users have (confirm first). "releases" — the last versions the users had (Neblla keeps the last 10), newest first: { keep, releases: [{ id, at, by: { email, via: "dashboard"|"mcp" }, changes: { first, files: { added, changed, removed } each { count, paths }, settings: [field] }, files, rollbackOf, current }], queued }; an entry with id null is a release from before the history and cannot be sent again. "rollback" (releaseId) — send an earlier version back to pro, whole (its files, server code and settings as the users had them), at once, like "promote" (same answer: live, promotedAt…). PRE IS NOT TOUCHED: the developer's draft stays as it is, so the next "promote" sends pre again. The version comes back to the list as a new one with rollbackOf. Confirm with the developer first; a rooms change that discards saved data needs confirmRoomsChange. In git, each environment is a branch (the developer's repo when linked with neblla_git, else Neblla's, see neblla_versions): when the version goes out, pre's branch is merged into pro's. The app's name, slug, publishing and bans are not per environment: they change at once, for both. The moderators follow the data, like the players: a pre on pro's data has pro's, a pre with its own data its own (neblla_set_moderator).

Publish a Neblla app to the public gallery. BEFORE calling this tool you MUST follow these steps with the user: 1) Ask for the app title and a short description (1-3 sentences) in the user's language. 2) Ask for the gallery section: "multiplayer" (games/apps where users interact in real time), "singleplayer" (games/tools for one person at a time), or "app" (everything else — utilities, tools, sites). 3) Ask for tags that describe the app (e.g. "puzzle", "multiplayer", "drawing"). 4) Ask what devices the app is best suited for: "mobile", "desktop", or omit for both. 5) Ask if the user wants to upload a cover image — pass an http(s) URL, a data: URI, or raw base64 JPEG/PNG. It will be auto-scaled to 400x400. 6) Provide the title and description in at least the user's language. The app is listed in the gallery ONLY for visitors whose language is one of those given (en, es, fr, de, it, pt, ja, ko, zh, ar — the languages of the Neblla website and gallery; they limit only the listing, never the app, which can use any language), and nothing is translated for you. Add other languages only if the developer wants visitors (and reviews) in them, and can read what those visitors write. Set defaultLang to the language the user originally provided the content in. titles and descriptions MUST each contain at least one entry in the same language.

Publish a community entry AS YOURSELF — owned by your own user in the app (the app user whose email is your developer email; it is created on first use if you never opened the app). Use it to seed a community with starter content. It skips the review queue (you are a moderator of your app) and obeys the same rules as neblla.community.publish: community must be enabled, contentType/category must be allowed, payload ≤ maxPayloadBytes, no "$"/"." keys.

The developer’s app as its OWN app in the stores, with THEIR developer account (Android now; iOS after). store "google": action "set" { packageName (e.g. com.studio.game; fixed once published), serviceAccountJson (a Play service account with release rights, kept sealed), track? (internal|alpha|beta|production), certs? (the app signing SHA-256 from Play Console → App integrity: the app then opens full screen) }; "build" builds the Android bundle from the app’s page (play.neblla.com/<slug or id> or its own domain) and uploads it to that track — it runs in the background: call "status" for the result; "status"; "remove" forgets the Play credentials (the upload key stays, or Play would refuse the next version). The first version of a new app must exist in Play Console (create the app there first). Never reuse credentials from elsewhere: ask the developer.

Answer a review of an entry in your app's community, as the app: the answer shows under the review for everyone. One answer per review; sending another replaces it, and text null takes it back. reviewerId is the review's author.id (neblla_get_community_entry lists the latest reviews). The entry's author can answer from the SDK too (community.reply).

Publish (or replace) the developer's public reply to a review; pass `text: ""` to delete the reply. The reply is shown in the gallery, translated into the reviewer's language when `developerLang` differs. Public text: show the developer the wording before sending.

Change the palette and/or typography of an app created with the wizard or neblla_create_app, AFTER creation. Re-bakes only the theme tokens (--nb-bg, --nb-primary, …, --nb-font-title, --nb-font-body) in main.css and the Google Fonts link in index.html; every other line stays as the developer left it. Tokens the developer deleted are not put back: they come back in `missing`. Stores the theme on the app. (neblla_update_app with `theme` only stores it, without touching the files.)

Run an automation now, to try it (its schedule does not change).

See a panel as the back office shows it: { appId, name, inputs? } → { title, columns, filters, actions, rows }.

The app's sales (Dinero › Ventas in the dashboard): action "list" { status?, productId?, from?, to?, skip?, limit? } — newest first, each with product, units, paid (minor units) and currency when known, status (completed | refunded | charged_back | ended), refund and dispute, the buyer's userId, email and buyerName, canRefund. "documents" { saleId } — the links Stripe keeps for the buyer: a payment's receipt (receiptUrl) or a subscription's invoices (url, pdf); nothing is stored. "refund" { saleId } — gives the WHOLE payment back in Stripe (Neblla's 1 % with it) and takes the purchase back at once (the player loses it, credits and paid bookings go back, the app hears a "revoked" purchase and the refund webhook fires). A subscription is not refunded here (not_refundable, reason "subscription"): the developer refunds or cancels it in their Stripe dashboard, at the sale's stripeUrl. Money leaves the developer's account: confirm with them first. The CSV downloads are in the dashboard (POST /api/backend/apps/:appId/sales/csv and /users/csv).

The rankings of a game for one (neblla.scores; boards declared with neblla_update_app({ scores })). action "top": the best of a board, { board, period: "all" (default) | "day" (today, UTC), limit (≤ 100) } → [{ place, player, value, at, info }]; action "player": one user's standing { board, player } → { best, bestAt, dayBest, runs, place } or null; action "remove": take a user's score off a board { board, player } (a cheat that got in). Refused scores never enter: they are in the app log (neblla_get_logs, area score).

Find users of an app by a partial email match (min 2 characters). Returns the matching user docs with email, communications, data, stats, and language. Use neblla_list_users for full pagination instead when no email is known.

Send a message from the developer to a specific end user. The user receives it live via the SDK's `communicationUpdated` event if connected, and on next reconnect otherwise. Optionally attach a `data` JSON payload (rendered by the app), or a calendar/appointment proposal via dateFrom/dateTo. Set `thread` to the id of an earlier communication to group replies. BEFORE calling: confirm the message wording with the developer (you are speaking to their users on their behalf).

The app's server key, for running room.js on the developer's own server (serverMode "own", see neblla_get_llms({ section: "servidor" }) "Server"). Their server runs `npx @neblla/server --app <appId> --key $NEBLLA_SERVER_KEY ./server`: it calls Neblla, no open ports or public URL. action "create" makes the key (refused if one exists), "rotate" replaces it (the old one stops at once), "status" says whether one exists, "revoke" removes it. The key is returned ONLY by create and rotate: it goes in the server's environment, never in the app.

Create or change an API secret: an external API the app reaches with neblla.api.call(name, path, body) without a server of yours. Neblla fills the secret in where {secret} appears in `headers` or `query`, and calls only under `baseUrl` (https, a public host). The value is written and never read back (neblla_list_api_secrets shows everything else); on a change, leave `value` out to keep it. From the server file (room.js…) it always works; from a user's client only with fromClient: true. Limits: loggedInOnly, calls per user per minute / hour / sixHours / day / week / month, and a whole-app cap per day / month (0 or absent = none). The bytes both ways count as quota.

Create or replace an automation: a scheduled action on the app (open a room, hand a room data, call one of your API secrets). For flows across the tools the developer already uses, n8n, Make or Zapier connect through the admin API, incoming webhooks and outgoing webhooks. when: { at: ISO date } once; { every: minutes } (5 – 10080); or { daily: "HH:MM", days?: [0–6, 0 = Sunday], tz?: "Europe/Madrid" (UTC by default) }. action: { kind: "openRoom", room, config?, openForMinutes? (60) } books the room with its config, so whoever enters first finds it in neblla.room.config; { kind: "message", room, data } hands data to that live room’s server file as neblla.room.on("hook", ({ name, data }) => …) (name = this automation); { kind: "callApi", secret, path, method?, body? } calls one of your API secrets (neblla_set_api_secret). Up to 50 per app; each run is recorded in lastResult. Or, instead of action, a ready-made template: template "booking.reminder" { set, secret, path?, hoursAhead? (24) } — one call per booking starting soon, each once ({ event, player: { id, name, email if granted }, slot, booking }); "community.digest" { days? (7), limit? (10), secret and/or room } — the week top entries; "game.dailyTournament" { board, day? ("today" | "yesterday", UTC), top? (10), secret and/or room } — the day's top of a protected ranking (neblla.scores, declared with neblla_update_app scores), kept and announced as { event, board, day, ranking: [{ place, player, value, at, info? }] }; or { table, field, top?, hours? (24), secret and/or room } — the rows of one of your tables in the period, which players can write.

Set a user's ban state in this app: "none" (lift), "banned" (the app shows the ban message and blocks play; Neblla refuses everything but their messages to you), "terminated" (blocks them for good: their device is sealed so the app no longer opens there, and they are disconnected), "community_muted" (can play, and can still REPORT entries, but cannot publish, rate or review). Takes effect live. WARNING: "terminated" seals the user's device, and lifting it with "none" does not unseal a device that is already sealed (the user has to clear the site's data) — never pass it unless the developer asked for that specific value. The other two are fully reversible with "none". This tool keeps no reason, no note and no history: if the developer needs a record of why someone was sanctioned, write it yourself with neblla_send_communication or in a community case note. Confirm with the developer before banned/terminated.

Toggle the "important" flag on a communication. This is dev-only metadata and is NOT broadcast to the end user — use it to bubble messages to the top of your own triage view.

Mark a specific communication as read or unread (from the developer's side). The end user is notified live via a `communicationRead` socket event if connected.

Make a user an app moderator (`moderator: true`) or remove them (`false`): it adds them to, or takes them out of, the app's reserved group `moderators`. `userId` is the per-app user id (from neblla_list_users with the same env), not an email. The group lives in the app's data: with env "pre" and a pre with its own data, it names a moderator of pre (the developer adds themselves to moderate there); a pre on pro's data shares pro's.

Create, replace or (panel: null) remove a back office panel: a screen for the developer and their team. panel: { title, source: { table } | { booking: set } | { credits: kind }, columns: ["field" | { field, label }] (player.name, start, title… too), where: { field: value | { gte: "$today", lt: "$tomorrow" } } (dates: $now, $today, $tomorrow, $weekStart, $monthStart, $nextMonthStart), filters: [{ field, op?, label?, type? }] the person fills in, orderBy, limit (≤ 500), actions: [{ label, call: "booking.cancel" | "booking.move" | "credits.adjust" | "table.remove" | "table.save", args: { … "$row.field" | "$input.name" }, confirm? }] — on each row; or call "booking.createSlot", a button over the panel with a form (title, start, minutes, capacity, and how it repeats as in a calendar: freq, interval, byDay, byMonthDay, until or count), args filling it in beforehand }. e.g. "Reservas de hoy": { source: { booking: "clases" }, where: { start: { gte: "$today", lt: "$tomorrow" } }, columns: ["start", "title", "player.name"], actions: [{ label: "Cancelar", call: "booking.cancel", args: { refund: true }, confirm: "¿Cancelar?" }] }. A { booking } panel lists every slot of its range, free or not: a row per booking (with capacity and left, the places left) and one row with status "free" and no id for a slot nobody booked; row actions only on booking rows. Panels see every table and user: they are for the back office, never the app.

Check, set or clear the app's public slug (the readable name in play.neblla.com/<slug or id>). `checkOnly: true` only tells whether it is valid and free; when another app of YOURS holds it (its slug or an old one) it says so (`reason: "yours"`, `heldBy`). `slug: null` removes it. An old slug keeps leading to the app (it stays the app's; nobody else can take it), and the users' sessions follow. `move: true` takes a slug from another app of yours (e.g. moving a game to a new app): the other app loses it and its address leads to this one from then on. At least 5 characters. Changing it changes the public URL — confirm with the developer.

Read an app table across users: filters on declared fields, order, page, or just a count. e.g. { table: "reservas", where: { clase: "yoga-martes", estado: "confirmada" }, count: true }, or { table: "puntos", orderBy: "-score", limit: 10 }. Rows come with id, owner (the user id in the app), createdAt, updatedAt.

Write or remove one row of an app table by hand (support, a fix): action "save" with { owner, data } for a new row of that user, or { id, data } to replace an existing row; action "remove" with { id }. Users never see other users’ rows; this is the developer side.

Taxes on the developer’s sales to users, with Stripe Tax on their own payout account (they are the seller; the taxes are theirs, Neblla only sets it up for them). "status": settings status (active/pending, and what is missing), head office, defaults and active registrations. "set_head_office": the business address ({ country, postal_code, city, line1, state? }). "set_defaults": the default product tax code (txcd_…, e.g. txcd_10000000 for general digital goods — check with the developer) and tax behaviour. "add_registration" / "expire_registration": the jurisdictions where the developer is registered to collect tax ({ country, type, state? } — type as Stripe names it, e.g. "standard", "oss_union", "state_sales_tax"); with no registration in the buyer’s location no tax is collected. "report": itemized tax transactions — call with { from, to } to start it, then with { runId } until it returns a download link. "app": switch automatic tax on or off for one app’s checkouts ({ appId, automatic, inclusive? }); it only applies while the settings are active. By default the price INCLUDES the tax (what a European consumer expects); { inclusive: false } adds it on top (usual for businesses or the US). Neblla’s 1 % stays on the pre-tax amount either way. Registering with a tax authority is the developer’s legal step — never add a registration they have not confirmed. The same settings and the tax reports are also in the developer’s own Stripe Dashboard (Tax).

The developer’s team for an app (Gente › Tu equipo in the panel): people who sign in to developers.neblla.com with their own email, and use this MCP with their own account, each with a paper (`access`) that the server applies on every route of the panel and every tool here: "partner" (Socio: everything but money, the plan and deleting the app), "support" (Comunidad y soporte: the people of the app — users, inbox, bookings, community, groups, moderation — and the sales, read only), "viewer" (Solo mirar: everything, read only) or "screens" (Solo una pantalla, the default: only the custom screens given in `panels`). A call the paper does not allow answers not_allowed. action "add" { email, access?, panels?: [names] | "*", role?, expiresInDays? } invites them: an email goes out and they accept it signed in with that address, within expiresInDays (1-30, 7 by default); on someone already there it changes access, panels or role (a pending invitation is sent again with a new date). "resend" { email, expiresInDays? } sends a pending or expired invitation again. "remove" { email } takes them (or their invitation) out at once. "list" → { team: [{ email, access, panels, role, status: active | invited | expired, expiresAt?, invitedBy? }] }. role: one of the app's roles (neblla_update_app({ roles })) — the member then also sees every panel over what the role can read, and presses its buttons where it can write. Only the owner changes the team. Who opens the draft (pre) is neblla_pre_access.

Trades between the app's users (C170: neblla.db.offer / acceptOffer; what is tradable is neblla_update_app({ trade })). Action "list": the log, newest first, with { user? (their id in the app), status? (pending | done | declined | cancelled | expired | failed | all, the default), limit?, offset? } → { trades, total }; each trade has from, to, give, get (items { table, id } or { product, amount }), status, reason (why it failed or was cancelled), createdAt, expiresAt, closedAt. Action "cancel" { id }: take a pending offer back (support, abuse); both users hear it. A trade that was done is not undone from here.

Remove an app from the public gallery. The app keeps its files and URL — only its public listing is hidden. Use neblla_publish_app to re-publish.