Developer / API / MCP Terms

Last updated: 2026-10-03 Version: 2.1 Status: Advance notice Effective: New products and features: first use on or after 7 October 2026; existing services: 10 November 2026, subject to the notice period below

For newly available products and features, this edition applies when you first choose to use the relevant service and accept its terms, on or after 7 October 2026. The product must actually be launched and available to you. For changes to services you already use, this edition applies from 10 November 2026, but never earlier than 30 days after we notify you of the changes, or a later date required by applicable law. Until then, the previous conditions continue for those existing services. Accepting in advance does not shorten that transition. Publication and acceptance do not make a product available or establish regulatory permission.

These terms govern Swaps' programmatic services, provided by Supa Labs OÜ, registry code 17399414, Oru tn 2, Tallinn 10127, Estonia ("Swaps"). They supplement the Terms of Service and Acceptable Use Policy. Product terms continue to govern products accessed through an API or agent. Mandatory consumer rights apply where the law grants them, even if you use a developer interface.

1. Surfaces and availability

Developer surfaces include the resource API at api.swaps.app/v1, hosted MCP services, the @agent.swaps/mcp-server package, developer documentation, agent-facing quote and discovery endpoints, and supported app integrations. Depending on the surface and credential, operations can read data, create resources or submit authorised payment instructions. The developer platform as a whole is not read-only.

The public ChatGPT app and public marketplace-review variants remain limited to their published tool catalogue. Their report-only scope does not authorise quotes, checkout, payments, transfers or account commerce. Access to another private or authenticated MCP service does not expand a public app's scope.

Use the developer documentation and current API or tool description for available operations, supported authentication and request formats. A planned, preview, disabled or unavailable operation is not a promise to supply it. A successful schema validation does not establish account eligibility or payment execution.

2. Principal, developer and agent

The principal is the person or legal entity on whose behalf a request is made. You must have authority to act for that principal and the selected account. An agent is software you permit to choose or make requests, including an AI assistant, automation or MCP client. It has no independent authority to act for a different holder.

You are responsible for configuring and supervising your integration, selecting suitable permissions and complying with your obligations to its users. That responsibility does not exclude Swaps' own obligations or liability for its own breach. You must not represent that Swaps supplies a regulated service merely because your software can call it, or that your users inherit a provider's authorisation.

3. Credentials and access

Keep API keys, session tokens and webhook signing secrets confidential. Use the supported credential class and least permissions needed. Store secrets on appropriately secured systems, not in public source, URLs, browser code distributed to users, public logs or unrestricted AI prompts. Do not ask users to copy session credentials into an agent to circumvent a missing supported authorisation flow.

Key scopes, account roles, expiry, revocation and any configured allowlist limit access. A credential does not replace provider verification, holder authority or a transaction signature. Some operations require a user session or a locally signed wallet transaction and cannot be completed with a business API key.

Rotate or revoke a compromised credential promptly and notify security@swaps.app. Revocation prevents future authorised use of that credential; it does not necessarily cancel instructions already accepted or transfers already signed. Reconcile those separately.

Public payment and recipient links can contain access tokens. Anyone holding a valid link may be able to view or perform the limited actions it permits. Treat these links as sensitive and disclose them only to the intended audience; they do not confer general account access.

4. Money-moving instructions and human confirmation

Do not turn quote, routing, screening or AI output into a payment or trade without explicit human confirmation of that transaction. Before a person confirms, show the principal, recipient, amount and currency, route, disclosed fees and material risks. A batch can be confirmed as a run only after its items are presented for review. Creating an invoice schedule does not authorise recurring debits.

Where the API requires a confirmation field, sending it is your statement that the required confirmation was obtained. It does not prove that a human saw or approved the action, and the API does not obtain that approval for you. You must keep appropriate evidence of authority and confirmation and prevent an agent from supplying it by default.

Do not bypass a verification refusal, alter a validated destination, suppress a warning, invent a quote or report settlement before the supporting evidence exists. Swaps Wallet signatures remain with the wallet user; an API key does not let Swaps sign for that wallet.

Creating an invoice, payment link or unsigned transaction payload does not itself debit a payer. On the direct Tempo route, the payer authorises funding and a separate release transaction can subsequently distribute it under the fixed contract parameters without another payer signature. The Crypto Processing Terms explain this distinction. Do not describe every stage as payer-signed, or imply that our release automation can choose a different recipient for that payment address.

5. Requests, retries and status

Follow documented idempotency requirements for mutations. Reuse a key only for the same intended request as documented. A timeout is not proof that an operation failed: fetch or reconcile the existing resource before sending a new instruction. Blind retries with new keys can produce duplicate payments.

Treat amounts and currencies according to the published contract, including minor units and decimals. Do not use a formatted display string as a funding instruction. Check quote expiry, destination, chain and asset before execution. Do not change the case of a case-sensitive address.

A created resource, accepted request or provider submission is not a completed transfer. Use the authoritative resource state and supporting receipt or transaction evidence. Handle pending, failed, returned, partial and unknown outcomes truthfully; do not map an unrecognised state to success.

6. Quotes and informational output

Quotes are time-limited indications from available routes; the applicable provider or transaction confirmation determines execution terms. A cached quote is not current merely because your integration fetched it recently. Display limitations and any expiry, fees or uncertainty supplied with the result.

Address Check, screening and AI-generated explanations are informational signals and may be incomplete, delayed or wrong. They are not legal findings, identity verification, investment advice or a certification of safety. The Address Check Terms, AI Disclosure and Risk Disclosure apply. Preserve source attribution and warnings when presenting output to users.

7. Test mode

Use test credentials and supported test operations only for testing. Where test mode is unavailable, a refusal is not permission to substitute a live credential. Do not use real funds, real recipient banking information or unnecessary personal data in fixtures or sandbox requests.

Test behaviour can use simulated data or provider sandboxes and does not prove that the same holder, route or amount will succeed in live mode. Check the returned mode and documented support; never present a test event, balance or receipt as real settlement. A test credential does not guarantee that every tool or external service in your integration is a sandbox.

A Preview or Beta designation describes maturity, not the execution environment. Preserve test/live and network information in your interface and agent output; do not infer that a preview operation is simulated or exempt from eligibility requirements. If its environment is unclear, do not submit a money-moving instruction.

8. Webhooks and events

Where enabled, signed webhooks notify your registered HTTPS endpoint of events. Verify signatures according to the documentation, guard against replay and process duplicate or out-of-order deliveries safely. A notification is not a substitute for reconciliation of the underlying resource, especially before moving money or delivering goods.

Delivery can be retried, delayed or fail. Monitor failures and retrieve missed state through supported resources. Keep endpoint secrets secure and rotate them as documented. Do not register a destination you do not control or use webhooks to disclose another account's information. No delivery or timing SLA applies unless separately agreed in writing.

9. Limits, pricing and service changes

The applicable Limits & Enforcement, account disclosures and response guidance govern usage. Respect rate limits, retry instructions and quota errors; do not distribute requests across keys or accounts to evade them. A plan label or displayed ceiling is not a promise of throughput, uptime or access to a disabled feature.

Charges apply only as disclosed for a purchase, plan or transaction, or in a separate written agreement. These terms introduce no new API subscription price or service-level commitment. Product and provider fees can apply to transactions initiated through an API just as through the dashboard.

We may maintain, change or deprecate services as described in the Terms and documentation. Follow version and deprecation notices and keep supported clients current. Open-source package versions can differ from the hosted service. A package installation is not a guarantee that all upstream endpoints will remain available.

10. Permitted use and downstream duties

You may build legitimate applications, internal tools, analytics and authorised workflows within the available contract. If you display Swaps data, give reasonably visible attribution such as "Data via Swaps" and do not imply an endorsement or partnership. Comply with the licence of any separately licensed code or dataset.

You must not resell access, proxy it as your own paid API or sublicense access without written agreement; systematically copy or redistribute proprietary data contrary to its licence; exploit a vulnerability; evade controls; or use the platform for unlawful, misleading or abusive activity. The AUP and sanctions restrictions apply to software and agents as well as people.

Give end users the disclosures and terms relevant to the product they are using. Do not promise a price, outcome, refund, licence status or guarantee that Swaps or a provider has not supplied. Disclose AI involvement where material and provide a way to review consequential actions and challenge errors.

11. Data protection

Send only the data needed for the operation and ensure you have a lawful basis and authority to provide it. Keep personal data out of URLs and unnecessary prompt context. Implement appropriate access controls and retention in your systems; deleting a resource at Swaps does not delete your copies or a public blockchain record.

The Privacy Policy describes Swaps' processing. The parties' controller or processor roles depend on the actual purpose and instructions. Neither an API key nor these terms automatically places every processing activity under a data-processing agreement. Contact legal@swaps.app where an agreement is needed for a processor relationship; independent provider processing remains governed by its own terms and notices.

Operational logs and events assist audit and reconciliation but are not your indefinite archive. Retain records you are legally required to keep, lawfully and securely. Do not assume every historical event or payload will always be available through the API.

12. Suspension, liability and complaints

We may restrict or revoke access for misuse, security, eligibility or legal reasons under the Terms and Limits & Enforcement. Such action does not itself reverse an accepted instruction. Use the stated review or complaint process if you believe a restriction or result is wrong.

The Terms govern liability, indemnities where applicable, changes and disputes. Nothing in these API Terms imposes an additional liability cap or excludes Swaps' own non-excludable responsibility, including applicable consumer rights. A separate signed agreement controls where it expressly varies these terms for its subject.

Use of the open-source MCP package code follows its repository licence. Use of the Swaps services it connects to also follows these terms; these terms do not withdraw rights already granted under the code licence.

Integration enquiries: hello@swaps.app. Legal and privacy: legal@swaps.app. Security: security@swaps.app.