Developer Platform Agreement

2.1 Account requirements

To access the Developer Services, you must have a valid Reinx account and accept both the Terms of Service and this Agreement. REST and MCP access are included on current plans, subject to plan-specific rate limits. Financial operations remain unavailable until any required KYC/KYB verification is complete.

2.2 API keys and authentication

Reinx may issue organization API keys, scoped agent keys, or other documented 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 distinct credentials for separate applications or 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 Testing and environments

Reinx does not currently provide a generally available public sandbox. Unless Reinx expressly gives you a separate test environment, you must treat the configured environment as capable of processing real financial activity. Follow the documentation, use minimum necessary permissions, and do not use real user data or funds for testing without authorization.

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 and analytics 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:

• Free, Pro, and Enterprise plans each include REST and MCP access
• Default request rates vary by plan and request surface
• Enterprise limits may be adjusted by written agreement or plan override

Applicable limits are enforced by the product and may be shown in plan information, API responses, or response headers. They 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

When an endpoint schema documents an idempotencyKey body field, provide a stable value and reuse it only when retrying the same logical operation. Use a new value for a different operation. Idempotency is route-specific; Reinx does not currently define a universal Idempotency-Key header or retention period for every state-changing route.

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 through authentication middleware, explicit organization and agent filters, and narrow service-role grants
• 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
• Developers must keep MCP tokens in a secret-backed client configuration and out of prompts, model context, logs, and agent 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, policy evaluation, and payment review. Agent Health Score is a planned capability and is not currently calculated or used to restrict access.

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 15 seconds of receiving a webhook
• Verify webhook signatures using the signing secret provided in your developer settings
• Handle duplicate deliveries idempotently — delivery is at-least-once, so a webhook may be re-sent (for example after a retry); deduplicate using the Reinx-Delivery-Id header, which is stable across retries of the same event
• 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 across up to five attempts spanning approximately ten hours. After exhausting retries, the webhook is marked as failed. You can view the delivery history for each endpoint — including failed deliveries — through the developer dashboard. The dashboard does not re-send a failed webhook; to recover a missed event, query the relevant Reinx API or poll the status of the underlying resource.

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 signing keys, or user KYC/KYB documents. Virtual card services are not currently active; if activated, raw card data will be handled through the issuing provider's secure elements. Wallet signing keys are held by Reinx in AWS KMS-backed infrastructure and never exposed through any API, while KYC/KYB documents are handled by Dakota. If you encounter 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, 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

Available support channels and response targets are those shown for your plan or written order form. Pro currently includes priority support. Enterprise may include a dedicated account manager, support SLA, or architecture assistance when specified in the applicable agreement.

10.2 API availability

Unless a written order form provides a service-level commitment, Developer Services are provided without a guaranteed uptime percentage. Reinx may perform scheduled or emergency maintenance and will provide notice when reasonably practicable.

10.3 API versioning

Reinx uses versioned API routes. Material breaking changes will be introduced in a new version or communicated before they take effect when reasonably practicable. Any contractual support or deprecation period must be stated in a written order form.

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 Acceptable 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.