Authentication

RideWiseCore uses service-to-service authentication. Your backend proves who it is with an API key. RideWiseCore never authenticates your riders or agents; that stays with you.

Credential types

The split is deliberate. Having the dashboard open in a browser tab should not be enough to dispatch rides. Only your backend, holding a real API key, can use the matching and tracking services.

REST requests

Send your key as a Bearer token in the Authorization header on every request:

POST /matches HTTP/1.1
Authorization: Bearer rwc_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Content-Type: application/json

Real-time socket

Pass the key in the Socket.IO auth payload when you connect. RideWiseCore checks the key during the handshake:

import { io } from "socket.io-client";

const socket = io(process.env.RWC_API_URL!, {
  auth: { apiKey: process.env.RWC_API_KEY },
});

socket.on("connect_error", (err) => {
  // err.message: "Missing API key", "Invalid or revoked API key",
  // or a billing message such as "A payment method must be on file…"
});

The same billing checks as the REST API run at handshake time, so a tenant without a payment method, or a cancelled one, can't connect.

Keeping keys safe

• Keep keys only on your servers, in environment variables or a secrets manager.
• Never embed a key in a mobile app, web frontend or public repository. Anyone who has the key can dispatch rides and generate billable usage as you.
• Use a separate key for each environment or service, labelled so you can tell them apart, for example production-api and staging.
• Rotate keys periodically, and immediately if you suspect one has leaked. See API keys → Rotating a key.

Rate limits

Every API key is limited to 300 requests per minute across the REST API. When you exceed it, you get 429 Too Many Requests. Wait for the time in the retry-after header, then retry.

Location updates sent over the socket don't count toward this limit.