Solution · Software and SaaS
Your product needs AI inside it. It does not need you to build the platform.
Meteor is the agentic layer of your software: it runs the work, keeps the context, meters what it consumes and leaves the trace. Your interface and your customer relationship stay yours.
Can I put AI agents inside my own SaaS?
Yes, without building the agentic layer from scratch. Meteor exposes its platform as a REST API with an OpenAPI contract, TypeScript and Python SDKs, a CLI and a remote MCP server. Your product runs a Met, hands it the context and receives the result; the Met uses the tools it already has connected and records every run with its cost. Each of your customers operates in an isolated workspace with its own key, and that key carries an Energy budget. Your interface, your brand and your billing do not change: what changes is that the hard part stops being yours.
- Operations
- 402
- MCP tools
- 166
- Scopes in the contract
- 68
- Integrations
- 302
Public operations in Meteor’s OpenAPI contract and the distinct scopes they require, plus the tools on the MCP server, counted from its descriptor every time the site is published. The integrations are the ones you can connect, each verified against the connector that implements it, and it is the same figure the rest of the site publishes.
How you connect
Build with the AI tools your team already uses
The same surface through four different doors. You pick the one that suits your team, not the one that suits us.
MCP server
When the one writing the code is your coding assistant, not you.
You add it as a remote server in Claude Code, Claude Desktop, Cursor, Windsurf and Cline; in Codex, through a stdio bridge. You connect by signing in to Meteor from the client (OAuth with dynamic registration, no key) where the client supports it, or with your key in the header. It brings 166 tools to operate and also to build: it creates and tunes Mets, assembles and publishes flows, schedules automations and creates collections. Three generic tools reach the rest of the API, except what should not pass through an assistant (secrets, file uploads, bulk deletes and partner operations). The catalog is filtered by the key’s scopes or the permissions you approved: what it cannot do, the assistant never even sees.
Setup for each clientREST API
When your backend talks to Meteor directly.
402 public operations with an OpenAPI contract generated from the code itself, prefixed keys, granular scopes, idempotency and documented errors. It is the same surface the MCP server runs on underneath, so there are never two versions of the truth.
API referenceSDK
When you would rather have types than documentation.
TypeScript and Python, both generated from the same contract and both published. They ship with outbound-signature verification, so you do not have to implement it by hand.
@meteor.ia/sdk on npmCLI
When what you need is to try something right now.
The met binary runs a Met, moves the CRM, fires a flow and stays listening to the workspace event stream live. It works just as well inside your CI pipeline.
@meteor.ia/cli on npmThe build-or-buy call
What is already built so your product can have AI inside it
None of these is the product you sell. All of them are needed for yours to have AI inside it that is worth anything.
Eight layers you do not have to write
-
Running the work
What Meteor already ships: You run a Met with one call and retrieve its status and its output by the Run identifier. The full history stays queryable.
Building it yourself: An engine that decides which tool to call, actually calls it, handles the provider’s failures and returns something usable.
-
The tools
What Meteor already ships: 302 integrations already built across channels, ERP, stores, marketplaces, carriers, invoicing and payments, with the Latin American ones (Siigo, Alegra, Mercado Libre, Wompi and more) and the global ones. You use them by running a Met that has them active, or by calling a connector’s tools one by one from your own code, with no Met in between. Each spec sheet says what it really does and what it does not.
Building it yourself: One connector for every system your product has to touch, and then maintaining them when the provider changes its API.
-
Who gets to see what
What Meteor already ships: Every workspace defines its own roles, with permissions per module and scope over specific Mets, channels and collections. Templates come included so nobody starts from a blank slate.
Building it yourself: Roles and permissions, because the account owner and the clerk who keys in orders cannot see the same thing, and that difference is what makes a product usable inside a team.
-
Memory and data
What Meteor already ships: Collections and items with their own API, workspace variables and files. It is the Met’s database, and you operate it from outside exactly as the Met does from inside.
Building it yourself: A schema where what you learned about a customer is stored, can be read back later and does not get reinvented in the next conversation.
-
The channels
What Meteor already ships: WhatsApp, Instagram, Messenger and the chat on your site, with queryable conversations and handover to a human when it is needed.
Building it yourself: WhatsApp Business verification, the Meta webhook, the message queue, the handover to a person.
-
Metering and billing the AI
What Meteor already ships: Every run is listed with its cost, consumption is grouped by contact, by conversation and by Met, and balance movements are queryable one by one.
Building it yourself: Per-run accounting, balance, a spend cap, and some way to keep one customer’s cost from eating another’s.
-
Knowing what happened
What Meteor already ships: A live event stream over SSE, the workspace activity log and the history of every run.
Building it yourself: Traces, a live event stream and a record that holds up when a customer disputes something a Met did.
-
Telling your system
What Meteor already ships: Outbound notifications signed with HMAC and retried with exponential backoff, over a closed catalog of events.
Building it yourself: Signed delivery, retries, and making sure a dropped notification is not dropped forever.
Multi-customer
One workspace per customer of yours, each with its own spend brake
The separation is not a convention you have to hold up carefully on every query: it is the boundary of the product. Every workspace has its own data, its own Mets, its own team, its own contacts and its own Energy balance, and a key is born inside exactly one of them. Each workspace is an account with its own plan, not a tenant inside yours; if you are an approved Tech Partner, you can create those accounts yourself from the API.
The key cannot wander
Every key carries which workspace it belongs to and which scopes it holds, and it does not leave it: a bug in your code cannot cross data between your customers. The only key that operates several accounts is an approved Tech Partner’s partner key, and it only reaches the accounts attributed to that partner, checked on every call.
A budget per key
You set an Energy cap on each key and decide whether hitting it stops everything dead. And you hear about it first: an outbound event fires when spend crosses half, eighty and one hundred percent of that budget. Inside each workspace you can also switch on a spend cap per conversation: past it, the Met stops replying in that chat and flags it for a person.
Test mode that means it
Test keys are not a label: they block the scopes that have effects outside, so you build without a message escaping to a real customer or an integration firing against their system.
If you are an approved Tech Partner, you create the accounts
Your product signs up each customer’s account through the API (POST /workspaces), moves it to a commercial plan charged to your card, tops up its Energy and, when the customer wants to pay for it themselves, hands it over. Creating and handing over accounts takes the workspaces:provision scope, which test keys do not have. Your partner key only operates the accounts attributed to you, and that attribution is checked on every call.
How to become a Tech PartnerThird-party apps
Your customers connect their Meteor to your product without handing you a key
If what you build installs on someone else’s account, asking for a key over chat is the worst way to do it. There is a better one, and it is standard.
-
You register your app
From Settings and Developers. You get a client identifier, and a secret if your app can keep one. You declare up front the maximum scopes your app will ever be able to request.
-
Your user approves what they see
You redirect them to Meteor’s consent screen, where your app and the exact permissions you are asking for are shown. They approve a subset of what you declared, never more.
-
You exchange the code for a token
Authorization code with PKCE required, so the flow is also safe for native and single-page apps that cannot keep a secret. The access token lasts one hour.
-
You refresh with rotation
Every refresh issues a new token and invalidates the previous one. If a stolen token is replayed, the whole session revokes itself.
-
The user stays in charge
Whoever authorized you sees your app in their account and revokes your access whenever they want, cascading across every token. And you find out: there are outbound events when an account authorizes your app and when it revokes it.
OAuth tokens operate the same public API, with the same scopes, the same quota and the same Energy as a key. There is no separate surface to learn.
Traceability
One run, one debit, one trace
What your Met did for one of your customers can be reconstructed afterwards, which is when it actually matters.
-
Every run, itemized
The workspace’s list of AI runs: which Met ran it, what type it was, at which intelligence level and how much Energy it cost. It is not a month-end total, it is the line item.
-
Consumption, grouped
The same consumption seen by contact, by conversation and by Met. That is how you know what it costs you to serve one of your customers before you price it.
-
Events, live
An SSE stream of what is happening in the workspace, which you can also leave running in a terminal with the CLI.
-
Notifications, signed
You subscribe to a closed catalog of events and receive them signed with HMAC, with retries. The SDK ships the signature verification.
Every request carries its own identifier, which travels back in the response and is stored, so when something breaks nobody has to reconstruct it from an approximate timestamp. Two of the events matter more to a product team than the rest: when a Run finishes and when it fails. With those two your system stops asking and starts being told. The portal guides have the detail on each one.
The cost model
Three components that move differently
It is the boring part, and it is the one that decides whether you can resell this with a margin.
License
Monthly and predictable
The plan you sign up for, with its allowance of team members and contacts. It is the component you can budget twelve months out without surprises, and it steps up when you grow rather than creeping up every month. Every plan also carries a daily limit on API requests, which your code checks, along with what you have used, at GET /billing/limits.
See the plansImplementation
One-time, and optional
For when you would rather have our team map your processes, design the Mets, wire them to your systems and hand them over working. If your team builds it, this component does not exist: the platform is the same and the only difference is who writes the configuration.
See what implementation includesEnergy
Variable, on real usage
What your Mets consume as they work. A Met that classifies a message spends little; one that carries a sales conversation spends more, and the intelligence level you assigned to the task is part of the math. Every plan includes an Energy allowance in every period you pay for, the platform tells you how many days your balance lasts at the current rate, and top-ups can run automatically.
Why this separation matters if you are going to resell
Because it lets you work out the margin before you commit to a price. The license is your fixed cost. Energy is your variable cost, and you can attribute it per customer by looking at consumption grouped by contact and by conversation. With those two numbers you know what each account costs you to serve and what you have to charge for it. Without that separation, AI is a bill that shows up at the end of the month and nobody knows how to split.
Run the numbers with real pricesThe limits
What Meteor does NOT do inside your product
We would rather say it here than have you find out during implementation.
- Creating your customers’ accounts from the API is for approved Tech Partners. With a regular account, each customer signs up on the platform and issues their key from there.
- Each workspace has its own subscription, its own data and its own keys. If you run several yourself, they sit under the same account: one sign-in, one card, and you switch between them from the profile menu.
- Meteor does not bill your end users. You charge for your product with your own gateway; Meteor charges you for the license and the Energy your Mets consumed.
- Test keys do not run a connector’s tools or send messages: to call a tool from your code you need a live key with the integrations:execute scope.
- A workspace key does not leave its workspace: operating twenty customers with regular keys means twenty keys. An approved Tech Partner’s partner key does operate several accounts, but only the ones attributed to that partner, and the attribution is checked on every call.
- The models running underneath are not exposed. You pick the intelligence level for each task between Ágil, Brillante and Genio, and that level is what determines how much Energy it costs.
- No response ever returns an integration credential, not even masked. What is observable is the state of the connection, never the secret.
Plans From US$99 a month. Every new account starts with a 7-day trial and US$5 of Energy, no card required.
Questions from the people who will build it
What a product team asks
Can I put Mets inside my own product?
Yes. Your product calls Meteor’s API, runs a Met and receives the result; your interface stays yours. What you are buying is the layer that runs the work, keeps the context, meters the consumption and leaves the trace, not a screen you have to embed.
How does it work if my SaaS has many customers?
Each of your customers operates their own workspace, with their data, their Mets, their team and their contacts separated from everyone else’s. Each workspace issues its own key, and each key can carry an Energy budget with a hard stop, so one customer’s consumption never bleeds into another’s. If you are an approved Tech Partner, you also create those accounts from your product through the API and operate them with your partner key, which only reaches the accounts attributed to you.
Can my customers connect their Meteor to my product without handing me a key?
Yes. You register an app and use OAuth 2.0 with authorization code and mandatory PKCE: the user sees a consent screen with the exact permissions you are requesting, approves a subset of what your app declared, and can revoke your access whenever they want. They never hand you a key.
Can I build with Claude Code, Cursor or Codex?
Yes. Meteor’s MCP server is remote: you add it in Claude Code, Claude Desktop, Cursor, Windsurf and Cline, and in Codex it goes through a stdio bridge. You connect by signing in to Meteor from the client, if it supports it, or with your key. Beyond operating, it builds: it creates and tunes Mets, assembles and publishes flows, schedules automations and creates collections. The assistant only sees the tools allowed by the key’s scopes or the permissions you approved; the portal has the exact setup for each client.
How does the cost behave as I grow?
Three components that move differently. The license is monthly and depends on the plan. Implementation, if you do it with us, is a one-time payment. Energy is variable and tracks real usage: every run is listed with its cost and consumption is grouped by contact, by conversation and by Met. That separation is what lets you work out your own margin before you set your price.
What happens if a Met does something a customer disputes?
Every run is recorded with its input, its output and its cost, and the workspace has a live event stream and a queryable activity log. You can also subscribe to signed outbound notifications so your own system finds out when a Run finishes or fails.
Do I need to be a partner to build on Meteor?
Not to build on your own account. An active account with API access is enough, and keys are issued from Settings and Developers. The Tech Partner program is for a product that operates other people’s accounts: once approved, it creates its customers’ accounts from the API, pays for them with its own card and hands them over, and its partner key only operates the attributed accounts. The implementation partner program comes with its own API for looking up attributed customers, projects and settlements.
Tell us what you are building
We look together at which part of your product is worth solving with Mets and which part is not, which is usually the more useful of the two conversations.