Developer Platform Agreement

2.1 Account requirements

To access the Developer Services, you must have a valid Reinx account with completed KYC/KYB verification, an active subscription on a tier that includes API access (Pro or Enterprise), and acceptance of both the Terms of Service and this Agreement.

2.2 API keys and authentication

Upon accessing the Developer Services, Reinx will issue API keys and/or OAuth credentials for authentication. You agree to:

• Treat all API keys, tokens, and credentials as confidential information
• Store API keys securely using environment variables, secrets managers, or equivalent secure storage; never in source code, version control, client-side code, or public repositories
• Implement proper key rotation practices and rotate keys at minimum every 90 days, or immediately upon suspected compromise
• Use separate API keys for development/sandbox and production environments
• Never share API keys between applications, services, or teams without Reinx’s written consent
• Implement proper authentication on all API requests, including signature verification for webhook payloads

You are solely responsible and liable for all activity conducted using your API keys, whether or not authorised by you.

2.3 Sandbox environment

Reinx provides a sandbox environment for development and testing purposes. The sandbox simulates production API behaviour using test data and does not process real financial transactions. You must use the sandbox environment for all development, testing, and integration work before deploying to production. Sandbox data may be periodically reset without notice.

3.1 Authorised applications

You may use the Developer Services to build applications (“Developer Applications”) that:

• Integrate AI agents with the Reinx platform for financial management purposes
• Enable users to manage agent accounts, spending controls, and financial operations through your application
• Consume Reinx APIs and MCP tools to execute authorised financial operations on behalf of authenticated Reinx users
• Display transaction data, analytics, and Agent Health Scores to authorised users
• Build developer tools, libraries, or integrations that enhance the Reinx ecosystem

3.2 User authorisation

Your Developer Application must obtain proper authorisation from Reinx users before accessing their data or performing operations on their behalf. You must clearly disclose to users what data your application accesses and what operations it performs, obtain explicit user consent before initiating any financial transactions, and provide users with the ability to revoke your application’s access at any time. You may not access or use any Reinx user’s data beyond the scope of the permissions they have granted.

4.1 Rate limits

The Developer Services are subject to rate limits to ensure platform stability and fair usage:

• Pro tier: Rate limits as published in developer documentation (per API key, may vary by endpoint).
• Enterprise tier: Custom rate limits negotiated per agreement.

Current limits are published in our developer documentation and may be updated with reasonable notice.

4.2 Rate limit handling

When your application exceeds rate limits, the API will return HTTP 429 (Too Many Requests) responses with a Retry-After header. Your application must respect rate limit responses and implement exponential backoff. You must not attempt to circumvent rate limits through multiple API keys, distributed requests, or other evasion techniques. Repeated or intentional rate limit violations may result in temporary or permanent suspension of API access.

4.3 Idempotency

For operations that modify state (creating agents, initiating transactions, updating policies), you must include an idempotency key (Idempotency-Key header) with each request. Idempotency keys prevent duplicate operations in the event of network failures or retries. Keys are valid for 24 hours.

5.1 MCP protocol

Reinx provides an MCP (Model Context Protocol) server that enables AI agents to interact with the platform using structured tool calls. The MCP server exposes tools for balance checks, transaction requests, approval status queries, spending intelligence, and other authorised agent operations.

5.2 MCP security model

The MCP server enforces the following security constraints:

• All MCP connections require a valid scoped API token linked to a specific agent account
• Each token is scoped to a single agent and enforces Row-Level Security (RLS) at the database level
• The MCP server does NOT expose any tools for retrieving card credentials (card numbers, CVCs, expiration dates)
• All financial operations requested through MCP are validated against the agent’s spending policies before execution
• MCP tokens are stored in the agent’s MCP configuration file, not in agent LLM context or memory

5.3 Tool call requirements

When making tool calls through the MCP server, your agent must provide structured metadata with every transaction request (amount, recipient, chain for wallet transactions, and purpose/reason). This metadata is required for dashboard analytics, audit trails, and Agent Health Score calculations. Agents that consistently fail to provide required metadata may have their Health Scores reduced or access restricted.

6.1 Webhook delivery

Reinx sends webhook notifications for events including transaction authorisations, approval decisions, agent account changes, and other platform events. Webhooks are delivered via HTTP POST to URLs you configure in your developer settings.

6.2 Webhook requirements

Your webhook endpoints must:

• Use HTTPS with a valid TLS certificate
• Respond with HTTP 2xx status within 5 seconds of receiving a webhook
• Verify webhook signatures using the signing secret provided in your developer settings
• Handle duplicate deliveries idempotently (webhooks may be retried on failure)
• Not expose webhook signing secrets in client-side code or logs

6.3 Retry policy

If your endpoint fails to respond with HTTP 2xx, Reinx will retry delivery using exponential backoff for up to 72 hours. After exhausting retries, the webhook is marked as failed. You can view and replay failed webhooks through the developer dashboard.

7.1 Data processing

When your Developer Application processes Reinx user data, you act as a data processor (or sub-processor) on behalf of the user. You agree to:

• Process user data only for the purposes authorised by the user and described in your application’s privacy policy
• Implement appropriate technical and organisational security measures to protect user data
• Not sell, rent, lease, or otherwise commercialise user data obtained through the Developer Services
• Not use user data to build or improve competing products or services
• Promptly delete user data when a user revokes your application’s access or upon Reinx’s request

7.2 Your privacy policy

If your Developer Application collects, stores, or processes data from Reinx users, you must maintain a publicly accessible privacy policy that clearly describes what data you collect, how you use it, and how users can exercise their privacy rights. Your privacy policy must be consistent with, and no less protective than, Reinx’s Privacy Policy.

7.3 Data security

You must implement and maintain reasonable security measures appropriate for the sensitivity of the data you process, including encryption of data in transit and at rest, access controls and authentication, regular security assessments, and incident response procedures. You must notify Reinx within 24 hours of discovering any data breach affecting Reinx user data.

7.4 Financial data restrictions

Through the Developer Services, you will never have access to raw card credentials (full card numbers, CVCs, or expiration dates), wallet private keys, or user KYC/KYB documents. These are handled exclusively by our infrastructure partners (Stripe and Privy). If you encounter any data that appears to be raw financial credentials, you must not store, log, or transmit it, and must notify Reinx immediately.

8.1 Reinx IP

All intellectual property rights in the Developer Services (including APIs, MCP servers, SDKs, documentation, and developer tools) are and remain the exclusive property of Reinx. This Agreement grants you a limited, non-exclusive, non-transferable, revocable licence to use the Developer Services solely to build, operate, and maintain Developer Applications in accordance with this Agreement.

8.2 Developer IP

You retain all intellectual property rights in your Developer Applications, excluding any Reinx IP incorporated therein. Nothing in this Agreement transfers ownership of your code, designs, or other original work to Reinx.

8.3 Reinx branding

You may use Reinx’s name, logo, and trademarks solely to identify your Developer Application’s integration with the Reinx platform, subject to our Brand Guidelines (available in our developer documentation). You must not imply endorsement, partnership, or affiliation beyond the actual integration. Reinx may revoke branding permission at any time.

9.1 Quality standards

Developer Applications that integrate with the Reinx platform must:

• Be stable, functional, and free of critical bugs that could affect user data or financial operations
• Handle API errors gracefully and provide meaningful error messages to users
• Not degrade the performance or stability of the Reinx platform
• Comply with all applicable laws, regulations, and payment network rules
• Clearly identify themselves to users and not misrepresent their relationship with Reinx

9.2 Security requirements

Developer Applications must:

• Use TLS/HTTPS for all communications with the Reinx API and MCP server
• Never log, store, or display API keys, tokens, or webhook signing secrets in plaintext
• Implement proper input validation and output encoding to prevent injection attacks
• Follow OWASP security best practices for web application security
• Maintain security patches and updates for all dependencies

9.3 Monitoring and compliance

Reinx reserves the right to monitor Developer Application behaviour to ensure compliance with this Agreement. This includes API call patterns, data access patterns, error rates, and rate limit compliance. Reinx may contact you regarding compliance concerns and may suspend API access for non-compliant applications.

10.1 Developer support

• Pro tier: Developer documentation, community forums, and email support (developer@reinx.ai) with response within 2 business days.
• Enterprise tier: All Pro support plus dedicated developer relations contact, priority support with response within 4 business hours, and technical architecture consultation.

10.2 API availability

Reinx targets 99.9% uptime for production API endpoints. Scheduled maintenance windows will be announced at least 48 hours in advance via the developer dashboard and status page. Emergency maintenance may occur without advance notice when required to address security vulnerabilities or critical system issues. Current API status is available at status.reinx.ai.

10.3 API versioning

Reinx uses semantic versioning for its APIs. Breaking changes are introduced only in new major versions. When a new major version is released, the previous version will be supported for a minimum of 12 months. Deprecation notices will be communicated via developer dashboard, email, and API response headers.

13.1 Suspension

Reinx may suspend your access to the Developer Services immediately and without notice if your application causes or threatens to cause harm to the Reinx platform, its users, or third parties; you violate this Agreement, the Terms of Service, or the Authorized Use Policy; your application’s API error rate exceeds 10% over a sustained period; or we are required to do so by law, regulation, or a third-party service provider.

13.2 Termination

Either party may terminate this Agreement with 30 days’ written notice. Reinx may terminate immediately for cause (material breach, prohibited activity, or legal requirement). Upon termination, you must cease all use of the Developer Services, delete all cached API data within 30 days, and remove Reinx branding from your application. Your obligations regarding data handling, confidentiality, and indemnification survive termination.