API Terms

Effective Date: June 1, 2026
Supplement to the ToS - Version dated June 1, 2026

0. API License Agreement - Overview

These API Terms supplement the ToS and apply to Customer's use of the API, SDKs, and related documentation. Provider does not deliver webhooks to Customer endpoints. Capitalized terms not defined here have the meaning given in the ToS.

• Provider: localoyal GmbH, Mercatorstrasse 62, 49080 Osnabrück, Germany, registered with the Local Court of Osnabrück under HRB 218235
• Contact: hello@revenipe.com
• Support Contact: support@revenipe.com
• Sub-processors: see the DPA and the current sub-processor list made available by Provider
• Technical Parameters: plans, limits, pricing, retention periods and technical specifications are set out on www.revenipe.com, in the ordering process, or in the documentation

1. License and Scope

1.1 Provider grants Customer a non-exclusive, non-transferable, revocable, limited right to use the API, SDKs, and solely to connect Customer's Connected Application and Customer-controlled Third-Party Service accounts to the Service.

1.2 Customer may use the API only for its internal business purposes and for operating its own Connected Application. API reselling, managed-service use for third parties, service-bureau use and sublicensing are prohibited unless expressly agreed in writing.

1.3 Provider may provide SDKs, sample code or documentation. Unless expressly stated otherwise, such materials are provided for integration assistance only and without any separate warranty beyond the Agreement.

2. API Keys, Tokens and Security

2.1 API keys, OAuth credentials, restricted keys, tokens and secrets must be kept confidential and protected using appropriate technical and organizational measures.

2.2 Customer must not embed private secrets in client-side code, mobile apps, public repositories, browser-accessible code, logs, screenshots or support tickets unless expressly instructed by Provider through secure channels.

2.3 Customer shall implement least-privilege permissions, secure secret storage, rotation, access logging and separation between development, staging and production environments.

2.4 Customer is responsible for securely configuring any endpoints, redirect URLs, callback URLs, app links, SDK configuration, connected-app settings and Third-Party Service endpoints that Customer provides to or uses with the Service.

2.5 If compromise is suspected, Customer must immediately rotate the affected credentials, revoke unnecessary access and inform Provider.

2.6 Provider may revoke or rotate credentials, block traffic, require restricted permissions or suspend API access where reasonably necessary for security, legal compliance or misuse prevention.

3. Rate Limits, Fair Use and Monitoring

3.1 Provider may establish, adjust and enforce rate limits, quotas, concurrency limits, payload-size limits and other technical restrictions.

3.2 Customer must not use aggressive polling, scraping, automated account creation, undocumented endpoints or other methods that place excessive load on the Service or Third-Party Services.

3.3 Provider may use logging, monitoring, anomaly detection, abuse detection and traffic analysis to ensure stability, security, billing accuracy and misuse prevention.

3.4 Exceeding limits may result in throttling, delayed processing, rejected requests, temporary suspension, overage charges or required plan changes, as described in the Agreement or documentation.

3.5 Provider may stop, pause, throttle, reject, quarantine or discard requests, events or processing jobs where reasonably necessary to prevent misuse, excessive load, repeated errors, security risks, data integrity risks, Third-Party Service restrictions or operational instability.

4. Retries, Duplicate Events, Idempotency and Event Processing

4.1 Provider does not deliver webhooks to Customer endpoints. References to events in these API Terms concern internal event processing, Third-Party Service events, API requests, SDK operations or other event-based processing within the Service.

4.2 Provider handles retries, duplicate-event handling and idempotency for its internal event processing and supported Third-Party Service integrations on a commercially reasonable basis. Customer is not required to implement webhook retry handling, duplicate-event handling or idempotency for Provider-delivered webhooks, because Provider does not deliver webhooks.

4.3 Customer remains responsible for handling normal API and SDK behavior in its Connected Application, including timeouts, failed requests, rejected requests, invalid responses, insufficient-balance responses, authentication failures, network errors and other application-side error conditions.

4.4 Provider may retry, delay, pause, stop or reject event processing, API requests or SDK operations where processing fails repeatedly, creates security risks, generates excessive load, conflicts with Third-Party Service restrictions or threatens the integrity or availability of the Service.

5. Sandbox, Test Mode and Production Mode

5.1 Customer must keep sandbox, test-mode and production-mode environments, keys, credentials, accounts, configurations and data separate.

5.2 Test-mode or sandbox data may not reflect production behavior, pricing, billing, availability, performance, Third-Party Service behavior or legal effects. Customer is responsible for validating configurations before using them in production.

5.3 Customer must not use production credentials, production End User data or production payment-provider settings in sandbox or test-mode environments unless expressly supported by the relevant Third-Party Service and configured securely.

6. Documentation, SDK Updates, Versioning, Deprecation and Breaking Changes

6.1 The API documentation, SDK documentation and related technical documentation are binding for the technical use of the API and SDKs. Provider may update the documentation from time to time. Customer is responsible for reviewing and following the then-current documentation when using the API and SDKs.

6.2 Provider may maintain multiple API or SDK versions. Customer is responsible for migrating to supported versions within the periods announced by Provider.

6.3 Provider does not guarantee backward compatibility, except to the extent expressly stated in the documentation or a written agreement. Provider will use commercially reasonable efforts to announce material deprecations in good time, for example 90 days in advance. Shorter periods may apply for security, legal, Third-Party Service or urgent operational reasons.

6.4 Provider may introduce breaking changes where required by law, security requirements, Third-Party Service changes, misuse prevention, product changes or discontinuation of a feature.

6.5 Customer is responsible for keeping SDKs and integrations reasonably up to date. Outdated SDKs or unsupported API versions may stop working, be restricted, or no longer receive fixes, updates or support.

7. Stripe and Third-Party API Use

7.1 Customer authorizes Provider to access and use Customer-controlled Third-Party Service APIs only as required to provide the Service and as configured by Customer.

7.2 Customer remains responsible for the scope of permissions granted, connected account settings, Third-Party Service terms, API costs, account restrictions and all legal and commercial consequences of configurations made through the Service.

7.3 Provider does not provide payment services and does not initiate, execute, settle, refund or reverse payments through any API.

8. Prohibited Use

The following are prohibited in particular:

• reverse engineering or circumvention of authentication, authorization, usage or rate limits;
• accessing undocumented endpoints or using undocumented behavior as a product dependency;
• use for developing competing integration, payment-routing, billing-automation or analytics products;
• processing prohibited content, fraud, spam, malware or unlawful transactions;
• interfering with the security, integrity or availability of the Service, Provider systems or Third-Party Services.

9. Suspension and Termination

9.1 Provider may suspend API access for good cause, including security risk, excessive load, misuse, payment default, Third-Party Service restriction, legal risk or violation of the Agreement.

9.2 Upon termination of the Agreement, Customer's API license ends immediately. Customer must cease API use and delete or revoke keys, tokens and secrets unless retention is legally required.