feat(docs): add custom MFA channel guides for Telegram and WhatsApp

[atharvadeosthale]

Adds a guide that shows how to deliver the custom MFA code through a real channel. The custom MFA factor page covers the flow. This page covers the two parts that page leaves to the reader: where the destination comes from, and what the provider call looks like.

One page, /docs/products/auth/custom-mfa-channels, with a tab per channel across three steps.

Telegram

• Bot setup through BotFather.
• Enrollment through a one-time deep link, so the chat ID is bound to the Appwrite user instead of taken from the client.
• A webhook function that receives the chat ID, with the secret header check.
• The delivery call.

WhatsApp

• Meta app setup and authentication template creation.
• The destination is the phone number already in the Appwrite user record, gated on phoneVerification.
• The delivery call, including the OTP button component.

Verification

Every Appwrite call, scope name, and response shape was checked against SDKs generated from the build the custom factor landed in. Both provider payloads were checked against provider documentation. Neither channel has been executed end to end yet: Telegram is testable on demand, WhatsApp needs Meta template approval first.

Notes for review

• Based on atharva/custom-mfa-factor-docs, because the page links to the custom MFA factor page and sits below it in the sidebar. Merge that one first.
• Node only. The channel call is plain HTTP, so the runtime is not the subject of this page, and the Rust equivalent of the read step already appears on the custom MFA factor page.

[appwrite]

Appwrite Website

Project ID: 69d7efb00023389e8d27

Sites (1)

Site	Status	Logs	Preview	QR
website 69d7f2670014e24571ca	Ready	View Logs	Preview URL

Website (appwrite/website)

Project ID: 684969cb000a2f6c0a02

Sites (1)

Site	Status	Logs	Preview	QR
website 68496a17000f03d62013	Queued	View Logs	Preview URL

---

Tip

Appwrite has crossed the 50K GitHub stars milestone with hundreds of active contributors

[greptile-apps]

Greptile Summary

The PR adds a custom MFA channel guide for Telegram and WhatsApp and links it from the authentication documentation sidebar.

• Documents provider setup and destination enrollment.
• Provides Node.js delivery examples for both channels.
• Adds security guidance for binding and verifying delivery destinations.

Confidence Score: 2/5

The PR does not appear safe to merge because the Telegram enrollment remains vulnerable to concurrent rebinding and the documented table schema can reject the enrollment writes.

The webhook still consumes enrollment tokens through separate non-transactional read and update operations, so overlapping requests can overwrite the destination used for later MFA delivery. The schema also does not specify optional columns even though the initial write omits chatId and the completion write clears linkToken.

Files Needing Attention: src/routes/docs/products/auth/custom-mfa-channels/+page.markdoc

Important Files Changed

Filename	Overview
src/routes/docs/products/auth/+layout.svelte	Adds the new custom MFA channels page to the hand-authored authentication sidebar.
src/routes/docs/products/auth/custom-mfa-channels/+page.markdoc	Adds the Telegram and WhatsApp setup, enrollment, delivery, and security documentation.

_{Reviews (2): Last reviewed commit: "feat(docs): add custom MFA channel guide..." | Re-trigger Greptile}

[greptile-apps]

Column optionality is unspecified

The schema describes chatId as empty before enrollment and linkToken as empty afterward, but it does not tell readers to make those columns optional or provide defaults. Configuring either column as required makes the corresponding initial upsert or enrollment-completion update fail validation.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/routes/docs/products/auth/custom-mfa-channels/+page.markdoc
Line: 89-92

Comment:
**Column optionality is unspecified**

The schema describes `chatId` as empty before enrollment and `linkToken` as empty afterward, but it does not tell readers to make those columns optional or provide defaults. Configuring either column as required makes the corresponding initial upsert or enrollment-completion update fail validation.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!