DOC: Add usage and trigger details for backend functions

[dheeraj12347]

Overview
The current Functions section in the README lists each backend function with a brief description, but it does not explain how to trigger these functions, what inputs they expect, or what responses they return. This makes it harder for new contributors to test and extend the backend functions effectively.
​
Problems identified

The README describes each function (create room, join room, send OTP, etc.) but does not document trigger types (HTTP, cron, or webhook) or any concrete endpoints/schedules.
There are no examples of request payloads or responses, so contributors need to dig into the code and Appwrite dashboard configuration to understand how to call a function correctly.
Functions like discussion-isTime-checker and database-cleaner run on schedules, but the cron configuration and behavior are not visible from the README.
​
Proposed changes

I’d like to improve the README by adding a compact “usage” summary for each major function, without changing any backend logic:
For each main function (create-room, delete-room, join-room, livekit-webhook, match-maker, send-otp, verify-otp, verify-email, discussion-isTime-checker, database-cleaner):
​
Add Trigger type:
HTTP endpoint / Appwrite function URL,
Cron schedule (for discussion-isTime-checker), or
Webhook origin (for livekit-webhook).

Add a short Input summary:
Key body/query/headers that are required (e.g., room ID, user ID, email, OTP code).

Add a short Output summary:
What a successful response roughly looks like (e.g., JSON with room info / token) and the most common error cases (missing params, auth failure, etc.).
Add a direct link to the function folder under functions/... so readers can quickly jump to the implementation (for example, functions/create-room, functions/join-room, functions/send-otp, etc.).
​
Optionally, for 2–3 core functions (such as create-room, join-room, send-otp), add a minimal curl example showing how a contributor can invoke the function in a local/dev environment.

Scope and impact
Changes will be documentation‑only, focused on the README.
The goal is to make the backend functions easier to understand, test, and debug for new contributors, without touching any runtime behavior.

If this sounds good, I’d be happy to work on this and open a PR.

[Khan30-ai]

Hi! I’d like to work on this issue.

I plan to improve the root README by adding a concise usage summary for each major backend function, including:
i) the trigger type (HTTP / cron / webhook),
ii) a short input and output overview (high level, no schemas),
iii) and a direct link to the corresponding function folder under functions/.

For a small subset of core HTTP functions (like create-room, join-room, and send-otp), I can also add minimal curl examples to help new contributors test them in a local/dev setup.

All changes will be documentation only and scoped to the README, without touching any backend logic or runtime behavior.

Please let me know if this approach sounds good. I’ll proceed once confirmed.

[M4dhav]

There is detailed usage documentation in each function's folder, and these folders are linked to the README

• check https://github.com/AOSSIE-Org/Resonate-Backend/tree/main/functions/create-room for example