V1 Synchronous APIs

August 2025

Bridge’s core eligibility flow revolves around creating Policy, ServiceEligibility and Service resources. In the first time user experience, these are expected to be sequential, and in short-order. The original Create Policy relies on a blocking call through to the insurance carrier to confirm the plan.

In the happy path, subsequent Create ServiceEligibility and Create Service calls do not result in a call to the Payer. However, there are scenarios where that is the case.

The object structure was always intended to handle an asynchronous workflow (all resources have a PENDING status). However, client implementations have come to rely on the synchronous nature of this call (where a non-PENDING state is guaranteed), and a change here would be considered breaking.

There are some fundamental issues with the synchronous calls. Primarily, timeouts at the HTTP request level can interfere with the correctness of the outcome. Bridge has a complex retry system, routing requests to alternative payers in certain error scenarios or when responses are slow. It’s possible that the requests fail at the network-level before resolution is complete, potentially missing a confirmation.

Additionally, the nature of relying on an all-or-nothing long-lived request is risky when many end users are on cellular networks.

Changes

A new set of asynchronous API’s for these resources have been live since late 2024. Bridge has recommended this flow to all new partners since its launch, and as of August 2025 will be working with existing clients to migrate.

• POST /api/policies → POST /api/policies/v2
• POST /api/service-eligibility → POST /api/service-eligibility/v2
• POST /api/services → POST /api/services/v2

Implementation

There are a few mechanisms to resolve these resources asynchronously. For maximum speed and resilience, we suggest relying on Streaming and Polling in parallel.

Policy and ServiceEligibility

Polling (Simplest)

The most basic implementation is to poll for resources after creation. Repeatedly call the Get Policy or Get ServiceEligibility endpoints, with a slight delay, and wait for the status to change.

When the status value moves out of PENDING, consider that the result of the request.

Streaming (Recommended)

After creating a Policy or ServiceEligibility, expect the status to be PENDING. Call the Stream Policy or Stream ServiceEligibility endpoints to monitor an SSE response. These endpoints will flush real time updates of the resources as it changes.

Immediately after connection, the latest state of the resource is returned. On network failure, retry the request. This is the fastest way to receive updates.

When the status value moves out of PENDING, consider that the result of the request.

Webhooks

Recommended alongside polling if the flow is being managed on the backend. Listen for the policy.updated and service_eligibility.updated Events coming through to your webhooks from Bridge. This is emitted real time, and should be pushed within tens-of milliseconds, but may not be as fast as the streaming endpoint.

Service

Common implementation patterns expect that a Service is created only after eligibility has been confirmed. Therefore, we recommend that the user journey is not influenced by the status values returned in the Service.

Standard implementation requires monitoring of a Service’s coverageStatus for insurance validation purposes, already, using webhooks and Events. If that’s done, failure scenarios coming out of Service creation should be handled automatically.