API Terms of Use

What these terms cover

These API Terms are part of the Terms of Service and apply to any access to Renaro's programmatic interfaces: the public partner API, outbound webhooks, and any tokens or keys issued for them. They bind the operator whose account the access belongs to and every developer or system the operator authorizes. Where a separate written partnership agreement covers API access, that agreement controls on conflict.

Keys and authentication

API access is available on plans that include it and uses keys issued from the operator dashboard, presented on each request. Keys are shown once at creation and stored by Renaro only as cryptographic hashes; if a key is lost, it is replaced, not recovered. Keys belong to the operator's organization, act with the permissions and scopes granted to them, and everything done with a key is attributed to that organization.

• Keep keys out of client-side code, repositories, logs, and support messages; store them like passwords.
• Scope keys to what the integration needs, and use separate keys per integration so one can be revoked without breaking the rest.
• Rotate keys on any suspicion of exposure and tell Renaro promptly at support@renaroapp.com if a key may have leaked.

Versioning and change management

The API contract is date-versioned. A request is served under the contract version it pins, and breaking changes - removed fields, changed shapes, altered semantics - ship only as new dated versions, never silently into an existing one. Additive changes (new optional fields, new endpoints, new event types) can appear in existing versions and consumers must tolerate them: unknown fields must not break an integration.

When a dated version is scheduled for retirement, Renaro publishes the retirement in the API documentation and gives operators with active traffic on that version reasonable advance notice through the platform or by email before it stops being served.

Rate limits and fair use

Requests are rate limited to protect the platform for everyone. Limits are enforced per key and organization and communicated through standard response signals; integrations must back off when told to and must not evade limits by rotating keys, distributing clients, or retry storms. Sustained load patterns that degrade the platform can be throttled independently of published limits, and pagination is cursor-based - iterate it rather than requesting unbounded pages.

Quotes, estimates, and similar priced responses are valid only for the period stated in the response; do not present an expired quote to a customer as a live price.

Webhooks

Operators can subscribe endpoints they control to platform events. Deliveries are signed, carry unique event identifiers, and are retried on failure - which shapes the consumer's obligations:

• Verify the signature on every delivery and reject requests that fail verification; the signing secret is confidential.
• Handle deliveries idempotently by event identifier - retries mean the same event can arrive more than once.
• Register only HTTPS endpoints you control; depending on the events selected, payloads can include passenger contact details and trip coordinates, so an endpoint's security is part of your data protection obligations.
• Respond quickly and process asynchronously; endpoints that persistently fail may have delivery paused until they recover.

Data received through the API

Data an integration reads or receives remains the operator's data, governed by the Terms of Service, the Data Processing Addendum, and the Privacy Policy. API consumers may use it only for the operator's own transportation operation, must protect it with measures appropriate to its sensitivity, must not retain it longer than the integration's purpose requires, and must delete or return it when the integration or the operator's account ends. Building shadow datasets of passenger or driver information beyond operational need, or using API data for advertising, resale, or list-building, is prohibited.

Prohibited integrations

• No reselling, sublicensing, or offering the API as a service to third parties without a written agreement with Renaro.
• No using the API to build or train a competing dispatch product, or to benchmark for competitive publication without consent.
• No misrepresenting an integration's identity, origin, or relationship with Renaro.
• All Acceptable Use Policy rules apply to API traffic - security boundaries, messaging rules, data stewardship, and payments integrity.

Availability, support, and changes

The API is provided with the same care as the rest of the platform, but without a committed service level unless a signed agreement says otherwise. Renaro may add, change, or withdraw API capabilities as the platform evolves, subject to the versioning commitments above. API documentation is part of the platform's documentation surface; keys, subscriptions, and integration health are managed in the dashboard.

Suspension and termination

Renaro may suspend or revoke API access - per key, endpoint, or organization - for violations of these terms, security risk, rate abuse, or where continued access threatens the platform or its users, with notice where practicable. API access ends with the operator's account; the data-handling obligations above survive.