Forem: SENZEN

I Built and Launched an AI Document API in Under a Week — Here's Exactly How I Did It

SENZEN — Thu, 26 Feb 2026 11:45:08 +0000

I Built and Launched an AI Document API in Under a Week — Here's Exactly How I Did It

TL;DR: I built Condensare — an AI-powered document processing API that turns any uploaded file into structured notes and contextualised implementation suggestions. It's live on RapidAPI. This is the full breakdown of how I built it, deployed it, tested it and shipped it.

The Problem

A few weeks ago I had a simple frustration.

I was uploading documents to various AI tools trying to get useful summaries and actionable insights, and every single one felt generic. The output didn't know what industry I was in, what scale my business operated at, or what I actually wanted to do with the information.

It just summarised. That was it.

So I built Condensare — a document condensing and AI suggestion API that takes any uploaded file and returns structured notes plus contextualised implementation suggestions.

The Stack

I kept it simple and production-focused:

Layer	Technology
API Server	Node.js + Express
AI	OpenAI GPT-4o
Deployment	Vercel (serverless)
Marketplace	RapidAPI
File Uploads	Multer
Document Parsing	pdf-parse, mammoth, xlsx

Vercel serverless was the right call for an API marketplace product — zero infrastructure management, global distribution out of the box, automatic scaling. You don't want to be managing servers when you're trying to get to market fast.

Project Structure

condensare-api/
├── src/
│   ├── app.js                  # Express entry point
│   ├── routes/
│   │   └── condense.js         # Route definitions
│   ├── middleware/
│   │   └── authenticate.js     # Auth + plan management
│   ├── services/
│   │   ├── parseService.js     # File parsing logic
│   │   ├── condenseService.js  # AI condensing logic
│   │   └── suggestService.js   # AI suggestions logic
│   └── utils/
│       └── fileUtils.js        # File validation helpers
├── vercel.json
└── package.json

The Two Endpoints

`POST /api/v1/condense/parse`

Available on: FREE, PRO, MEGA, ULTRA

The lightweight endpoint. Upload any supported file and get back extracted raw text plus metadata — word count, character count, MIME type, a unique request ID and processing time. No AI involved, just clean text extraction.

Example response:

{
  "success": true,
  "data": {
    "id": "c934e6f2-a2d8-416e-8782-c40e4e5eb8d3",
    "filename": "report.pdf",
    "mimeType": "application/pdf",
    "characterCount": 9786,
    "wordCount": 1438,
    "extractedText": "Full extracted text content...",
    "parsedAt": "2026-02-24T10:00:00.000Z",
    "processingTimeMs": 385
  }
}

`POST /api/v1/condense`

Available on: PRO, MEGA, ULTRA

The full AI pipeline. File gets parsed, text gets passed to GPT-4o with a carefully engineered prompt, and you get back two structured objects:

Condensed Notes — title, summary, key points, organised sections, keywords
AI Suggestions — prioritised recommendations, quick wins, long term goals, risk warnings

Example response:

{
  "success": true,
  "data": {
    "id": "2f05d51f-1469-4399-8d93-2005f6215028",
    "plan": "pro",
    "priorityProcessing": false,
    "processingTimeMs": 11641,
    "condensedNotes": {
      "title": "Comprehensive Guide to Setting Up a Project",
      "summary": "Step-by-step guide covering project setup...",
      "keyPoints": [
        "Create a project directory and navigate to it.",
        "Install Node.js and initialise a React project.",
        "Connect the project to a GitHub repository."
      ],
      "sections": [
        {
          "heading": "Setup",
          "content": "Instructions for creating the project directory."
        }
      ],
      "keywords": ["React", "Firebase", "Node.js"],
      "tone": "business",
      "depth": "standard"
    },
    "suggestions": {
      "suggestions": [
        {
          "title": "Integrate AI Features",
          "description": "Leverage AI to enhance user experience.",
          "priority": "high",
          "effort": "medium",
          "impact": "high"
        }
      ],
      "quickWins": ["Set up a GitHub repo immediately."],
      "longTermGoals": ["Build a CI/CD pipeline."],
      "warnings": ["Monitor Firebase costs as usage scales."]
    }
  }
}

File Parsing

Supporting multiple file types meant handling each format differently under the hood:

const parseFile = async (file) => {
  const { mimetype, buffer } = file;

  switch (mimetype) {
    case 'application/pdf':
      return await parsePdf(buffer);

    case 'application/vnd.openxmlformats-officedocument.wordprocessingml.document':
      return await parseDocs(buffer);

    case 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet':
      return await parseXlsx(buffer);

    case 'text/plain':
    case 'text/markdown':
    case 'text/csv':
      return buffer.toString('utf-8');

    default:
      throw new Error(`Unsupported file type: ${mimetype}`);
  }
};

Each parser returns normalised plain text. From the AI's perspective it just sees text — the complexity of handling different formats is completely abstracted away.

Authentication and Plan Management

Authentication works through RapidAPI's proxy secret mechanism. Every request through the RapidAPI gateway includes an X-RapidAPI-Proxy-Secret header proving it came through their infrastructure.

Plan management works through the X-RapidAPI-Subscription header which RapidAPI appends automatically:

const authenticate = (req, res, next) => {
  const proxySecret = req.headers['x-rapidapi-proxy-secret'];
  const expectedSecret = process.env.RAPIDAPI_SECRET;

  // Validate proxy secret
  if (!proxySecret || proxySecret !== expectedSecret) {
    return res.status(401).json({
      success: false,
      error: 'Unauthorised. Invalid or missing API credentials.',
      code: 401
    });
  }

  // Detect plan from subscription header
  const subscriptionHeader = req.headers['x-rapidapi-subscription'];
  const plan = VALID_PLANS.includes(subscriptionHeader?.toLowerCase())
    ? subscriptionHeader.toLowerCase()
    : 'free';

  // Attach plan and limits to request
  req.plan = plan;
  req.planLimits = PLAN_LIMITS[plan];

  next();
};

The four tiers and their limits:

const PLAN_LIMITS = {
  free:  { requestsPerDay: 20,    requestsPerMinute: 5,   aiSuggestions: false },
  pro:   { requestsPerDay: 500,   requestsPerMinute: 30,  aiSuggestions: true  },
  mega:  { requestsPerDay: 2000,  requestsPerMinute: 60,  aiSuggestions: true  },
  ultra: { requestsPerDay: 10000, requestsPerMinute: 100, aiSuggestions: true, priorityProcessing: true }
};

Prompt Engineering

Getting consistently structured JSON output from GPT-4o took more iteration than anything else in the project. Early prompts returned well-written prose but in formats that varied between requests — inconsistent field names, missing sections, sometimes prose instead of JSON.

The solution was to be extremely explicit:

const buildCondensePrompt = ({ text, tone, depth, industry, scale, focus, goal }) => `
You are a document analysis AI. Analyse the following document and return a JSON object.

IMPORTANT: Return ONLY valid JSON. No text before or after. No markdown code blocks.

Document:
"""
${text}
"""

Parameters:
- Tone: ${tone}
- Depth: ${depth}
- Industry: ${industry || 'general'}
- Scale: ${scale || 'medium'}
${focus ? `- Focus: ${focus}` : ''}
${goal ? `- Goal: ${goal}` : ''}

Return this exact structure:
{
  "condensedNotes": {
    "title": "string",
    "summary": "string",
    "keyPoints": ["string"],
    "sections": [{ "heading": "string", "content": "string" }],
    "keywords": ["string"],
    "tone": "${tone}",
    "depth": "${depth}"
  },
  "suggestions": {
    "suggestions": [{ "title": "string", "description": "string", "priority": "high|medium|low", "effort": "high|medium|low", "impact": "high|medium|low" }],
    "quickWins": ["string"],
    "longTermGoals": ["string"],
    "warnings": ["string"]
  }
}
`;

The strict structure instruction plus showing the exact JSON shape expected eliminated the inconsistency completely.

Vercel Deployment

Deploying an Express app to Vercel as a serverless function requires a vercel.json config:

{
  "version": 2,
  "builds": [{ "src": "src/app.js", "use": "@vercel/node" }],
  "routes": [{ "src": "/(.*)", "dest": "src/app.js" }]
}

One issue I hit was Swagger UI not rendering on Vercel. The swagger-ui-express package tries to serve static assets from the local filesystem which doesn't work in a serverless environment. The fix was to serve a simple HTML page that loads Swagger UI from the unpkg CDN instead:

app.get('/docs', (req, res) => {
  res.send(`
    <!DOCTYPE html>
    <html>
      <head>
        <title>Condensare API Docs</title>
        <link rel="stylesheet" href="https://unpkg.com/swagger-ui-dist/swagger-ui.css" />
      </head>
      <body>
        <div id="swagger-ui"></div>
        <script src="https://unpkg.com/swagger-ui-dist/swagger-ui-bundle.js"></script>
        <script>
          SwaggerUIBundle({
            url: '/docs/spec',
            dom_id: '#swagger-ui'
          });
        </script>
      </body>
    </html>
  `);
});

Cleaner, faster, no dependency on local static files.

Environment Variables

# Set via Vercel CLI — never in code
vercel env add OPENAI_API_KEY
vercel env add RAPIDAPI_SECRET
vercel env add NODE_ENV

The RAPIDAPI_SECRET must exactly match the proxy secret shown in your RapidAPI provider dashboard under Security → Firewall Settings. No extra spaces, no modifications. This one caught me out — the secret in Vercel needs to be a fresh paste from the RapidAPI dashboard, not typed manually.

Testing

Before listing on RapidAPI I built a Postman collection with 10 tests covering every layer:

Test	Expected	Result
Health check	200 OK	✅
No auth headers	401	✅
Wrong proxy secret	401	✅
FREE plan hits /condense	403	✅
FREE plan hits /parse	200	✅
PRO plan with file	200	✅
No file provided	400	✅
PRO full pipeline	200	✅
ULTRA with focus + goal	200	✅

All 10 passed locally, then all 10 passed against the production Vercel URL. Only after that did I move to the RapidAPI listing.

To test the real proxy secret without going through RapidAPI, I used curl.exe directly in PowerShell:

curl.exe -X POST "https://your-deployment.vercel.app/api/v1/condense" \
  -H "X-RapidAPI-Proxy-Secret: your-proxy-secret" \
  -H "X-RapidAPI-Subscription: pro" \
  -F "file=@./document.pdf" \
  -F "tone=business" \
  -F "depth=standard" \
  -F "industry=ecommerce" \
  -F "scale=medium"

RapidAPI Listing Tips

A few things I learned setting up the provider listing:

Use OpenAPI import. Write a full openapi.yaml spec and import it — this populates all endpoint documentation automatically rather than configuring everything manually field by field.

Feature toggles matter. The monetisation section lets you toggle which features appear on each plan tier in the pricing table. Setting this up properly makes the pricing page significantly more convincing because subscribers can see exactly what they get at each level.

Proxy secret != API key. These are two different things. The API key is what subscribers use to identify themselves. The proxy secret is what RapidAPI adds to every request to prove it came through their gateway. Your server validates the proxy secret, not the API key.

Test before going public. RapidAPI's built-in testing tool can be unreliable. Test using curl against your production URL with the real proxy secret before making the API public.

Pricing

Pricing an API is harder than pricing SaaS because every request has a real cost. OpenAI API calls are not free, so the pricing needs to cover costs at scale while staying competitive.

Plan	Price	Requests/Day	Key Features
FREE	$0/mo	20	Parse endpoint only
PRO	$9.99/mo	500	Full AI pipeline, brief depth
MEGA	$29.99/mo	2,000	Standard + detailed depth
ULTRA	$79.99/mo	10,000	Focus + goal params, priority processing

The FREE tier exists purely to get developers into the funnel. Let them test the parse endpoint, see the response quality, understand the API structure — then upgrade when they want the AI pipeline.

What I'd Do Differently

Prompt engineering earlier. Getting consistent structured JSON output needed more iteration than expected. Starting with the prompt structure before writing any route handlers would have saved time.

Structured logging from day one. Vercel's function logs are fine for debugging but structured request logging with plan tier, processing time and token usage per request would make cost optimisation much easier as volume grows.

OpenAPI spec first. Writing the OpenAPI spec before building the API forces you to think about request/response structure upfront. I wrote it after, which meant going back to adjust a few things.

What's Next

Monitor usage patterns to validate pricing tiers
Add PowerPoint (.pptx) and HTML file support
Build a simple web UI on top of the API for non-developers
Set up structured logging and cost dashboards

Final Thoughts

The whole thing — API, deployment, testing, RapidAPI listing — took under a week of focused work. The hardest parts were prompt engineering for consistent structured output and getting the Vercel serverless deployment working correctly with file uploads.

If you're thinking about building an API product, the RapidAPI marketplace is a genuinely good distribution channel. The tooling is mature, the developer audience is large and the monetisation infrastructure is all handled for you.

The full API is live on RapidAPI now. If you're building something that needs document processing or AI summarisation, give it a try.

Built with Node.js, Express, OpenAI GPT-4o and Vercel. Available on RapidAPI across four pricing tiers starting at free.

How I went from "wouldn't it be cool if..." to a production API serving 195 languages with AI-powered emotional intelligence

SENZEN — Tue, 17 Feb 2026 14:40:24 +0000

The "Aha!" Moment

Picture this: You're running a SaaS company. A customer emails you in Spanish, clearly frustrated. Your support team scrambles to:

Copy-paste into Google Translate
Read the translation
Guess if they're angry or just asking a question
Craft a response
Translate it back to Spanish
Hope it sounds natural

This takes 10-15 minutes per ticket.

What if an API could do all of this in 2 seconds?

That's what I built. And this is the story of my trials and tribulations.

What I Actually Built

Y TU API does three things that no other translation API does together:

🌍 Translation (The Easy Part)

195+ languages
Powered by Google Translate
~500ms response time
95%+ confidence scores

🎭 Tone Analysis (The Hard Part)

Using OpenAI GPT-4, it detects:

Emotion: positive, negative, neutral, mixed
Urgency: low, medium, high
Intent: question, complaint, request, feedback
Cultural context: Western direct vs Asian indirect communication styles
Formality score: 1-10 scale

💬 Response Generation (The Magic Part)

Generates contextually-appropriate responses in 7 different tones:

Professional, casual, friendly, formal
Empathetic, concise, creative

All wrapped in a RESTful API, live on RapidAPI.

The Tech Stack (And Why I Chose Each Piece)

Backend:     Node.js + Express + TypeScript
Database:    MongoDB Atlas
AI:          OpenAI GPT-4o-mini
Translation: Google Translate API
Deployment:  Vercel (serverless)
Auth:        Custom API key system
Marketplace: RapidAPI

Why Serverless?

I wanted zero devops. No servers to manage, no scaling headaches, no 3am wake-up calls.

The dream: Write code, git push, done.

The reality: Vercel's free tier has a 10-second execution limit.

Spoiler: This nearly killed the project.

Day 1: "This Will Be Easy"

Narrator: It was not easy.

Hour 1-3: Project Setup

Started with the typical setup dance:

npm init -y
npm install express typescript mongoose
# ... 47 more packages

Created the basic structure:

src/
├── routes/        # API endpoints
├── controllers/   # Business logic
├── middleware/    # Auth, rate limiting
├── models/        # MongoDB schemas
├── services/      # External API calls
└── utils/         # Helpers

Lesson 1: TypeScript setup takes longer than you think. Always does.

Hour 4-8: Building the Core Translation Endpoint

The translation endpoint seemed straightforward:

// What I thought it would be:
const translated = await googleTranslate(text, targetLang);
return { translatedText: translated };

// What it actually became:
async translateText(req: Request, res: Response) {
  // Input validation
  const errors = validationResult(req);
  if (!errors.isEmpty()) {
    return res.status(400).json({ errors });
  }

  // Rate limiting check
  const rateLimit = await checkRateLimit(req.user);
  if (rateLimit.exceeded) {
    return res.status(429).json({ error: 'Rate limit exceeded' });
  }

  // Language code validation
  if (!isValidLanguageCode(targetLanguage)) {
    return res.status(400).json({ error: 'Invalid language' });
  }

  // Actual translation
  try {
    const result = await googleTranslateService.translate(
      text, 
      targetLanguage,
      sourceLanguage
    );

    // Usage tracking
    await trackUsage(req.user, 'translation');

    // Return with metadata
    return sendSuccess(res, {
      originalText: text,
      translatedText: result.translatedText,
      confidence: result.confidence,
      sourceLanguage: result.detectedSourceLanguage,
      timestamp: new Date().toISOString()
    });
  } catch (error) {
    logger.error('Translation failed', error);
    return res.status(500).json({ error: 'Translation failed' });
  }
}

Lesson 2: The 80/20 rule is real. 20% of the code is the feature, 80% is error handling, validation, and logging.

Hour 9-12: The MongoDB Nightmare

"Let's add a database!" - Famous last words

MongoDB in serverless environments is... special.

The Problem:

// This works locally
await mongoose.connect(MONGODB_URI);
const apiKey = await ApiKeyModel.findOne({ key });

// In production on Vercel:
// Error: Operation `api_keys.find()` buffering timed out after 10000ms

Mongoose tries to be helpful by "buffering" operations until connected. In serverless, this means every request tries to connect, queries buffer, timeouts happen, chaos ensues.

The Solution:

// Call connect() explicitly BEFORE every database operation
export class Database {
  async connect() {
    // Check if already connected
    if (mongoose.connection.readyState === 1) {
      return; // Skip if connected
    }

    if (mongoose.connection.readyState === 2) {
      // Wait if connecting
      await new Promise(resolve => {
        mongoose.connection.once('connected', resolve);
      });
      return;
    }

    // Actually connect
    await mongoose.connect(process.env.MONGODB_URI, {
      serverSelectionTimeoutMS: 5000,
      socketTimeoutMS: 45000,
    });
  }
}

// Then before EVERY query:
await database.connect();
const apiKey = await ApiKeyModel.findOne({ key });

Lesson 3: Serverless means "stateless." Treat every request like it's the first request ever.

Day 2: "AI Will Save Me"

Narrator: AI tried to kill the project

Hour 13-18: Adding OpenAI for Tone Analysis

The tone analysis endpoint was supposed to be the "cool" feature. And it was!

Until I checked the response times.

First attempt:

const analysis = await openai.chat.completions.create({
  model: "gpt-4",
  messages: [
    {
      role: "system",
      content: "You are an expert at analyzing human communication..."
    },
    {
      role: "user", 
      content: `Analyze this: "${text}"`
    }
  ]
});

Response time: 25-30 seconds

Vercel timeout: 10 seconds

My reaction: 💀

The Fix:

Switched to gpt-4o-mini:

Response time: ~5 seconds (acceptable!)
Cost: 60% cheaper
Quality: Actually better for this use case (less verbose)

const analysis = await openai.chat.completions.create({
  model: "gpt-4o-mini",
  messages: [...],
  temperature: 0.3, // Lower = more consistent
  max_tokens: 500   // Limit response length
});

Lesson 4: The latest/greatest model isn't always the right model. Sometimes smaller and faster wins.

Hour 19-24: The Response Generation Feature

By this point, I was in deep. Too deep to quit.

Response generation took everything I learned and made it harder:

Requirements:

Generate multiple response options
Score them by quality
Return the best one + alternatives
Do it in under 10 seconds
Support 7 different tones

My approach:

async generateResponse(originalText: string, tone: string, context: string) {
  // Generate 5 candidate responses
  const candidates = await Promise.all([
    this.generateSingleResponse(originalText, tone, context, 0.7),
    this.generateSingleResponse(originalText, tone, context, 0.8),
    this.generateSingleResponse(originalText, tone, context, 0.6),
    this.generateSingleResponse(originalText, tone, context, 0.9),
    this.generateSingleResponse(originalText, tone, context, 0.5),
  ]);

  // Score each candidate
  const scored = candidates.map(c => ({
    text: c,
    score: this.scoreResponse(c, originalText, tone)
  }));

  // Sort by score
  scored.sort((a, b) => b.score - a.score);

  return {
    response: scored[0].text,
    score: scored[0].score,
    alternatives: scored.slice(1, 3) // Return top 3
  };
}

Response time: 12-16 seconds

Vercel's response: 💥 TIMEOUT

My response: 😭

The "Process" Endpoint That Wasn't

I had this grand vision: One endpoint to rule them all!

POST /process
{
  "text": "¡Estoy muy enojado!",
  "targetLanguage": "en",
  "options": {
    "translate": true,
    "analyzeTone": true,
    "generateResponse": true
  }
}

Timeline:

Translation: ~0.5s
Tone analysis: ~5s
Response generation: ~15s
Total: ~20 seconds

Vercel free tier limit: 10 seconds

Math doesn't lie.

The Decision:

Ship it anyway, but document the limitation clearly:

Note: The /process endpoint may timeout when all three operations are enabled on Vercel's free tier. Recommended approach: Call /translate, /analyze-tone, and /generate-response separately for full control.

Lesson 5: Perfect is the enemy of shipped. Document limitations and move on.

Day 3: Authentication difficulties

Hour 25-30: Building the API Key System

Needed a system that could:

Generate secure API keys
Track usage per key
Enforce rate limits
Support multiple tiers (FREE, PRO, ULTRA, MEGA)
Work with RapidAPI's proxy

The key generation:

function generateApiKey(): string {
  const prefix = 'ytu_'; // "Y Tu" branding
  const randomBytes = crypto.randomBytes(32);
  const base64 = randomBytes.toString('base64')
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=/g, '');

  return `${prefix}${base64}`;
}

// Example: ytu_u-6_r9eYPTsWMKf_SHBtHJUuY6pvorELgIimfJxCB_M

The rate limiter:

async checkRateLimit(apiKey: string): Promise<RateLimitResult> {
  const key = await ApiKeyModel.findOne({ key: apiKey });

  // Get today's usage
  const today = new Date().toISOString().split('T')[0];
  const usage = await UsageModel.countDocuments({
    apiKey: key._id,
    date: today
  });

  // Check against tier limit
  const limits = {
    FREE: 100,
    PRO: 10000,
    ULTRA: 20000,
    MEGA: 100000
  };

  const limit = limits[key.tier];
  const remaining = Math.max(0, limit - usage);

  return {
    limit,
    remaining,
    exceeded: remaining === 0
  };
}

Lesson 6: Rate limiting is not optional. Users will abuse any API without limits.

Day 4-5: The RapidAPI Integration Saga

Where everything that could go wrong, did

Attempt 1: Testing in RapidAPI's Interface

RapidAPI has a built-in testing interface. Should be simple, right?

What I expected:

Upload OpenAPI spec
Test endpoints
Ship it

What actually happened:

Uploaded OpenAPI spec ✅
Testing interface doesn't work ❌
Error: "Invalid API key" ❌
Error: "X-RapidAPI-Host missing" ❌
Headers not populating ❌
Created test app ❌
Still doesn't work ❌

After 6 hours of debugging, I realized: RapidAPI's testing UI is just buggy.

The Solution:

Test the actual gateway URL directly:

$headers = @{
    "X-RapidAPI-Key" = "your-rapidapi-key"
    "X-RapidAPI-Host" = "y-tu-api.p.rapidapi.com"
    "Content-Type" = "application/json"
}

Invoke-RestMethod -Uri "https://y-tu-api.p.rapidapi.com/translate" `
  -Method Post `
  -Headers $headers `
  -Body '{"text":"Hello","targetLanguage":"es"}'

Result:

{
  "success": true,
  "data": {
    "translatedText": "Hola",
    "confidence": 0.95
  }
}

It worked! 🎉

Lesson 7: When the UI is broken, go around it. Test with curl/PowerShell/Postman.

The Pricing Dilemma

How do you price something you built in a weekend?

My thought process:

Too cheap:

Attracts tire-kickers
Unsustainable if it actually works
Signals low quality

Too expensive:

Nobody will try it
No feedback loop
Wasted effort

The tiers I chose:

Tier	Price	Requests/Day	Logic
FREE	$0	100	Hook them with value
PRO	$49/mo	10,000	Sweet spot for small businesses
ULTRA	$99/mo	20,000	For growing companies
MEGA	$149/mo	100,000	Enterprise-lite

Why these numbers?

FREE: Big enough to be useful (100/day = 3,000/month), small enough to make them want more
PRO at $49: Psychologically under $50, covers all my costs at scale
ULTRA at $99: Double the capacity, not quite double the price (less value = pushes to MEGA)
MEGA at $149: Best value per request ($0.05 per 1K vs $0.16 for PRO)

Lesson 8: Pricing is psychology, not math. Make the tier you want people to choose the obvious "best value."

The Documentation Marathon

At this point, I had a working API. But would anyone actually use it?

The README Nobody Reads (But Everyone Judges)

Spent 4 hours writing a comprehensive README:

✅ What the API does (in plain English)
✅ Real-world use cases with examples
✅ Code snippets in multiple languages
✅ Step-by-step integration guides
✅ Troubleshooting section
✅ ROI calculator (show them the money!)
✅ Pricing comparison table
✅ Architecture diagrams

The secret: Write docs as if explaining to your non-technical friend. If they get it, developers will too.

The OpenAPI Spec issue

OpenAPI specs are supposed to be easy with tools like Swagger.

Reality: Manually writing 500+ lines of YAML because my endpoints were too custom.

The pain points:

Tone validation mismatch:
- OpenAPI said: empathetic, concise
- Code accepted: professional, casual, friendly, formal, creative
- Result: Users got validation errors
- Fix: Manually sync'd everything
Security schemes:
- Needed to support both X-API-Key and RapidAPI's headers
- Required two separate security schemes
- Took 3 attempts to get right
Example responses:
- Had to manually craft realistic examples
- Spent 2 hours making them look professional

Lesson 9: Your docs are your marketing. Invest the time.

Production Testing: When Reality Hits

Test 1: Direct API (✅ Perfect)

curl -X POST https://y-tu-api.vercel.app/api/v1/translate \
  -H "X-API-Key: ytu_..." \
  -d '{"text":"Hello","targetLanguage":"es"}'

# Response: 500ms, perfect!

Test 2: Tone Analysis (✅ Good Enough)

curl -X POST https://y-tu-api.vercel.app/api/v1/analyze-tone \
  -H "X-API-Key: ytu_..." \
  -d '{"text":"I am furious!","language":"en"}'

# Response: 5 seconds
# Result: Emotion: "negative", Urgency: "high" ✅

Test 3: Response Generation (⚠️ Close Call)

curl -X POST https://y-tu-api.vercel.app/api/v1/generate-response \
  -H "X-API-Key: ytu_..." \
  -d '{"originalText":"Where is my order?","tone":"professional"}'

# Response: 15 seconds
# Result: Generated 3 alternatives, scored properly ✅
# BUT: Vercel threw warnings about approaching timeout

Test 4: The Full Pipeline (❌ Timeout)

curl -X POST https://y-tu-api.vercel.app/api/v1/process \
  -H "X-API-Key: ytu_..." \
  -d '{
    "text":"¡Estoy enojado!",
    "targetLanguage":"en",
    "options":{"translate":true,"analyzeTone":true,"generateResponse":true}
  }'

# Response: ERROR - Function execution timeout

Decision time: Ship it anyway with documented limitations, or delay launch to fix?

I shipped it. Here's why:

3 out of 4 endpoints work perfectly
Users can chain the working endpoints
I can fix it later with Vercel Pro ($20/mo)
Better to have real users than perfect features

Lesson 10: Ship the 80% solution. Perfect is a myth.

Launch Day: Making It Public

The Pre-Launch Checklist

✅ Remove test API key from Gateway settings

✅ Verify all endpoints work

✅ Double-check pricing is correct

✅ README is comprehensive

✅ OpenAPI spec matches actual code

✅ Rate limiting tested

✅ Error messages are helpful

✅ Monitoring set up (basic)

One last test through RapidAPI's actual gateway:

# Created RapidAPI app to get real API key
# Subscribed to my own API (FREE tier)
# Tested through gateway:

Invoke-RestMethod -Uri "https://y-tu-api.p.rapidapi.com/translate" `
  -Headers @{
    "X-RapidAPI-Key" = "my-rapidapi-key"
    "X-RapidAPI-Host" = "y-tu-api.p.rapidapi.com"
  } `
  -Body '{"text":"Final test!","targetLanguage":"es"}'

# ✅ SUCCESS!
# Response: "¡Prueba final!"

Clicked "Make Public"

My API was live. 🚀

What I Learned

Technical Lessons

Serverless is amazing until it's not
- Perfect for 90% of use cases
- That 10% will hurt
- Plan for timeouts from day 1
MongoDB + Serverless = Effort
- Explicit connection management
- Connection pooling
- Timeout configuration
- Worth it for the flexibility
AI APIs are expensive and slow
- GPT-4: Great quality, terrible speed/cost
- GPT-4o-mini: Sweet spot for production
- Always have a budget alert
Rate limiting is not optional
- Someone WILL abuse your API
- Implement before launch
- Make it per-user, not global
Testing through proxies is ridiculously difficult
- RapidAPI's UI is buggy
- Always test with actual HTTP clients
- Document your testing process

Business Lessons

Documentation > Features
- People can't use what they don't understand
- Good docs = less support time
- Examples are worth 1000 words
Ship imperfect products
- Perfect is the enemy of done
- Real users > perfect features
- You can always iterate
Pricing is psychology
- Make one tier obviously the "best value"
- FREE tier hooks them
- Price high enough to cover costs + profit
Integration is harder than building
- Your API is 50% of the work
- Integration with marketplaces is the other 50%
- Budget time for debugging proxies
Limitations can be features
- "/process endpoint requires separate calls"
- Becomes: "Full control with granular endpoints"
- Spin it right

Current Status

After 1 week live:

API is searchable on RapidAPI ✅
All core endpoints working ✅
Rate limiting enforced ✅
Zero downtime so far ✅
Documentation complete ✅

Current costs: $0-50/month

Break-even: 1-2 paying customers

Profit margin: 70-80%

What's Next

Immediate (Week 1-4):

[ ] Add error monitoring (Sentry)
[ ] Create usage analytics dashboard
[ ] Build Python SDK
[ ] Add more code examples
[ ] Set up status page

When profitable ($500/mo):

[ ] Upgrade to Vercel Pro (fix /process timeout)
[ ] Add webhook support
[ ] Build batch processing endpoint
[ ] Add caching layer (Redis)

Long-term ($5K/mo):

[ ] Custom model training
[ ] White-label options
[ ] Regional deployments
[ ] Enterprise features

Try It Yourself

Search "Y TU Translation" on RapidAPI

Free tier includes:

100 requests/day
All endpoints
Full documentation
No credit card required

Want to build something similar?

The full stack:

Node.js + TypeScript + Express
MongoDB Atlas (free tier)
OpenAI API
Google Translate API
Vercel (serverless)
RapidAPI (marketplace)

Questions? Ask in the comments!

The Real Numbers

Total development time: ~40 hours over 5 days

Lines of code: ~3,000

API endpoints: 12

Languages supported: 195

Cost to build: $0 (free tiers everywhere)

Cost to run: $0-50/month

Was it worth it? Ask me in 3 months. 😅

Final Thoughts

Building an API isn't hard.

Building a production-ready API that:

Handles errors gracefully
Scales automatically
Integrates with marketplaces
Has proper auth and rate limiting
Is well-documented
Actually solves a real problem

That's hard.

But it's also incredibly rewarding.

If you're thinking about building an API, my advice:

Start with a real problem - Don't build "another translation API". Build "translation with emotional intelligence for customer service."
Pick boring tech - Node.js, MongoDB, Vercel. Not exciting, but reliable.
Ship fast - Don't wait for perfect. Ship at 80% and iterate.
Document everything - Your docs are your marketing.
Charge money - Free APIs die. Paid APIs get improved.

Remember

The gap between you and the person you hope to become and what you aim to achieve is a leap of faith.

Now go build something!

SENZEN

Building APIs for global communication

Contact: stainfluence@gmail.com

Try Y TU API: Search "Y TU Translation" on RapidAPI

Tags: #api #ai #nodejs #typescript #mongodb #openai #rapidapi #startup #buildinpublic