> Portal Navigation:
> 
> - Append `.md` to any URL under `https://dev.wix.com/docs/` to get its markdown version.
> - Pages are either content pages (article or reference text) or menu pages (a list of links to child pages).
> - To get a menu page, truncate any URL to a parent path and append `.md` (e.g. `https://dev.wix.com/docs/sdk.md`, `https://dev.wix.com/docs/sdk/core-modules.md`).
> - If a reference page seems to be missing its schema (parameters, return types, or type definitions), append `?schema=true` to its `.md` URL (e.g. `https://dev.wix.com/docs/contexts/contexts/stores/category-info/use-category-info-context.md?schema=true`).
> - Top-level index of all portals: https://dev.wix.com/docs/llms.txt
> - Full concatenated docs: https://dev.wix.com/docs/llms-full.txt

## Resource: Sample Flows

## Article: Sample Flows

## Article Link: https://dev.wix.com/docs/api-reference/business-management/calendar/conferencing/conferencing-provider-v1/sample-flows.md

## Article Content:

# Conferencing Provider: Sample Flows

This article presents possible use cases and corresponding sample flows that your service plugin can support. It provides a useful starting point as you plan your implementation.

## Add a conferencing provider with OAuth

A site user wants to connect their account in your provider so conferences can be created on their behalf. Your implementation owns the OAuth flow and the resulting connection.

> **Prerequisite:** Your Conferencing Provider service plugin is registered and configured, with `OAUTH` listed in `connectionMethods`.

To add a conferencing provider with OAuth:

### Step 1 | Wix calls your implementation

Wix calls your Connect By OAuth method with the `resourceId` to connect and a `redirectUrl` to return the user to.

### Step 2 | Your implementation returns an OAuth URL

Generate the authorization URL for your provider and return it as `oauthUrl`. Wix redirects the user there to grant access.

### Step 3 | Your implementation handles the callback

After the user authorizes, your provider calls your callback. Exchange the authorization code for tokens, create and store a connection for the `resourceId` (generating a stable connection `id`), and set its `connectedDate`. Wix ignores connections without a `connectedDate`.

### Step 4 | Your implementation redirects back to Wix

Redirect the user to the `redirectUrl` with `?connectionId=<id>` on success, or `?error=<code>` on failure (`reject`, `missing_permissions`, or `internal`).

### Step 5 | Wix reads the connection

Wix calls your List Connections method to read the connection state and show the connection's status.

## Create and manage a conference for a connected resource

Once a resource is connected, Wix asks your implementation to create a conference and, later, to update, retrieve, or delete it.

> **Prerequisite:** The resource has an active connection in your system (see [Add a conferencing provider with OAuth](#add-a-conferencing-provider-with-oauth)).

To create and manage a conference:

### Step 1 | Wix requests a conference

Wix calls your Create Conference method with the `resourceId` and optional scheduling details (`title`, `startTime`, `durationInMinutes`).

### Step 2 | Your implementation creates the meeting

Look up the connection for the `resourceId`, create a distinct meeting in your provider, and return the conference details, including a stable conference `id`, the join `url`, and any `password`.

### Step 3 | Wix uses the response

Wix passes the details you return, including the join URL, to the Wix product that requested the conference. Wix doesn't store the conference, so it calls Get Conference when it needs the current details.

### Step 4 | Wix manages the conference later

When the meeting changes, Wix calls your Update Conference method (only if your configuration sets `updateSupported = true`). To read or remove the meeting, Wix calls Get Conference or Delete Conference. Each call includes the conference `id` and `resourceId` you returned, which you use to look the meeting up in your provider.