Technical terms & conditions

1. Purpose and scope

This document describes Saturn Studio ("the Platform"), the cloud workflow-orchestration component of the Rocketbot Suite: functional capabilities, technical limits, operational restrictions and responsibilities by module and plan. Saturn is not sold or billed as a standalone product: it is only contracted within a Suite plan.

2. Workflow Builder

A no-code visual builder for designing flows via drag-and-drop, with conditional logic, loops, data transformations and integration with external services. The number of flows is unlimited on every plan (subject to the plan's practical execution limits). Custom JavaScript functions are available from Standard up (limited mode) with advanced capabilities on Corporate — their use is the Client's responsibility; the provider does not guarantee the behavior of such code.

3. Integrations

A catalog of 500+ standard apps and components on every plan, inbound webhooks, a native connector to Rocketbot RPA robots, Human-in-the-Loop capability, and connection to third-party LLMs (every plan). Custom apps are available in limited form on Standard/Enterprise and in advanced form on Corporate; Enterprise Apps (connectors to specialized corporate systems) are Corporate-only. When a flow sends information to an AI model hosted outside the Rocketbot environment, the processing and security of that information are subject to that model provider's terms — Rocketbot is not responsible for the security of data once transferred outside its environment.

4. Execution engine

Processes flow instances, managing concurrency, execution times, queues, priorities and files. It is the component most sensitive to the plan's technical limits:

The maximum time per flow is a hard ceiling: an execution that reaches it is terminated by the Platform. Once the concurrent-process limit is reached, new requests queue until capacity frees up.

5. Monitoring, governance and security

Includes execution history, detailed logs and analytics dashboards, with FIFO retention by plan (for greater retention needs, the Client must periodically export logs at its own responsibility). Audit logs of administrative actions are available on every plan.

2FA on every plan; Google/OAuth SSO on every plan and Active Directory exclusive to Corporate; encrypted secrets store from Standard up (not present on Entry 1, so production use with sensitive credentials is not recommended on those plans); encrypted TLS communication and logical tenant isolation on every plan.

6. Support and responsibilities

Support is defined at the Suite level. Client: size the plan, design flows within technical limits, manage credentials and their rotation, avoid confidential data in logs, export evidence when the plan's retention is insufficient, configure access and 2FA. Provider: availability per the plan, patches that do not affect the Client's flows, maintenance notices, technical support, encryption in transit and at rest, tenant isolation.

The breakdown of shared responsibilities between the Client and the provider is described in the responsibility matrix.

7. Limitations

The Platform does not guarantee the behavior of the Client's custom JavaScript code or apps, nor the availability of integrated external services. It does not natively provide Git-style versioning, separate DEV/QA/PROD environments, or forensic evidentiary integrity over logs. AI Studio's accuracy within flows is subject to the limitations of generative AI models and must be validated before production use.

The Spanish-language version of this document is the official version; any existing translations are for reference only.

1. Purpose and scope

This document describes RPA Studio ("the Studio"), the integrated development environment (IDE) for building RPA robots within the Rocketbot Suite: its capabilities, components, technical limits and conditions of use. It applies to any Client using RPA Studio under any Suite plan. It is a technical, descriptive document, not itself a contract or binding SLA.

2. Architecture and service levels

RPA Studio is a cross-platform desktop application installed on the Client's developer workstations: robots are built, tested and debugged there, then published to the central repository for production execution. Access is authenticated against the Orchestrator, with 2FA on every plan and SSO depending on the plan.

It is offered on every Suite plan. The Studio's only quantitative limit of its own is development licenses per plan:

3. Robot editor

A visual command-composition environment with conditional logic, loops, variables, error handling, and step-by-step local execution for testing and debugging. The number of buildable robots is unlimited on every plan; production execution runs through the Orchestrator and is subject to the plan's process quota. Formal versioning of published robots is the responsibility of the Orchestrator's repository.

4. Commands and modules

A catalog of official commands and modules maintained by the provider: interaction with graphical interfaces (clicks, typing, screen reading), integration with APIs, databases and web services, and custom command development by the Client. The catalog may vary due to changes in integrated external systems; the provider does not guarantee its permanent availability. Custom commands and modules developed by the Client or third parties remain the Client's responsibility for security, maintenance and regulatory compliance — the provider is not liable for errors or vulnerabilities introduced by such code. Automating third-party systems must respect those systems' terms of use.

5. Publishing, lifecycle and security

Robots are published to the Orchestrator's centralized repository, which manages their versioning and production updates; promotion between stages (development, QA, production) is managed through the Client's own organizational procedures, and the Client is responsible for testing robots before publishing them to production.

Robot credentials must be managed through the Suite's secure mechanisms (never in plain text). When a robot sends information to services outside the Rocketbot environment (including third-party AI models via AI Studio or direct integrations), the processing and security of that information are subject to the terms of the external service chosen by the Client. Security of the workstations where the Studio is installed is the Client's responsibility.

6. Support

Support is defined at the Suite level and applies equally to every product. First-response times are measured in business-hour minutes (5×8); 24/7 coverage carries an extra cost on every plan, and meetup support is included from Standard up. Support does not include, absent express agreement, robot development or administration of workstations.

7. Technical responsibilities

Client: manage development-license allocation without exceeding the plan; keep development workstations secure and compatible; design, test and maintain robots as automated systems change; verify the regulatory compliance of its automations; implement compensating controls for stage separation and change approval when not natively supported.

Provider: keep installers, official modules and documentation available; fix reproducible defects; notify material changes.

The breakdown of shared responsibilities between the Client and the provider is described in the responsibility matrix.

8. Limitations

RPA Studio is a build tool; production operation (scheduling, dispatch, monitoring, logs) is governed by the Orchestrator's technical terms. The provider does not guarantee a robot will keep working indefinitely without maintenance as automated systems change. Using RPA Studio for actions requiring professional judgment, regulatory decisions or third-party consent is the Client's sole responsibility.

The Spanish-language version of this document is the official version; any existing translations are for reference only.

1. Purpose and scope

This document describes Rocketbot Orchestrator ("the Orchestrator"), including its Xperience forms and self-service portal module: functional capabilities, components, technical limits and per-plan conditions. It is not sold as a standalone product; it is contracted within one of the Suite's five plans.

2. Architecture and Process Control

Operates on a client-server model: the server centralizes administration, scheduling, queueing and persistence, while agents installed on the Client's hosts run assigned robots and report results back. Process Control is the unified (single-instance) management interface: robots, agents, calendars, queue, users, roles, logs, reports and Xperience forms, all subject to the RBAC permission model.

3. Robot, agent and scheduling management

Publishing, versioning and tagging of robots in the central repository; registration, monitoring and configuration of agents (which register with no quantitative limit — effective capacity is governed by the plan's process quota). Scheduling supports cron expressions, webhook triggers, chaining on another robot's completion, or triggering on submission of an Xperience form.

4. Queue, execution engine and logs

The queue enqueues, prioritizes and assigns executions to the best-available agent according to tag, capacity and priority rules (designed by the Client). The Orchestrator natively stores four log types (Robot, Process, User, Instance) with mandatory recording of input data and of the component where each error occurred, queryable from Control Room or via API. Retention depends on the plan; for greater regulatory needs, the Client must periodically export logs. The Orchestrator does not natively apply forensic evidentiary integrity (digital signature, TSA timestamping) — where formal evidentiary guarantees are required, external compensating controls must be implemented.

5. RBAC, repository and Xperience

Role-based access control operates at the level of Process Control's single instance, with Google/OAuth SSO on every plan and Active Directory exclusive to Corporate. The robot repository is an artifact store (it does not replace a Git-style version-control system). Xperience, included on every plan, allows public forms (no login) or private forms (login and role-based permissions) whose submission automatically triggers an execution; it has no quantitative limit of its own — the real limit is governed by the plan's process quota, and the Client must design public forms to avoid exposing sensitive data or abusive triggering.

6. Plan limits

7. Security, integrations and support

2FA on every plan; Google/OAuth SSO on every plan and Active Directory on Corporate. The Orchestrator is the Suite's single identity provider. TLS communication, an encrypted store for robot credentials, and authenticated symmetric encryption (Fernet / AES-128-CBC+HMAC-SHA256) of robot steps in the repository, with key rotation via MultiFernet. The REST API enables integration with Client systems under its own authentication controls. Support is defined at the Suite level, with first response in business-hour minutes (5×8), 24/7 event coverage at extra cost, and meetup support from Standard up.

8. Responsibilities and limitations

Client: size infrastructure and agent hosts; in on-premise mode, administer the OS, network and perimeter security; manage credentials and their rotation; design robots and forms to avoid exposing confidential data; keep agents up to date; configure RBAC with least privilege; export logs when the plan's retention is insufficient. Provider: availability per the plan; updates and patches; maintenance notices; technical support; encryption in transit and at rest depending on deployment mode.

The breakdown of shared responsibilities between the Client and the provider is described in the responsibility matrix.

The Orchestrator does not natively provide separate DEV/QA/PROD environments within a single instance, nor Git-style version control over robot code; where required, these controls must be implemented via separate instances or external tools under Client administration.

The Spanish-language version of this document is the official version; any existing translations are for reference only.

1. Purpose and scope

This document describes AI Studio, the Rocketbot Suite component focused on intelligent processing of unstructured content (emails, documents, audio, images) and its conversion into actionable structured data using generative AI, NLP and OCR. It is provided exclusively in SaaS mode: infrastructure runs on AWS with integration to Microsoft Azure AI services (including OpenAI), and the Client accesses it via browser over an encrypted connection.

2. Processing modules

Email AI connects Gmail, Outlook, IMAP and POP3 accounts (via OAuth 2.0 for Gmail/Outlook), interprets the email body with NLP and extracts Client-defined fields, triggering follow-up actions. Documents AI converts PDF and TXT into structured information without prior training; scanned documents with no embedded text must be processed via Image AI instead. Voice AI transcribes audio (MP3/WAV, including WhatsApp voice notes, max. 25 MB) and extracts key data from the transcript. Image AI applies AI-powered OCR to PNG, JPEG, JPG, WEBP and non-animated GIF.

Each module's accuracy depends on the quality of the source content (resolution, noise, document structure). Content processed by these modules is sent to the AI services described in section 1; the Client must consider the nature of that content, especially where personal data or regulated information is involved, and obtain the necessary consents from data subjects.

3. Actions and outputs

After extraction, AI Studio can execute actions: display in Data View, sending/receiving via WhatsApp, sending email, integration with Rocketbot Xperience to trigger automations, or calls to the Client's external APIs (CRM, ERP, proprietary systems). The effective availability of each channel depends on the Client having contracted the underlying services (e.g., WhatsApp Business API); AI Studio is not responsible for the availability of those external systems.

4. Credit model

AI Studio is not sold as a standalone product: credits are allocated as an annual quota within each Suite plan, with no rollover to the next cycle. One credit equals one character processed by the AI model (letters, numbers, symbols and punctuation). AI Studio's internal model is available on every plan; from Standard up, the Client may also connect its own external model (Bring Your Own Model, e.g. Azure OpenAI or Amazon Bedrock).

Actual consumption depends on the content processed; retries caused by Client-attributable errors (malformed content, misconfigured tasks) may generate additional consumption.

5. Security

HTTPS/TLS 1.2 communication, JWT authentication, traffic filtering via WAF, sensitive-credential management via KMS, persistence on Amazon RDS, and logical tenant isolation. Access tokens for external providers (Gmail, Outlook, Drive) are subject to each identity provider's own security policies. When the Client connects an external AI model (Bring Your Own Model), the processing and security of the information sent are subject to that provider's terms — the Suite provider is not responsible for the security of data once transferred outside the Rocketbot environment. AI Studio's internal model, operating within the Rocketbot environment, is not subject to this exclusion.

6. Support and responsibilities

Support is defined at the Suite level (first response in business-hour minutes 5×8, 24/7 event coverage at extra cost, meetup support from Standard up) and does not include, absent express agreement, use-case definition or fine-tuning of extraction instructions. Client: assess the nature of content before bulk upload; obtain necessary consents; manage and rotate connection credentials; validate model output before high-impact automated decisions. Provider: availability per SLA; the security controls in section 5; notice of material changes; up-to-date technical documentation.

The breakdown of shared responsibilities between the Client and the provider is described in the responsibility matrix.

7. Limitations on AI outputs

AI model outputs are subject to inherent limitations: possible errors on ambiguous content, variability across similar inputs, biases from training data, and hallucinations not grounded in the input content. The Client must implement validation controls proportional to the impact of automated decisions, including human review (Human-in-the-Loop) in critical scenarios. AI Studio does not replace document-management, CRM or ERP systems, and its outputs should not be treated as professional advice (legal, accounting, medical, financial).

The Spanish-language version of this document is the official version; any existing translations are for reference only.

1. Purpose and scope

This document describes Nexus, the Rocketbot Suite's low-code SaaS platform for internal applications: architecture, modules, commercial editions, technical limits and conditions of use. Nexus is sold as a SaaS component included in every Suite plan.

2. Architecture

Nexus is a client-server web application: the frontend is a Single Page Application with the visual editor and the runtime for published apps; the backend exposes a REST API, orchestrates query and function execution, and persists metadata in a relational database. The main entities are: Application, Screen (with version history), AppTable, DataSource, Query, JsFunction, ApiCall and Action.

3. Visual builder and component catalog

A drag-and-drop editor over a 12-column grid (x + w ≤ 12 constraint, no overlap), with a properties panel, an actions panel, an embedded code editor and real-time preview. The component tree is serialized as JSON and versioned automatically; simultaneous editing of the same screen follows a last-write-wins policy. It includes 30+ prebuilt components (layout, input, display, data, chart, media, upload and invisible). The Div component allows free HTML and JavaScript at the Client's own responsibility, subject to the platform's strict Content Security Policy.

4. Data Sources, Queries and JS Functions

Data Sources connect internal databases, external databases (MySQL, PostgreSQL, Supabase, Google Sheets, S3) and Suite components (Orchestrator, Saturn Studio, and an On-Premises Gateway for sources behind a corporate firewall, with no inbound ports required). Credentials are encrypted at rest and the backend never returns them in plain text to the frontend.

Queries are declarative operations (SELECT, COUNT, INSERT, UPDATE, DELETE) with parameterizable filters via mustache-style bindings, always executed with prepared statements (SQL injection is not possible). JS Functions run Client code in a server-side sandbox with controlled access to helpers (params, query.execute, table.list, api.execute, $user, etc.), with no direct network access, filesystem access, or access to server runtime components outside those helpers.

5. API, MCP Server and Suite integrations

Nexus exposes a full REST API (/api/v1), API-Key-authenticated external endpoints for headless integration (e.g., with Orchestrator robots), and an MCP server (/mcp) that lets AI clients (Claude Desktop, Cursor, etc.) create and modify applications through a controlled set of tools. Using the MCP Server means an external AI client can modify the Client's applications; it is the Client's responsibility to restrict the scope of issued MCP Keys and review changes before publishing them to production. The ROCKETBOT_ORCHESTRATOR and SATURN_STUDIO data sources enable direct integration with those Suite products.

6. Plan limits

7. Actions-based billing model

Nexus bills by Actions: a unit of useful work executed by the system. Reads (SELECT/COUNT) and purely UI actions do not consume; consumption only occurs when business logic actually runs.

The monthly Actions limit is a hard limit: once reached, execution of new Actions is suspended until the cycle renews or the plan is upgraded — there is no overage billing. Retries from uncontrolled errors also consume Actions, so the Client must design robust queries and functions.

8. Security and responsibilities

JWT authentication in an HttpOnly cookie (Secure, SameSite=Strict), configurable OAuth/OIDC SSO on Business and Enterprise (enforced on Enterprise), OWNER/ADMIN/MAKER/VIEWER roles, strict Content Security Policy and rate limiting on every endpoint. Client: size the plan to expected Actions, apps and users; manage users, roles, API Keys and MCP Keys under least privilege; safeguard and rotate Data Source credentials; validate MCP Server outputs before publishing them. Provider: operate the SaaS infrastructure; apply the security controls; notify material changes; provide support per the plan.

The breakdown of shared responsibilities between the Client and the provider is described in the responsibility matrix.

9. Limitations

Nexus does not replace ERP, CRM, HRIS or high-volume mission-critical transactional systems; it does not natively offer advanced BI-style reporting or strong separation of DEV/QA/PROD environments within a single tenant. JS Function code and Div component HTML are the Client's responsibility. Outputs generated by the MCP Server depend on the AI client used: Nexus does not guarantee their semantic correctness.

The Spanish-language version of this document is the official version; any existing translations are for reference only.