> ## 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 Lead Capture 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 Lead Capture 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.
> Integrations API error codes follow the BRIDGE_<DOMAIN>_<NNNN> format, for example BRIDGE_CONVERSATION_0001, and are listed on the error codes page. Lead Capture error codes follow a different format, BRIDGE.CAMPAIGN_LEADS.<NAME>, and are listed on the Lead Capture error reference. Never invent a code that is not listed on the page for its own surface.
> This documentation covers the Integrations API, webhooks and Lead Capture only. It does not describe the Bridge web application or its internal APIs.

# Template requirements

> Why the message that opens the conversation must stay strictly transactional.

## The rule

The template that opens the conversation must be a **utility** template: strictly
transactional, echoing what the visitor just submitted. No offers, no discounts, no
promotional language, and no purchase call to action.

You configure and submit this template yourself, and getting it approved is a prerequisite
for going live.

## Why, and why it is not a style preference

<Warning>
  Meta classifies templates by their content, not by the category you select. A template it
  reclassifies as MARKETING stops being deliverable under the same conditions — it begins
  failing with error `131049`, which does not announce itself. Your sends simply stop
  arriving.
</Warning>

That silence is the whole problem. A rejected template is obvious; a reclassified one is
not. Keeping the first message strictly transactional is what keeps it working, which is
why this reads as protection rather than paperwork.

## The line, shown rather than described

**Compliant** — it acknowledges an action the person just took and offers nothing:

```text theme={null}
Hi {{1}}, thanks for your enquiry about the {{2}}. A member of our team will follow up here shortly.
```

**Not compliant** — same opening, but the second sentence turns it into an advertisement:

```text theme={null}
Hi {{1}}, thanks for your enquiry about the {{2}}. Book this week and get 15% off — reply YES to claim.
```

The difference is not tone or length. It is whether the message exists to confirm something
the person did, or to sell them something they did not ask for.

## Practical guidance

* Echo the specifics the visitor gave you. A message that repeats their enquiry reads as
  transactional because it is.
* Do not include prices, promotions, urgency, or a call to action to buy.
* Do not use the first message to introduce products they did not ask about.
* Once the person replies, you are in a normal conversation and these constraints no longer
  apply. The restriction is on the message that opens it.