> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bridge.new/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Bridge exposes three integration surfaces: the REST Integrations API for pushing data into Bridge, webhooks for receiving events from Bridge, and the public Custom Connections endpoint that a tenant's landing page posts to.
> The Integrations API host is https://api-connect-us.bridge.new and every request to it must be authenticated with the x-api-key header. Bridge does not use bearer tokens or OAuth.
> The Custom Connections endpoint is different and the Integrations API rules do not apply to it: it has its own host, it takes no x-api-key and no authentication header of any kind, and it is called from a visitor's browser. It is identified by a workspace id and a capture key together with a reCAPTCHA token. Never tell a reader to authenticate it with an API key, and never tell them to keep its capture key out of frontend code - it is designed to live in the page.
> REST error catalog keys use BRIDGE_<DOMAIN>_<NNNN>, for example BRIDGE_CONVERSATION_0001. Some reviewed legacy handlers return a recognized code plus a symbolic suffix separated by |; preserve the complete received value and use the compatible catalog lookup on /error-codes. Custom Connections uses separate BRIDGE.CAMPAIGN_LEADS.<NAME> identifiers on its own error reference. Never invent an error code or confuse the two integration surfaces.
> This documentation covers the Integrations API, webhooks and Custom Connections only. It does not describe the Bridge web application or its internal APIs.
> Before generating an API request, read the relevant OpenAPI specification or the individual endpoint Markdown page. llms-full.txt collects guides and endpoint descriptions; it does not embed every request and response schema. The REST and Custom Connections contracts are separate.
> Preserve the published host, method, path, operationId, authentication, headers, parameter and field names, types, formats, required and nullable fields, enums, defaults, limits, and response codes. Do not invent identifiers, fields, retry rules, or delivery guarantees. When published sources conflict, identify the conflicting passages and ask Bridge support to confirm the current behavior before relying on it.
> Custom Connections is the current name of the landing-page feature previously documented as Lead Capture. The existing /lead-capture documentation URLs, captureKey field, campaign-leads endpoint, and BRIDGE.CAMPAIGN_LEADS error identifiers are unchanged. This is a naming change, not a change to authentication or the API contract.
> For a complete workflow, start with the task guides: /guides/first-conversation, /guides/send-attachments, /guides/send-template, /guides/agent-outbound, /guides/pagination, /guides/identifiers and /guides/responses. Read the endpoint contract as well as the recipe. Outbound requires an existing Contact, but does not require creating a separate Conversation first.
> forceSend=true permits reuse of an existing active conversation; it does not create a fresh one by ignoring it and it is not idempotency. Recovery of a released recoverable conversation can occur even with false. The LeadScout and Agents outbound routes have different line-selection and controller checks; use /guides/agent-outbound.
> For webhook HMAC, follow /webhooks/verifying-signatures exactly: the Python JSON serialization with sorted keys is signed; X-Bridge-Timestamp is not included in that signature. Do not claim a signed timestamp, raw-body signing, exactly-once delivery or a global event order. Use /webhooks/receive-events for durable acceptance and duplicates.
> A 201 message response, 202 handoff or 202 Custom Connections response is not a provider delivery receipt. Do not invent a polling endpoint from messageId, trackingId or requestId. REST validation parsing must tolerate the compatibility difference explained in /error-codes.
> The documentation is available in English (existing root URLs), Spanish (/es/) and Brazilian Portuguese (/pt-br/). Prefer the reader's language when a localized page exists, but preserve the API's exact field names, enums, routes, authentication and examples. Translations describe the same API; they do not introduce regional API hosts or behaviors.
> For coding-assistant setup, use /connect-your-agent, /es/connect-your-agent or /pt-br/connect-your-agent. The Bridge documentation MCP server reads published documentation and has a separate optional feedback tool. Connecting it does not connect the coding assistant to a customer workspace or authorize live business requests.
> For direct HTTP access without MCP, start at https://docs.bridge.new/llms.txt. It lists every published page in English, Spanish and Brazilian Portuguese. Choose /llms-en.json, /llms-es.json or /llms-pt-br.json for a language-specific index, and /llms-full-en.json, /llms-full-es.json or /llms-full-pt-br.json for collected content. /llms-full.txt contains the combined collection. Fetch the original OpenAPI specification for exact schemas.
> For HTTP page reads, follow the .md URLs from the index or request Accept: text/markdown at the canonical page URL. The MCP virtual filesystem uses .mdx page paths instead; .mdx is not the public HTTP export extension. With Search MCP, set language to en, es or pt-BR explicitly; its default is en.
> For integration capabilities and source-selection rules, read https://docs.bridge.new/skill.md. Documentation access does not authorize business API actions; use the actual user request, workspace, credentials and target identifiers for any live integration.

# Histórico de alterações

> Mudanças da API Bridge que afetam sua integração, das mais recentes para as mais antigas.

## Visão geral

Mudanças que afetam as chamadas que você já faz, das mais recentes para as mais antigas. Alterações aditivas, como um novo endpoint ou campo opcional, não são listadas aqui, exceto quando substituem algo que será removido; elas aparecem na referência da [API REST](https://docs.bridge.new/pt-br/api-reference/health/verificar-integridade.md) quando são disponibilizadas.

> [!NOTE]
>
> As entradas antigas abaixo não registraram datas de vigência. As datas de implantação não foram verificadas, e a ordem das entradas não define uma data de lançamento. A data de remoção dos filtros de lista obsoletos **ainda não foi anunciada**. Continue usando o contrato atual documentado até a publicação de uma mudança efetiva e use os endpoints de consulta disponíveis em novas integrações.

## Melhorias na documentação

Esta revisão esclarece o contrato existente da API e apresenta guias de integração por tarefa. Ela renomeia o recurso de landing pages para **Custom Connections**, explica a reutilização e a recuperação de conversas outbound e melhora as orientações de erros e webhooks. As assinaturas existentes da API e as URLs de documentação `/lead-capture` são preservadas. A data de revisão da documentação não é uma data de implantação ou descontinuação da API.

***

## A criação de uma conversa pode recuperar uma conversa liberada

`POST /conversations` costumava retornar `409 BRIDGE_PROVIDER_CHANNEL_0001` quando nenhuma linha estava livre. Agora, se os Contatos solicitados tiverem uma conversa liberada com recuperação, ela é recuperada e retornada com `201` e seu `id` existente. Portanto, você pode receber um `id` que já armazenou. Se essa conversa tiver outros Contatos ou linhas, a requisição retorna `409 BRIDGE_CONVERSATION_0105`. Veja os detalhes na referência da [API REST](https://docs.bridge.new/pt-br/api-reference/health/verificar-integridade.md).

***

## Encontre um contato ou usuário por um identificador

> [!WARNING]
>
> **Essa mudança removerá parâmetros de query que existem hoje.** Eles ainda funcionam e estão marcados como obsoletos na referência da [API REST](https://docs.bridge.new/pt-br/api-reference/health/verificar-integridade.md). A data em que deixarão de ser aceitos será publicada aqui antes da mudança; os endpoints de consulta que os substituem já estão disponíveis.

### O que muda

**Disponível agora:** `GET /contacts/lookup` e `GET /users/lookup` retornam um contato ou usuário do Bridge — chamado de usuário interno na referência da API — por um identificador.

**Obsoleto, com remoção prevista:** os endpoints de listagem deixarão de filtrar. `GET /contacts` e `GET /users` manterão apenas `limit` e `cursor`.

| Parâmetro obsoleto | Substituição |
| - | - |
| `GET /contacts?search=` — um telefone celular | `GET /contacts/lookup?type=PHONE&value=…` |
| `GET /contacts?search=` — um e-mail | `GET /contacts/lookup?type=EMAIL&value=…` |
| `GET /contacts?search=` — um nome | **Nenhuma** |
| `GET /contacts?ownerEmail=` | **Nenhuma** |
| `GET /users?email=` | `GET /users/lookup?type=EMAIL&value=…` |
| `GET /users?status=` | **Nenhuma** — cada linha já contém `status` |

Depois da remoção, o parâmetro será **rejeitado**, não ignorado. Enviá-lo retornará `400` com `BRIDGE_CORE_0103`, e a resposta identificará o parâmetro. Essa decisão é intencional: uma chamada que ignorasse silenciosamente o filtro retornaria a primeira página de todo o workspace, permitindo que você a interpretasse como um resultado correspondente à busca.

### O que fazer

**Se você pesquisa por celular ou e-mail**, migre para o endpoint de consulta correspondente. Ele retorna o mesmo objeto que a lista fornece em cada linha e retorna `404` quando não há correspondência.

`type` aceita os tipos de identificador já usados pela API em outros contextos: os mesmos valores de `identifierType` de um participante de conversa. Contatos aceitam `ID`, `EMAIL` e `PHONE`; usuários do Bridge aceitam `ID` e `EMAIL`, pois o celular de um usuário interno não é um identificador consultável no Bridge.

`ID` é aceito pelo mesmo motivo: um código que já trabalha com o par `{identifierType, identifier}` não deve precisar tratar um dos valores de forma diferente para montar outra URL. Ele retorna exatamente o mesmo resultado de `GET /contacts/{contactId}`, que continua sendo a URL canônica de um contato. Prefira essa URL quando já tiver o ID.

```bash theme={null}
# Before
curl "https://api-connect-us.bridge.new/bridge/api/v1/workspaces/$WORKSPACE/contacts?search=%2B14084029292" \
  -H "x-api-key: $BRIDGE_API_KEY"

# After
curl "https://api-connect-us.bridge.new/bridge/api/v1/workspaces/$WORKSPACE/contacts/lookup?type=PHONE&value=%2B14084029292" \
  -H "x-api-key: $BRIDGE_API_KEY"
```

Um `PHONE` é interpretado da mesma forma que o celular enviado na criação de um contato: números sem código de país usam o país padrão do workspace, e espaços e separadores são ignorados. Em um `EMAIL`, o domínio é convertido para minúsculas, mas a parte local é comparada exatamente como foi enviada.

> [!NOTE]
>
> Um celular em formato internacional começa com `+`, que precisa ser codificado como `%2B` na query string. A maioria dos clientes HTTP faz isso quando você fornece os parâmetros em um mapa, em vez de montar a URL manualmente.

Um `value` incompatível com seu `type`, como e-mail, celular ou UUID malformado, é rejeitado com `422` e `BRIDGE_CORE_0101` antes de qualquer consulta. Trate esse caso separadamente de `404` se repassar diretamente dados informados por usuários: um significa *você enviou algo que não é um identificador*; o outro, *ninguém neste workspace tem esse identificador*.

**Se você filtra usuários do Bridge por status**, leia `status` em cada linha. Ele é calculado, não armazenado, e já aparece em todas as respostas. Hoje, a lista retorna apenas usuários ativos, a menos que você envie `status`; após a remoção do parâmetro, ela retornará usuários ativos e desabilitados.

O mesmo vale para `GET /users/lookup`: ele retorna o usuário do Bridge ativo ou desabilitado, priorizando o ativo quando um e-mail corresponde aos dois. Hoje, `GET /users?email=` não retorna um usuário desabilitado. Portanto, confira `status` na resposta se sua aplicação deve agir apenas sobre usuários ativos.

**Se você pesquisa contatos por nome**, não haverá substituição; entenda o que deixará de estar disponível. O parâmetro encontra apenas o **nome completo exato**: primeiro nome, um espaço e sobrenome. Ele nunca encontra prefixos, trechos do nome ou apenas o sobrenome. Se funciona no seu caso, você já está fornecendo o nome completo.

**Se você filtra contatos por responsável**, não haverá substituição. Liste a página e filtre por `ownerId` no seu próprio código. `ownerId` é o ID do usuário do Bridge responsável pelo contato, não um e-mail. Obtenha-o uma vez com `GET /users/lookup?type=EMAIL&value=…` e compare com seu `id`.

### Por quê

Filtrar por esses parâmetros faz o custo da chamada depender do tamanho do workspace, não do tamanho da resposta. Buscar um contato por telefone em um workspace grande exige ler dezenas de milhares de registros para retornar um único resultado. Pedir uma página maior torna a operação mais lenta, não mais rápida. Os endpoints de consulta leem apenas os registros que contêm o identificador.

Por isso, os filtros estão sendo removidos, em vez de corrigidos: quando existe uma substituição, ela é estritamente melhor. A pesquisa por nome, que não tem substituição, nunca encontrou nada além do nome completo exato.

***

## Tópicos relacionados

* [Códigos de erro](https://docs.bridge.new/pt-br/error-codes.md) — Referência completa, incluindo `BRIDGE_CORE_0103` e `BRIDGE_CORE_0101`
* [Referência da API REST](https://docs.bridge.new/pt-br/api-reference/health/verificar-integridade.md) — Endpoints de consulta, seus parâmetros e respostas
* [Limites de requisições](https://docs.bridge.new/pt-br/rate-limits.md) — Cota por workspace e como respeitar os intervalos de nova tentativa


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.