Connect Tuolen to your existing workflow

0:00Connect the next step

Useful support shouldn't stop at the edge of your inbox. Let's look at how Tuolen's API and webhooks can fit into your existing workflow. We'll use the official developer guides and an example design, without creating keys or connecting a live system.

0:17API requests versus webhook events

Think of the API as your server asking Tuolen for information or an action. A webhook works the other way: Tuolen tells your server that an event happened. For example, your workflow could record a resolved conversation in your own system. That's the design we're explaining, not a completed integration.

0:38Choose the correct credential

Start in the authentication guide. Workspace operations can use a personal access token from Settings, then API Tokens, if your role allows it. Widget keys are for the widget; reporting keys stay on your server. They're not interchangeable. Check the required credential on the exact endpoint you plan to use.

1:00Start with a read-only request

For a first request, the quick-start guide shows a read-only call that lists your agents. The token comes from your server environment, not your frontend code. Use the documented API origin and path exactly. Don't paste a real credential into a video, shared screenshot, or public example.

1:21Register an approved webhook receiver

For webhooks, choose a public receiver you control, preferably using a secure connection, and select only the events you need. The guide shows registration through the API. Configuration requires webhook access on your plan and the right role. Store the signing secret securely when it's returned.

1:42Understand the event payload

Read the event contract before building the next step. A conversation resolved event includes the conversation and agent identifiers. Your backend can use the relevant read API to get any additional permitted context. Send downstream systems only what they need, not an entire customer conversation by default.

2:05Verify and deduplicate safely

Verify the webhook signature against the original request bytes before processing it. Check the timestamp, then use the verified event identifier to prevent the same delivery from repeating an action. Save the accepted event and processing job durably before acknowledging. The guide explains the verification details for your developer.

2:28Plan for missed deliveries

One important detail: Tuolen documents a single best-effort delivery attempt, with a ten-second timeout. There are no automatic retries or replay guarantees. Build monitoring and reconciliation into your own workflow, and check delivery logs. Don't treat a webhook notification as your only record of important state.

The documented test action sends a real test event to your configured receiver, so use an approved destination and inspect the result. A successful test proves that delivery, not every future one. Start with a narrow workflow, verify it carefully, and expand only after you've seen it work.

3:11Build one useful connection

Connect one useful event to one clear next step. Keep credentials private, verify what arrives, and plan for delivery failures. Visit Tuolen dot com, and open Docs to start building.