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