Privacy and data in the API

What is specific to the developer surface. The governing policy is the one on the company site, linked below.

Which policy governs

The document that governs data processing is the Meteor privacy policy, published on the company site. This page neither replaces nor summarises it: it explains how those commitments map onto the API surface, which is the part that is not covered there.

What data goes through the API

The API operates on the data of the workspace the credential authorises: CRM contacts and conversations, collections and items the customer loaded themselves, tasks, agent runs and their associated files. Meteor processes them on the customer's behalf, in order to provide the service. The party deciding what data goes in and what for is the integrating customer, not Meteor.

Every call is recorded with operational metadata — timestamp, operation, outcome, request_id — which is what makes a problem diagnosable and usage billable.

How access is limited

Access is not all-or-nothing. An API key carries scopes: named permissions that enable a bounded set of operations. A key without contacts:read cannot read contacts, full stop. The full catalogue is public and machine-readable:

The usual advice, and here you can actually follow it: issue one key per integration, with the scopes that integration uses and no others. And use met_test_… while you build — test mode blocks external side effects, so you will not message anyone by accident.

How access is cut off

An API key is revoked from the workspace panel and stops working immediately: no grace period, no token that outlives it. If you suspect a key leaked, revoke first and investigate afterwards.

Exercising data rights

Access, correction and deletion requests are handled through the channels in the policy, and deletion additionally has its own form at meteor.com.co/eliminar-datos. If you embed Meteor inside your own product, those requests reach you first: to your users, you are the controller.