Security

1.Data in transit and at rest

Traffic to the website and API is served over TLS, so data is encrypted in transit between your client and our services. Secrets such as API keys are stored hashed rather than in plaintext, and a key's full value is shown only once, at the moment it is created; after that only a masked prefix is displayed.

Application data is stored in managed database services provided by our hosting sub-processors, which apply their own encryption-at-rest and network controls.

2.Access control

Administrative access to production systems follows the principle of least privilege: people and services receive only the access they need. Administrative access requires two-factor authentication, and administrative actions on keys, billing, and configuration are recorded in an audit log so sensitive changes are attributable and reviewable.

Access is reviewed periodically and revoked when it is no longer required.

3.API keys and agent keys

API keys are scoped and rotatable, so you can issue a key for a specific product or agent and revoke it without affecting the rest of your account. You are responsible for storing keys securely and for the activity of any agent you configure with them; if a key is exposed, rotate it immediately from the console.

4.Spend and abuse controls

Financial exposure is bounded by design: spend cannot exceed a prepaid balance, and per-key rate limits and spend caps limit the impact of a compromised key or a misbehaving agent. A free-tier gate limits anonymous abuse of the gateway, and repeated abusive traffic can be blocked at the network edge.

5.Payment security

Card and UPI payments are handled by Dodo Payments as Merchant of Record. Satelink never receives or stores full card numbers — that data stays within the payment processor's PCI-compliant environment. Satelink sees only payment metadata such as amount, currency, status, and card brand or last-4.

6.On-chain settlement

Revenue settles on-chain to a permissionless Polygon vault, so settlement is publicly verifiable rather than opaque. On-chain data is public and permanent by nature; do not put anything private in a transaction.

7.Sub-processor security

We rely on established hosting and payment sub-processors (see /sub-processors) and depend in part on the security controls they operate. We select processors with credible security practices and impose data-protection obligations on them.

8.Backups and availability

Application data is stored in managed services that provide backups and redundancy operated by our hosting sub-processors. We do not promise a specific uptime figure on this page; where an availability commitment exists it will be stated in a separate agreement.

9.Incident response

If we become aware of a security incident affecting personal data, we will act to contain it and notify the Data Protection Board of India and affected users as required by the DPDP Act and its Rules, and other regulators where applicable. See the Privacy Policy for more on breach notification.

10.Reporting

To report a security issue, see the Responsible Disclosure policy or email satelinknetwork@gmail.com. We investigate credible reports and work with good-faith researchers.

11.What we do not claim

We do not currently hold third-party security certifications and do not represent otherwise. We describe only practices we actually follow; this page will be updated if our posture or certifications change.