Skip to content

SDK Quickstarts #457

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 17 commits into
base: feature/examples-code
Choose a base branch
from
Open

Conversation

goosewin
Copy link
Collaborator

Description

  • Aggregated web and sdk quickstarts into 2 pages
    • quickstart/client-sdk.mdx
    • quickstart/server-sdk.mdx
  • For every code snippet / example we have tabs for each SDK

Testing Steps

  • Run the app locally using fern docs dev or navigate to preview deployment
  • Ensure that no links are broken
  • Ensure that all examples make sense and we're not missing any snippets
  • Ensure that code snippets are functional and are based on best practices

@goosewin goosewin requested a review from elizabethtrykin May 30, 2025 19:33
Copy link
Contributor

@goosewin goosewin removed the request for review from elizabethtrykin June 1, 2025 00:39
Copy link
Contributor

github-actions bot commented Jun 1, 2025

Copy link
Contributor

github-actions bot commented Jun 1, 2025

📝✨ Documentation Review by Claude 🤖

Hey there! 👋 I've reviewed your documentation changes against our style guidelines. Here's what I found:

📄 fern/examples.mdx

Looking at your examples.mdx file! 🎉

Overall Assessment ✅

This is a clean, well-structured landing page that follows most of the documentation guidelines perfectly!

What's Working Well 🚀

Perfect front matter: Title and subtitle are clear and concise
Great Card usage: Proper title, icon, and href format
Excellent scannability: Clean layout with CardGroup cols={2}
Descriptive links: Each card clearly describes what the example does
Consistent tone: Direct and professional
Good spacing: Well-organized with appropriate whitespace

Minor Suggestions 💡

🎯 Consider adding context: While the cards are descriptive, you might consider adding a brief intro paragraph explaining what users will find in these examples and how they can help them get started.

Example:

---
title: Examples
subtitle: Explore complete examples with step-by-step instructions to build with Vapi
slug: examples
---

Ready to see Vapi in action? These examples show you how to build real-world voice AI applications with complete code and step-by-step instructions.

<CardGroup cols={2}>
  <!-- your existing cards -->
</CardGroup>

Link validation: Make sure all the href paths (/examples/outbound-sales, etc.) actually exist and work correctly.

Final Verdict 🎉

This is excellent work! The page is clean, scannable, and follows the documentation guidelines well. It's a great landing page that will help users quickly find the examples they need.


📄 fern/quickstart/client-sdk.mdx

Looking at your Client SDKs documentation, here's my review:

Overall Assessment ✅

This is a solid documentation file with good structure and comprehensive coverage! The multi-platform approach with tabs is excellent for showcasing Vapi's cross-platform capabilities.

Things Done Well 🎉

  • Excellent use of tabs for different platforms - makes it easy to find relevant code
  • Comprehensive code examples across Web, Python, React Native, Flutter, and iOS
  • Good visual hierarchy with clear sections and card groups
  • Practical voice widget implementations - these are exactly what developers need
  • Active voice throughout - "Build voice interfaces" not "Voice interfaces can be built"
  • Proper MDX components - Cards, Tabs, and CodeBlocks used correctly

Areas for Improvement

🎯 Subtitle Enhancement

Your subtitle is good but could be more action-oriented:

Current: "Build voice interfaces and web calls using Vapi's Client SDKs across platforms."
Suggested: "Learn to build voice interfaces and web calls across multiple platforms."

📝 Writing Style Tweaks

Intent before action - A few places could benefit from explaining "why" before "how":

Current opening:

"In this quickstart, we'll build voice interfaces and web-based conversations using Vapi's Client SDKs."

Consider:

"Client SDKs enable real-time voice interactions in user-facing applications. In this quickstart, you'll build voice interfaces and web-based conversations across multiple platforms."

💡 Code Example Improvements

Python Client tab - The event handling syntax looks unusual:

# This syntax seems off
@vapi.on('transcript')
def on_transcript(message):
    print(f"{message.role}: {message.text}")

iOS code - Consider adding brief context before the code blocks to explain what each example demonstrates.

⚠️ Minor Issues

  1. Inconsistent property names across examples:

    • Web SDK uses message.transcript
    • Python uses message.text
    • Ensure consistency or explain differences
  2. Missing error handling in code examples - consider adding basic error handling patterns

  3. Resource links at the bottom could benefit from brief descriptions of what each link provides

✨ Enhancement Suggestions

  1. Add a troubleshooting callout for common setup issues
  2. Include performance considerations for mobile implementations
  3. Add authentication section explaining public vs private API keys

Technical Accuracy 🤔

The code examples look comprehensive, but I'd recommend having the engineering team verify:

  • Python client event handling syntax
  • Flutter package name and import paths
  • iOS SDK delegate methods

Final Score: 8.5/10 🚀

This is high-quality documentation that effectively serves developers across multiple platforms. The improvements suggested are mostly minor refinements that would make an already good document even better!


📄 fern/quickstart/server-sdk.mdx

Looking at this Server SDK documentation, here's my review:

Overall Assessment ✅ 🎉

This is a solid, comprehensive guide that does an excellent job covering multiple programming languages and practical use cases. The structure is logical and user-focused.

What's Working Well 🚀

  • Multi-language coverage: Excellent use of tabs to show the same concepts across 6 different programming languages
  • Practical examples: Real-world scenarios like bulk campaigns and webhook handling
  • Clear progression: Moves logically from setup → basic usage → advanced features
  • Code quality: All examples are complete and actionable
  • Resource links: Good collection of GitHub repos and community links

Issues to Address

🚨 Front Matter Problem

The subtitle is too long and doesn't follow the guidelines:

# Current (too long)
subtitle: Build automated voice calls and backend integrations using Vapi's Server SDKs.

# Better (concise)
subtitle: Learn to build automated voice calls and backend integrations

🔥 Comment Syntax Issues

Several code blocks use // comments in non-JavaScript languages:

Python tabs (lines in Python examples):

// Create an outbound call  # Should be: # Create an outbound call

Ruby tabs:

// Create an outbound call  # Should be: # Create an outbound call

This appears in multiple places and will confuse developers.

⚠️ Minor Writing Issues

  1. Passive voice in intro:

    • Current: "You'll learn how to create assistants"
    • Better: "Create assistants, manage calls, and handle real-time events"
  2. Missing context for code examples: The webhook integration section jumps into complex Express/Flask code without explaining what these webhooks accomplish for the user.

💡 Enhancement Suggestions

  1. Add outcome statements: Start each major section with what the user will accomplish
  2. Explain webhook value: Add a brief intro explaining why webhook integration matters for their voice applications
  3. Consider callouts: The bulk operations section could benefit from a about rate limiting best practices

Quick Fixes Needed 🎯

  1. Fix comment syntax in Python and Ruby code blocks
  2. Shorten the subtitle in front matter
  3. Add brief context before the webhook integration section
  4. Convert intro passive voice to active voice

The documentation structure and content quality are excellent - these are mainly syntax and style polish issues that will improve the developer experience significantly.


📄 fern/overview.mdx

📝 Documentation Review for fern/overview.mdx

Overall, this is a well-structured overview page! ✅ The use of CardGroups and clear sections makes it very scannable. Here's my detailed feedback:

🎉 What's Working Well

  • ✅ Excellent MDX component usage: Perfect use of CardGroups throughout
  • ✅ Clean structure: Logical flow from intro → capabilities → concepts → examples
  • ✅ Great scannability: Headers and cards make content easy to scan
  • 🚀 Descriptive links: All links use meaningful text (no "click here")
  • ✅ Good front matter: Title and subtitle are clear and concise

🔥 Issues That Need Fixing

🚨 Typo in line 31

"spoken back ot the user" → "spoken back to the user"

📝 Grammar issue in line 16

"Vapi began as a product build on top of voice agents" 
→ "Vapi began as a product built on top of voice agents"

📝 Writing style issues

  • Line 7: "It handles the underlying infrastructure stack to your agents" - the "to" should be "for"
  • Line 191: Redundant phrasing "connect with other developers & connect with our team" - could be "connect with other developers and our team"

⚠️ Minor Improvements

🎯 Title consistency

Some Card titles could be more consistent:

  • Line 40: "No-code Quickstart" vs Line 45: "Client SDKs"
  • Consider: "No-code quickstart" and "Client SDKs" (consistent capitalization)

🤔 Content clarity

  • Line 123: "ins-and-outs" could be simplified to "details" for clearer language
  • Line 185: "Common questions asked by other users" could be just "Common questions"

📝 Tone consistency

Some Card descriptions start with "We'll build..." while others start with different patterns. Consider standardizing for consistency.

💡 Suggestions for Enhancement

✨ Add context to Examples section

The Examples section could benefit from a brief intro explaining what makes these examples comprehensive (end-to-end, real-world scenarios, etc.).

🧩 Consider adding a callout

After the "What is a Voice Agent?" section, you could add:

<Tip>
Each Assistant component (STT, LLM, TTS) can be customized with different providers and models to optimize for your specific use case.
</Tip>

🎯 Priority Fixes

  1. 🔥 Fix the typo: "ot" → "to" (line 31)
  2. 🔥 Fix grammar: "build" → "built" (line 16)
  3. ⚠️ Fix preposition: "stack to your agents" → "stack for your agents" (line 7)

The document follows most style guidelines well and effectively uses MDX components. These fixes will make it even better! 🚀


📄 fern/quickstart/dashboard.mdx

Looking at your dashboard quickstart documentation, this is an excellent comprehensive guide! Here's my review:

✅ Major Strengths

🎉 Great structure - Love the tabbed approach showing Dashboard, Web SDK, Server SDK, and cURL options
🚀 Comprehensive coverage - Covers both inbound and outbound calls thoroughly
Proper MDX usage - Excellent use of <Steps> components instead of numbered lists
🎯 Clear examples - Code snippets are concrete and well-documented
Good visual elements - GIFs and images enhance understanding

🔥 Critical Issues to Fix

🚨 Title capitalization - Your title "Dashboard" should follow the "only first word capitalized" rule. It's actually correct, but double-check other headings.

🚨 Bold formatting inconsistency - You have ***assistants*** which creates bold+italic. Use **assistants** for just bold formatting.

⚠️ Minor Improvements

🤔 Passive voice instances:

  • "which we call assistants" → "called assistants"
  • "You can call an assistant or have it call you" is good (active)

🤔 Link text - Most links are good, but ensure all are descriptive

📝 Writing style tweaks:

  • "Vapi makes it easy to build end-to-end voice agents" - great active voice
  • Consider shortening some longer paragraphs in the code examples

💡 Suggestions

Callout opportunities - Consider adding a <Tip> callout about model experimentation (you already have one, which is great!)

🧩 Consistent formatting - The code blocks are well-formatted, but ensure consistent spacing around them

🎯 Specific Fixes Needed

  1. Line 8: Change ***assistants*** to **assistants**
  2. Consider breaking up the longer system prompt examples into more digestible chunks
  3. Verify all headings follow first-word-only capitalization

🚀 Overall Assessment

This is a high-quality quickstart guide that effectively uses MDX components and provides multiple implementation paths. The structure is logical, examples are practical, and the step-by-step approach is perfect for users getting started. Just needs those minor formatting fixes!

The multi-tab approach allowing users to choose their preferred method (Dashboard vs various SDKs) is particularly well done and user-friendly.


📄 fern/sdk/web.mdx

Looking at your Web SDK documentation, here's my review:

🎉 What's Working Well

Clean structure - Good logical flow from installation to usage to events
Excellent code examples - Every method has clear, practical code snippets
Good use of MDX components - Proper use of <Info>, <CardGroup>, and <Card>
Active voice - "You can start a web call" not "A web call can be started"
Present tense - Consistent throughout

🔥 Major Issues to Fix

🚨 Front matter subtitle - Change "Integrate Vapi into your web application." to "Learn to integrate Vapi into your web application" (following the style guide for guides)

⚠️ Minor Improvements

🤔 Inconsistent section spacing - Some sections have --- dividers, others don't. Be consistent.

📝 Code comment formatting - The long comment in the first .start() example should be broken into multiple lines for better readability:

const call = await vapi.start(assistantId);
// Returns call object with id, orgId, createdAt, updatedAt, type, etc.

🎯 Link text improvement - "see Create Assistant" could be more descriptive: "see the Create Assistant API reference"

💡 Suggestions for Enhancement

Add context callouts - Consider adding <Tip> or <Note> components for important concepts like:

  • When to use assistant ID vs inline configuration
  • Performance implications of ephemeral vs persistent assistants

🧩 Event examples - The events section could benefit from more practical examples showing how developers might use these events in real applications.

Overall Assessment

🚀 This is solid documentation! The structure is logical, examples are comprehensive, and the writing style follows most guidelines well. Just a few tweaks needed for consistency and that front matter subtitle fix.

The documentation successfully guides developers from basic setup through advanced usage patterns. Great work! 🎉


📄 fern/docs.yml

Looking at this docs.yml configuration file, I can see this is the main Fern documentation configuration. Since this is a YAML configuration file rather than user-facing documentation content, most of the documentation guidelines don't directly apply. However, I can review it for clarity and organization! ✅

Overall Assessment 🎉

This is a well-structured documentation configuration that demonstrates excellent organization and user experience considerations:

Excellent navigation hierarchy - Clear logical grouping from basic concepts to advanced features
Consistent naming conventions - Good use of descriptive slugs and titles
Comprehensive coverage - Covers all major product areas
Good use of icons - FontAwesome icons enhance navigation UX

Areas That Look Great 🚀

Clear section organization - Logical flow from "Get started" → "Workflows" → "Assistant customization" → "Best practices"
Helpful redirects - Comprehensive redirect mapping for URL changes
Good tab structure - Separates documentation, API reference, SDKs, and changelog appropriately
Professional styling - Clean color scheme and branding

Minor Suggestions 💡

⚠️ Consistency in section naming: Most sections use lowercase (e.g., "tools", "calls") but some use title case. Consider standardizing.

⚠️ Deep nesting: Some sections like "Assistant customization" have quite deep nesting (4+ levels). Consider if any could be flattened for better discoverability.

💡 Icon consistency: You're mixing FontAwesome prefixes (fa-light, fa-brands, fa-solid). Consider standardizing on one weight where possible.

Configuration-Specific Notes 📝

Good analytics setup - Both PostHog and GA4 configured
Proper asset organization - CSS, JS, and static files well organized
Sensible layout settings - Good content width and spacing choices

Since this is a configuration file rather than user-facing content, the main documentation guidelines about writing style, tone, and MDX components don't apply here. The structure looks solid for organizing the actual documentation content! 🎯

The navigation flow makes sense for users progressing from basic setup to advanced customization, which aligns well with typical user journeys.


📖 Style Guidelines | Thanks for contributing! 🙏✨

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant