Solution · Software and SaaS
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.
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 execution 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.
Public operations in Meteor’s OpenAPI contract, tools on the MCP server and scopes in the API key catalog. The integrations are the spec sheets verified against the connector that implements each one.
The build-or-buy call
None of these is the product you sell. All of them are needed for yours to have AI inside it that is worth anything.
Building it yourself
An engine that decides which tool to call, actually calls it, handles the provider’s failures and returns something usable.
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
One connector for every system your product has to touch, and then maintaining them when the provider changes its API.
What Meteor already ships
27 integrations already built across ERP, stores, marketplaces, carriers, invoicing and payments, most of them Latin American. Each spec sheet says what it really does and what it does not.
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.
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
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.
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
WhatsApp Business verification, the Meta webhook, the message queue, the handover to a person.
What Meteor already ships
WhatsApp, Instagram, Messenger, email and the chat on your site, with queryable conversations and handover to a human when it is needed.
Building it yourself
Per-execution accounting, balance, a spend cap, and some way to keep one customer’s cost from eating another’s.
What Meteor already ships
Every execution 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
Traces, a live event stream and a record that holds up when a customer disputes something a Met did.
What Meteor already ships
A live event stream over SSE, the workspace activity log and the history of every execution.
Building it yourself
Signed delivery, retries, and making sure a dropped notification is not dropped forever.
What Meteor already ships
Outbound notifications signed with HMAC and retried with exponential backoff, over a closed catalog of events.
How you connect
The same surface through four different doors. You pick the one that suits your team, not the one that suits us.
When the one writing the code is your coding assistant, not you.
You add it as a remote server with your key in the header, and it shows up in Claude Code, Claude Desktop, Cursor, Windsurf, Codex and VS Code. It exposes 34 tools, and the catalog is filtered by the key’s scopes: what the key cannot do, the assistant never even sees.
Setup for each clientWhen your backend talks to Meteor directly.
Three hundred public operations with an OpenAPI contract generated from the code itself, prefixed keys, 63 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 referenceWhen 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 npmWhen 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 Python SDK lives on PyPI as meteor-ia. If what you want is the connector catalog and not the architecture, the door is Meteor for developers.
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. That also means each workspace is an account with its own plan, not a tenant you create inside yours.
Every key carries which workspace it belongs to and which scopes it holds. There is no master key that sees all of your customers, which also means a bug in your code cannot cross data between them.
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.
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.
Third-party apps
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.
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.
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.
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.
Every refresh issues a new token and invalidates the previous one. If a stolen token is replayed, the whole session revokes itself.
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
What your Met did for one of your customers can be reconstructed afterwards, which is when it actually matters.
The workspace’s list of AI executions: 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.
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.
An SSE stream of what is happening in the workspace, which you can also leave running in a terminal with the CLI.
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
It is the boring part, and it is the one that decides whether you can resell this with a margin.
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.
See the plansOne-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.
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.
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
We would rather say it here than have you find out during implementation.
Your customers’ workspaces are not created from the API. The scope for it is reserved, but today each customer signs up on the platform and issues their key from there.
A session belongs to one workspace. There is no single dashboard where you watch all twenty of your customers’ workspaces at once: what you can do is operate them through the API, each with its own key.
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.
Calling a connector’s tools one by one from outside is not published yet. What is published is running a Met that already has that connector active and does the work.
A key lives inside one workspace and does not reach another. Operating twenty customers means twenty keys, not one key with twenty permissions.
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.
Questions from the people who will build it
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.
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.
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.
Yes. Meteor’s MCP server is remote and authenticates with your key, so you add it as a server in Claude Code, Claude Desktop, Cursor, Windsurf, Codex and VS Code. The assistant only sees the tools that key’s scopes allow.
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 execution 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.
Every execution 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.
Not to build. An active account with API access is enough, and keys are issued from Settings and Developers. The partner program is a different thing: it is for whoever also implements Meteor for third parties, and it comes with its own API and partner scopes for looking up their attributed customers, their projects and their settlements.
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.