Video API Usage Monitoring with Moyan SEE

Video API Usage Monitoring with Moyan SEE

Adding video to a product creates an operational question that an embedded room cannot answer by itself: how much calling capacity is your application consuming, and what happens when it runs out?

For developers, usage monitoring belongs alongside the meeting interface—not on a billing checklist after launch. A short group call can consume more participant-minutes than a long one-to-one conversation, while quality choices introduce another dimension to cost planning.

Moyan SEE by Moyan AI is a browser-based HD video meeting platform. Its developer tools include a REST API at /api/public/v1/meetings, usage reporting at /api/public/v1/usage, and a free JavaScript SDK with embedMeeting, joinUrl, and theming options.

This guide focuses on the layer around those tools: tracking consumption, reconciling usage, and preparing your product for capacity limits.

Understand the unit before building the dashboard

A participant-minute measures attendance over time, rather than simply counting how long a room exists.

For planning purposes, a 20-minute call with four people present throughout represents 80 participant-minutes. If two people attend all 20 minutes and another two attend only 10 minutes each, the estimate becomes 60 participant-minutes.

Those examples explain the unit; they do not establish Moyan SEE's billing precision or rounding rules. Verify those details before treating an application-side calculation as a billing record.

That distinction matters in products with uneven attendance. Your dashboard should distinguish between:

• Meeting duration: elapsed time for a conversation.
• Attendance: how many people participate and for how long.
• Estimated participant-minutes: your application's planning calculation.
• Reported usage: consumption retrieved through the usage API.

Do not label an estimate as an invoice-ready total. Give developers and administrators enough context to understand why two numbers might differ.

Separate meeting access from API capacity

Moyan SEE's meeting plans and API plans are separate product lines. A paid meeting subscription does not include an API allowance.

For API development, the free Developer plan provides a one-time allocation of 10,000 participant-minutes in the first month. It is not a recurring monthly allocation.

Growth provides 25,000 participant-minutes for $58 per month, while Scale provides 150,000 participant-minutes for $298 per month. Extra minutes are listed at $25 per 10,000.

These distinctions should influence your internal account model. Avoid using a single “paid customer” flag to decide whether an integration has calling capacity. Instead, represent meeting-plan access and API capacity separately in your application's business logic.

Most importantly, Moyan SEE usage hard-stops instead of generating surprise billing. Treat capacity exhaustion as a product state you need to design for, not merely an accounting event.

Design a usage layer around the REST API

Keep your application-side usage model small at first. Its purpose is to support decisions, not duplicate an entire billing system.

A practical design separates these responsibilities:

Layer	Responsibility	Implementation caution
Meeting integration	Work with /api/public/v1/meetings	Verify supported operations and request formats
Client experience	Use SDK embedding or joinUrl	Keep local usage estimates distinct from provider data
Usage reconciliation	Retrieve reporting from /api/public/v1/usage	Confirm available fields and reporting granularity
Capacity policy	Decide when your app warns or restricts access	This is application logic you build
Operator dashboard	Show usage and retrieval status	Display when the data was last refreshed

The endpoint paths alone do not establish response schemas, reporting latency, pagination, or per-meeting attribution. Check the API documentation before choosing database fields or writing a parser.

In particular, do not assume the usage response can identify each of your customers. If your product serves multiple organizations, determine whether the available reporting supports that attribution. Maintain your own application identifiers where necessary, and label any resulting allocation as an estimate unless it can be reconciled reliably.

Reconcile usage without overstating freshness

A sensible reporting process retrieves usage on a controlled schedule, stores successful results, and records retrieval failures separately from consumption.

Your implementation checklist should include:

1. Confirm the reporting scope. Establish what period and account context a usage response covers.
2. Store retrieval timestamps. Let operators distinguish current data from an older successful result.
3. Preserve reported values. Keep raw reporting data separate from calculations used for forecasting.
4. Prevent duplicate accounting. Determine whether responses contain cumulative totals or incremental records before adding anything together.
5. Surface uncertainty. Show stale or unavailable reporting as such, rather than replacing it with zero.
6. Test recovery. Make sure a temporary reporting failure does not erase previously known consumption.

These are application design recommendations, not claims about built-in Moyan SEE dashboard features.

Likewise, handle request failures conservatively. Verify documented rate limits and retry behavior rather than guessing a requests-per-second limit. Avoid tight retry loops, and do not automatically repeat meeting operations unless you have confirmed that doing so is safe.

Make quality an explicit product decision

Moyan SEE offers Full HD by default, a 2K option, and audio-only calls. Its listed pay-per-minute rates provide a useful comparison when evaluating call experiences:

Usage category	Price per 1,000 participant-minutes	Product question to ask
Audio	$0.79	Does this interaction need video?
HD	$2.99	What visual detail does the workflow require?
Full HD	$6.49	Is this the intended default experience?
2K	$12.49	Does additional resolution serve the task?

Do not assume these rates describe how every allowance or extra-minute purchase is applied. Confirm the applicable billing arrangement before turning a quality selection into a projected charge.

For your application, document which experience each workflow needs. An audio-only consultation and a visually detailed review need not share the same product requirements. Verify supported configuration options before implementing quality controls; the SDK's theming options should not be mistaken for media-quality settings.

Plan the hard-stop experience before launch

Because usage hard-stops, your product needs a clear response when capacity is unavailable. Confirm the exact API behavior, including what happens to active meetings, rather than promising uninterrupted calls.

Application-side warning thresholds can help your team respond earlier. Choose them using your expected demand and operational response time, not an arbitrary universal percentage.

Prepare honest user-facing copy. A capacity problem should not appear as a camera-permission error. Where appropriate, let users contact your team or return later, without promising an automatic capacity increase your system cannot deliver.

Moyan SEE will not be the best fit for every integration. If a competing provider documents a billing model or reporting capability that better matches a non-negotiable requirement, that competitor may be the better choice. Evaluate those requirements before committing your architecture.

Start with one measurable test

Before polishing a branded embed, prove that your team can understand its consumption.

Go to Moyan SEE, start with the Developer API offering, and run a controlled test meeting. Record attendance and duration, inspect the reporting available through /api/public/v1/usage, and compare the reported result with your participant-minute estimate. Use that test to define your first usage dashboard and capacity-warning policy.