DocsGuide
Product
Frontend Guide
The product-facing integration guide for building a customer-friendly MidSync frontend.
Guide for multiple API surfacesScope: Depends on API key scopes configured in backend
Best for
Product, frontend, and design teams shaping the overall generation experience.
Stable docs plus runtime-driven UI
Friendly validation and pricing preview
Separating video, image, usage, and docs clearly
Overview
This guide defines the public developer-facing integration direction for MidSync.
The main rule is: keep the public entry path stable, use model docs to explain allowed parameters, and treat the task-creation response as the source of final charged points.
Authentication strategy
- Customer-facing API usage should use Authorization: Bearer <midsync_api_key>.
- Your own product frontend should call MidSync backend, not upstream providers directly from the browser.
- Backend should handle routing, point deduction, pricing metadata, and validation errors.
Product UX principles
- Keep the public entry path stable.
- Render only fields supported by the selected model doc.
- Use progressive disclosure for advanced settings.
- Validate inline before submit.
- Show final charged points after create.
- Use usage endpoints for billing visibility.
Frontend-ready API groups
Group
Model rules
Create
Billing
Completion
Video
Model-specific docs
POST /unified-video/generate
GET /v1/usage/logs and GET /v1/usage/summary
Callback first, task tracking as needed
Usage
N/A
N/A
GET /v1/usage/logs and GET /v1/usage/summary
N/A
Recommended frontend flow
- Video: let the customer choose a model, render fields from the documented model rules, then submit POST /unified-video/generate.
- After create succeeds, show taskId, providerTaskId, and pointsCharged clearly.
- Usage: show point balance, usage logs, and summary cards in a billing/dashboard area.
Validation and error UX
- Validate locally when the rule is already documented on the selected model page.
- Keep the primary action disabled when the configuration is invalid.
- Use friendly error messages that explain what is wrong and how to fix it.
- Keep the unified-video docs consistent with the actual frontend integration flow.
Information architecture
- Generation should focus on Unified Video.
- Billing should show point balance and recent usage.
- History should show generation history and task status.
- Docs should stay stable and human-readable for external developers.
Ready to test with your own key?
Create a general API key in Settings, then come back here to copy a request example.