# Network Resilience

CabFare Connect is designed to operate in vehicle environments where network connectivity may be intermittent. Integration partners must account for connectivity loss, timeouts, and delayed responses in their implementations.

## Acknowledging Inbound Events

When your system receives an inbound event from CabFare Connect, return an immediate `200 OK` or `204 No Content` response before processing the event. This prevents CabFare Connect from timing out and retrying the request unnecessarily.

## Timeouts

Do not block your user interface waiting for a CabFare Connect response where it can be avoided. The API is designed to allow devices to respond to events and driver input asynchronously rather than waiting for responses at every step.

If a request times out:

- Log the request details including timestamp, endpoint, `tripId`, and any relevant identifiers
- Retry the request using the same identifiers to avoid creating duplicate records
- Do not generate a new `tripId` or `transactionId` on retry — CabFare Connect uses these to detect and handle duplicate submissions

## Polling for State Recovery

If your device loses connectivity mid-session and reconnects, use the poll endpoints to verify your current state before resuming normal operation:

- Taxi Meter: `GET /meter/driver/poll`
- Payment Terminal: `GET /terminal/driver/poll`

These endpoints return the current `loginStatus` and `linkStatus` for the session, allowing your device to recover to the correct state without user intervention.

## Duplicate Submissions

CabFare Connect uses `tripId` and `transactionId` as idempotency keys. If the same identifier is submitted more than once, CabFare Connect will handle it as a duplicate and return the original result rather than creating a new record. This means it is safe to retry failed or unacknowledged requests using the same identifiers.

## Unlinked Mode

There are two scenarios that result in Unlinked Mode:

**Taxi Meter logout**
When the driver logs out of the Taxi Meter, CabFare Connect automatically sends a `/driver/logout` notification to the linked Payment Terminal. The Payment Terminal receives this notification and unlinks from the Taxi Meter. This is the normal end-of-shift unlinking process.

**Payment Terminal connectivity loss**
If the Payment Terminal loses connectivity, errors out, or the driver manually logs out of the terminal without logging out of the Taxi Meter, the Taxi Meter must automatically transition to Unlinked Mode. In Unlinked Mode the Taxi Meter assumes the driver will process payments via cash, voucher, or an external manual process. Standard trip processing continues on the Taxi Meter independently.

---
Source: https://docs.cabfare.com/api/network-resilience