> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.usebridge.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.usebridge.com/_mcp/server.

# V1 Synchronous APIs

*August 2025*

> **Note**
>
> The original endpoints are sensitive to Payer response times and errors. Using asynchronous calls
> remove network-layer problems.

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` endpoint relies on a blocking call through to the insurance carrier to confirm the plan.

In the happy path, subsequent `Create ServiceEligibility` and [Create Service](/api/api-reference/services/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`](/api/api-reference/policies/v-2/create-policy)
* `POST /api/service-eligibility` → [`POST /api/service-eligibility/v2`](/api/api-reference/service-eligibility/v-2/create-service-eligibility)
* [`POST /api/services`](/api/api-reference/services/create-service) → [`POST /api/services/v2`](/api/api-reference/services/v-2/create-service)
* [`POST /api/services/{id}` (synchronous)](/api/deprecated/endpoints/update-service-v-1) → [`POST /api/services/v2/{id}`](/api/api-reference/services/v-2/update-service)

## 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.*

> **Info**
>
> The P95 for eligibility validation, of a patient with valid insurance is 8 seconds. We recommend
> having your UI "time out" in the eyes of the patient, and assume failure will happen, after 30
> seconds.

### Policy and ServiceEligibility

#### Polling (Simplest)

The most basic implementation is to poll for resources after creation.
Repeatedly call the [Get Policy](/api/api-reference/policies/get-policy) or [Get ServiceEligibility](/api/api-reference/service-eligibility/get-service-eligibility) 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](/api/api-reference/policies/stream-policy) or [Stream ServiceEligibility](/api/api-reference/service-eligibility/stream-service-eligibility) 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](/api/resources/webhooks).
If that's done, failure scenarios coming out of Service creation should be handled automatically.

The same applies after a Service update when using the asynchronous update endpoint: poll [Get Service](/api/api-reference/services/get-service), use [Stream Service](/api/api-reference/services/stream-service), or rely on `service.updated` webhooks until `coverageStatus` and eligibility reflect the refresh.