Added the SIP Request tool and moved tools to be a top level node

fern/advanced/sip/sip.mdx

@@ -100,3 +100,7 @@ If your SIP provider or firewall requires IP allowlisting, use the signalling IP
     Now, every time you make a call to this phone number, your server will receive an `assistant-request` event.
   </Step>
 </Steps>
+
+## Send SIP requests during a call
+
+On calls to a Vapi SIP number or through a [BYO SIP trunk](/advanced/sip/sip-trunk), your assistant can send SIP INFO, MESSAGE, or NOTIFY requests to the other end of the call, for example to pass call details to your PBX or contact center platform. See [SIP Request tool](/tools/sip-request).

fern/observability/logs/call-logs.mdx

@@ -97,19 +97,6 @@ This tab shows the stored conversation-message objects for the call, in order. A
 
 Use this tab to inspect the message data retained for the call. The objects are not necessarily the exact payloads sent to or returned by the model provider. The stored history depends on your artifact configuration.
 
-### Function and API Request tools
-
-Use **Messages** to inspect a tool call and its result. Use the call's **Logs** tab to inspect request and response details when the assistant's **Logging** setting is enabled.
-
-| Tool type | Where to inspect | Correlation details |
-| --- | --- | --- |
-| Function | Open **Logs → Webhooks** and find the `tool-calls` entry. Use the call's **Messages** tab to inspect the tool call and result. | The webhook includes the call and tool-call IDs. Vapi also sends the call ID in the `X-Call-Id` header. |
-| API Request | Open the call's **Logs** tab for the resolved request and response. Use **Messages** to inspect the tool call and result. | Vapi sends the call ID in the `X-Call-Id` header. Your destination can return its own `requestId` for its server logs. Vapi does not add `toolCallId` to the destination request by default. |
-
-The **Logs → API** tab records requests made to the Vapi API. It does not show requests that an API Request tool sends to your destination.
-
-For an async Function tool, Vapi returns an immediate `Success.` result to the assistant and ignores the webhook's later result. Open **Logs → Webhooks** to inspect the webhook response after it finishes. Detailed entries in the call's **Logs** tab depend on the assistant's **Logging** setting. See [Logs overview](/observability/logs/overview#retention-and-logging-configuration) for retention and compliance limits.
-
 ### Call Cost
 
 When available, the **Call Cost** tab shows the call's total cost, duration, and per-category breakdown. The tab may be hidden for organizations with invoiced billing. Contact your account team for cost details that reflect your agreement.
@@ -126,6 +113,20 @@ Use the per-turn table to find which stage made the call feel slow. It shows eac
 
 For the full object behind these views, see the [call object](/api-reference/calls/get). Recordings and artifacts are also covered in [Call recording](/assistants/call-recording) and [Retrieve call artifacts](/assistants/retrieve-call-artifacts).
 
+## Inspect tool calls
+
+Use **Messages** to inspect a tool call and its result. Use the call's **Logs** tab to inspect request and response details when the assistant's **Logging** setting is enabled.
+
+| Tool type | Where to inspect | Correlation details |
+| --- | --- | --- |
+| Function | Open **Logs → Webhooks** and find the `tool-calls` entry. Use the call's **Messages** tab to inspect the tool call and result. | The webhook includes the call and tool-call IDs. Vapi also sends the call ID in the `X-Call-Id` header. |
+| API Request | Open the call's **Logs** tab for the resolved request and response. Use **Messages** to inspect the tool call and result. | Vapi sends the call ID in the `X-Call-Id` header. Your destination can return its own `requestId` for its server logs. Vapi does not add `toolCallId` to the destination request by default. |
+| [SIP Request](/tools/sip-request) | Use **Messages** to inspect the tool call and result. Download the call's packet capture with **PCAP** on the call's page to inspect the SIP signaling. See [Verify the request was sent](/tools/sip-request/configure#verify-the-request-was-sent). | Vapi doesn't add its own call ID to the SIP request. Include `{{call.id}}` in the body if your system needs it. |
+
+The **Logs → API** tab records requests made to the Vapi API. It does not show requests that an API Request tool sends to your destination.
+
+For an async Function tool, Vapi returns an immediate `Success.` result to the assistant and ignores the webhook's later result. Open **Logs → Webhooks** to inspect the webhook response after it finishes. Detailed entries in the call's **Logs** tab depend on the assistant's **Logging** setting. See [Logs overview](/observability/logs/overview#retention-and-logging-configuration) for retention and compliance limits.
+
 ## Debug with call logs
 
 Reach for call logs when a call did not go as expected:

fern/tools/api-request/response-handling.mdx

@@ -175,7 +175,7 @@ After a test call, inspect the tool arguments and result before changing the sch
   </Tab>
 </Tabs>
 
-When the assistant's **Logging** setting is enabled, the call's **Logs** tab records the resolved API Request URL, method, request data, and response details. Vapi sends the call ID in the `X-Call-Id` request header. The destination does not receive `toolCallId` by default, so use the call ID and a destination-generated `requestId` to correlate with your server logs. Sensitive values can be redacted or omitted based on logging and compliance settings. The **Logs → API** tab records requests made to Vapi's API, not requests sent by an API Request tool. For Function and API Request tool log locations, see [Call logs](/observability/logs/call-logs#function-and-api-request-tools).
+When the assistant's **Logging** setting is enabled, the call's **Logs** tab records the resolved API Request URL, method, request data, and response details. Vapi sends the call ID in the `X-Call-Id` request header. The destination does not receive `toolCallId` by default, so use the call ID and a destination-generated `requestId` to correlate with your server logs. Sensitive values can be redacted or omitted based on logging and compliance settings. The **Logs → API** tab records requests made to Vapi's API, not requests sent by an API Request tool. For Function and API Request tool log locations, see [Call logs](/observability/logs/call-logs#inspect-tool-calls).
 
 ## Diagnose common failures
 

fern/tools/custom-tools-troubleshooting.mdx

@@ -325,7 +325,7 @@ Tool behavior doesn't match your expectations.
   processing for long-running operations.
 </Tip>
 
-For an async Function tool, Vapi returns an immediate `Success.` result to the assistant and does not use the webhook's eventual response as the tool result. Inspect the later webhook response in [Logs → Webhooks](/observability/logs/webhook-logs) and check your server logs for the completed action. See [Call logs](/observability/logs/call-logs#function-and-api-request-tools) for the Function and API Request log locations.
+For an async Function tool, Vapi returns an immediate `Success.` result to the assistant and does not use the webhook's eventual response as the tool result. Inspect the later webhook response in [Logs → Webhooks](/observability/logs/webhook-logs) and check your server logs for the completed action. See [Call logs](/observability/logs/call-logs#inspect-tool-calls) for the Function and API Request log locations.
 
 ## Reference: Required formats
 

fern/tools/custom-tools.mdx

@@ -312,7 +312,7 @@ If the location can't be found, report the failure through `error` instead of `r
 
 For multiple tool calls in one request, return a result for every call in the `results` array and match each result to its call with `toolCallId`. Results can appear in any order. Use `result` for success and `error` for failure.
 
-To inspect a Function tool call, open its [call log](/observability/logs/call-logs#function-and-api-request-tools). The call's **Messages** tab shows the tool call and result. **Logs → Webhooks** shows the Function webhook request and response.
+To inspect a Function tool call, open its [call log](/observability/logs/call-logs#inspect-tool-calls). The call's **Messages** tab shows the tool call and result. **Logs → Webhooks** shows the Function webhook request and response.
 
 **Some Key Points:**
 

fern/tools/introduction.mdx

@@ -28,8 +28,10 @@ Because the model controls both *when* a tool runs and the arguments it receives
 | [API Request tool](/tools/api-request) | Calls an ordinary HTTPS endpoint directly, with a configurable URL, method, headers, and JSON body |
 | [Function tools](/tools/custom-tools) | Sends Vapi's `tool-calls` webhook to a server you control, so your code decides what happens |
 | [Transfer Call tool](/tools/transfer-call) | Routes a live call to a phone number or SIP URI |
+| [Hang Up tool](/tools/hang-up) | Ends the call when the assistant decides the conversation is complete, with an optional goodbye message |
 | [Handoff tool](/squads/handoff) | Moves a call from one assistant to another, carrying context and extracted variables |
 | [Voicemail tool](/tools/voicemail-tool) | Lets the assistant decide what to do when it reaches a voicemail system |
+| [SIP Request tool](/tools/sip-request) | Sends a SIP INFO, MESSAGE, or NOTIFY request on a live SIP call, for example to pass call details to your PBX or contact center platform |
 | [Client-side tools](/tools/client-side-websdk) | Runs in the browser through the Web SDK, with no server URL |
 | [Query tool](/knowledge-base/using-query-tool) | Searches a [knowledge base](/knowledge-base) and returns matching content |
 | [MCP tools](/tools/mcp) | Connects to an MCP server so the assistant can use tools resolved at runtime |

fern/tools/sip-request.mdx

@@ -0,0 +1,78 @@
+---
+title: SIP Request tool
+subtitle: Send SIP INFO, MESSAGE, or NOTIFY requests on a live call
+slug: tools/sip-request
+description: Use the SIP Request tool to let a Vapi assistant send SIP INFO, MESSAGE, or NOTIFY requests mid-call to your PBX, SBC, or contact center platform on SIP calls.
+---
+
+The SIP Request tool lets your assistant send a Session Initiation Protocol (SIP) INFO, MESSAGE, or NOTIFY request to the system on the other end of the call. It doesn't transfer the call, end it, or change who's on it.
+
+Use it to tell your telephony system something during the call, at the moment your assistant learns it.
+
+<Note>
+The SIP Request tool only works on calls that run over Vapi's SIP transport, such as calls to a Vapi SIP URI or calls through a [BYO SIP trunk](/advanced/sip/sip-trunk). See [Requirements](#requirements).
+</Note>
+
+## When to use the SIP Request tool
+
+Use the SIP Request tool when a system that's already in the SIP call path needs information from the conversation, and that system listens for SIP requests. Common examples:
+
+- **Pass caller details to your contact center.** Your assistant collects an account number, the reason for the call, or a verification result. It sends them to your private branch exchange (PBX) or contact center platform, which records them against the call in real time, uses them to route a transfer, or shows them to the human agent who picks up.
+- **Signal call milestones.** Your assistant tells your system when something happens, such as "caller verified," "consent captured," or "escalation requested," so the system can react while the call is still live.
+- **Send a short text payload to a SIP endpoint.** Your assistant sends a MESSAGE request that the receiving device or application can display or log.
+
+### Why use SIP instead of an HTTP request
+
+You could send the same information to a webhook with an [API request](/tools/api-request) or [Function](/tools/custom-tools) tool. The SIP Request tool is a better fit when:
+
+- **The receiving system speaks SIP, not HTTP.** Many PBXs, session border controllers (SBCs), and contact center platforms act on in-call SIP requests but don't expose an HTTP API for live calls.
+- **The data needs to stay tied to the call.** The request travels inside the same SIP dialog as the call, so the receiving system knows which call it belongs to. You don't need to match call IDs across systems.
+- **You don't want to host an endpoint.** No server URL or webhook is involved.
+
+For other tool types, see the [tools overview](/tools).
+
+## Requirements
+
+The call must run over Vapi's SIP transport (`vapi.sip`). That includes calls to a [Vapi SIP URI](/advanced/sip) and calls through a [BYO SIP trunk](/advanced/sip/sip-trunk).
+
+On other calls, such as web calls or calls on phone numbers imported with Twilio, Vonage, or Telnyx API credentials, the tool doesn't send anything. It returns an error to the assistant instead.
+
+The system on the other end must also accept the SIP method you choose. Check which methods, headers, and body formats your PBX, SBC, or platform expects before you configure the tool.
+
+## Choose a SIP method
+
+| Method | Typical use |
+| --- | --- |
+| `INFO` | Pass application data during a call. This is the most common choice for sending call details to a PBX or contact center. |
+| `MESSAGE` | Send a short text message to the endpoint. |
+| `NOTIFY` | Report that an event happened. |
+
+Use the method your receiving system expects. If you're not sure, start with `INFO`.
+
+<Warning>
+The assistant can choose a different method than the one you configured. If your system only accepts one method, a request sent with another one can be rejected or ignored, so your system never gets the data. Name the method in the tool description and in your system prompt, such as "Always send this as a SIP INFO request."
+</Warning>
+
+## How the tool works during a call
+
+When your assistant calls the tool, it chooses the values to send:
+
+- **Method.** The assistant can choose the method. If it doesn't, Vapi uses the `verb` you configured. See [Choose a SIP method](#choose-a-sip-method).
+- **Headers.** The assistant fills in the headers you described in `headers`.
+- **Body.** With a schema body, the assistant fills in the fields and Vapi sends them as JSON. With a fixed string body, Vapi uses your string as the default value, and the assistant can still replace it.
+
+The content type of the request is set like this:
+
+1. If you include a `Content-Type` header, Vapi uses it.
+2. If the body is JSON, Vapi sets `Content-Type: application/json`.
+3. Otherwise, Vapi sends the body as `text/plain`.
+
+Match the format your receiving system expects. If your system expects JSON sent as `text/plain` and responds with `415 Unsupported Media Type`, use a **Raw string** body containing the JSON and don't add a `Content-Type` header.
+
+The assistant gets back a short result: success, or an error. The SIP response from the other end, such as `200 OK`, isn't passed back to the assistant.
+
+## Next steps
+
+<Card title="Configure the SIP Request tool" icon="sliders" href="/tools/sip-request/configure">
+  Create the tool, tell the assistant when to use it, send requests from hooks, set tool messages and variables, and verify the request was sent.
+</Card>