Let’s start with a scenario that should sound familiar.

You’ve shipped an AI agent inside your B2B SaaS product. It summarizes meetings, drafts content, creates notes in Notion, and manages knowledge workflows — all on behalf of your users. It’s fast. It’s delightful. Your customers love it.

Now ask yourself: when your agent creates a Notion page on behalf of John from the XCorp account — does Notion’s API actually know it’s John? Does it know it’s XCorp? Does it know the agent is only supposed to write to specific workspaces and not read everything John has ever written?

If your answer involves a shared API key, a service account with broad permissions, or a vague “we trust the agent to behave” — this article is for you.

How Most Teams Handle Agent Auth Today (And Why It’s a Liability)

Most teams building customer-facing AI agents have stitched together authentication in one of three ways. They all work. They all have problems that don’t show up until something goes very wrong.

Pattern 1: The Hardcoded API Key

This is the fastest path from prototype to production, which is exactly why it’s so common. Your agent needs to create Notion pages, read databases, manage workspaces — you grab a Notion integration token, stuff it in an environment variable, and ship it.

The token is tied to a single Notion integration. It has whatever permissions that integration has. It has no concept of which user triggered the action. It has no concept of which org the request is for. It will keep working indefinitely, or until someone revokes the integration and everything breaks.

A hardcoded API key is like giving your delivery driver a master key to every apartment in the building because you don’t want to bother them with individual unit codes.

There’s no revocation per user. There’s no scoping per tenant. And if someone asks “which agent action ran on behalf of John from Sales at XCorp last Tuesday?” the answer is a spreadsheet of server logs and a prayer.

Pattern 2: The Shared Service Account

A step up from a raw API key, and somehow worse in practice. A single Notion integration with broad workspace access handles every agent action, for every user, for every org.

The downstream system sees requests from one identity. You’ve lost all user context the moment the agent touches an external tool. If you’re in a multi-tenant environment — and if you’re building B2B SaaS, you are — this means your agent is running as a single undifferentiated identity across every customer organization you have.

That’s not multi-tenancy. That’s a liability waiting to manifest.

Pattern 3: The “Trust the Agent” Architecture

This one is the most optimistic. You trust the application layer to enforce access controls. The agent figures out from context which user it’s acting for, and you trust it won’t do anything it shouldn’t.

This works precisely until it doesn’t. An edge case in the LLM’s context handling. A subtly malformed request. A prompt injection attack that convinces the agent it’s acting for a different user. You have no cryptographic guarantee of identity at the infrastructure level — just vibes and hope.

The Multi-Tenancy Time Bomb

Here’s the failure mode that keeps B2B SaaS engineering leads up at night. Not a dramatic breach. A quiet data bleed.

Imagine your AI agent is helping a content manager at TechCorp. The agent creates a Notion page and starts writing to a database. Somewhere in the permission model, there’s a misconfiguration, the agent’s shared integration token has access to a Notion workspace that doesn’t properly filter by organization. Because the agent doesn’t carry a user-scoped token, Notion’s API has no way to enforce tenant boundaries at the credential level.

The agent writes data. Some of it might land in the wrong workspace.

This isn’t a hypothetical. It’s a class of bugs that shows up in any system where authorization decisions are made at the application layer rather than the infrastructure layer. Agents make it worse because they operate autonomously, at speed, across many tenants, often without a human in the loop to notice when something looks off.

Tenant isolation isn’t a nice-to-have in B2B SaaS. It’s the whole point. Every enterprise customer assumes it’s airtight. If your agent auth model relies on application-level trust rather than cryptographically verified, tenant-scoped tokens, you have a gap.

What Delegated, Scoped, Auditable Agent Auth Actually Looks Like

The Identity Problem, Stated Cleanly

When a human logs into your app, authentication is relatively straightforward. They prove who they are, you issue a session token tied to their identity, and every downstream request carries that identity as a cryptographic claim. The system knows who is asking, what they’re allowed to see, and can log it against their account.

An AI agent acting on a user’s behalf introduces a new actor into this chain. The agent isn’t the user. It’s not your service. It’s something operating in between, and classical auth models weren’t designed for it.

What you actually need is delegated authorization: the user explicitly grants the agent permission to act on their behalf, the agent receives a token that carries the user’s identity and org context, and that token is scoped to exactly the actions the user authorized. The downstream system doesn’t trust the agent, it trusts the token, which was issued through a consent flow the user approved.

The question isn’t “does the agent have permission to do this?” It’s “did this specific user, in this specific org, authorize this agent to do exactly this?”

What Delegated Auth Actually Looks Like in Practice

The pattern is OAuth, specifically, OAuth flows adapted for the agent context. Here’s the mental model:

• A user interacts with your product and authorizes your agent to access external tools on their behalf.
• Your system initiates an OAuth flow that ties the resulting token to that specific user, in their specific org, with a specific set of scopes.
• The agent receives this token and uses it when making downstream API calls. The token carries the user’s identity. The downstream system can verify it cryptographically.
• If the user revokes consent, the token is immediately invalidated. The agent loses access at the exact moment authorization is withdrawn.

This is fundamentally different from a service account. The agent doesn’t accumulate permissions over time. It has exactly what this user authorized for exactly this session, and nothing more.

Least Privilege, Per Tenant, Per Action

Token scoping is the mechanism that makes least privilege real at the agent layer. Instead of issuing a token that says “this agent can do anything this user can do,” you issue a token that says “this agent can create Notion pages in approved workspaces, on behalf of this user, in this org, until revoked.”

This matters in practice for a few reasons. Agents make mistakes. LLMs hallucinate. Prompt injection is a real attack vector. A scoped token acts as a hard boundary, even if the agent logic goes sideways, the token can’t be used to take actions it was never authorized to take. It’s defense in depth at the identity layer.

In a multi-tenant context, token scoping also means every token is inherently org-scoped. There’s no way for a token issued on behalf of John at XCorp to accidentally write into TechCorp’s Notion workspace. The tenant boundary is baked into the credential, not enforced by application logic you might forget to write.

What a Token Should Actually Carry

A properly constructed agent token is typically a short-lived OAuth access token backed by a JWT. Here’s what the payload should look like:

{
  "sub": "user_01HXYZ123",          // stable user identifier — not email, not name
  "org_id": "org_xcorp_456",        // tenant context, baked in at issuance
  "scope": "notion:pages:write notion:workspace:read-specific",
  "agent_id": "agent_content_mgr",  // which agent received this delegation
  "auth_event_id": "authz_789",     // reference to the consent event that produced this token
  "iat": 1714000000,
  "exp": 1714003600                 // 1 hour; vault handles refresh, not your app
}

Each field is doing specific work.

sub makes every downstream action attributable to an individual — not a service account, not a role.

org_id encodes the tenant boundary in the credential itself rather than relying on application logic to filter correctly.

scope constrains what the agent can do at the infrastructure layer, so even a misbehaving agent can't exceed what the user approved.

auth_event_id is the key to clean revocation: revoke that authorization event, and every token derived from it is immediately invalid, regardless of whether it's technically unexpired. The vault tracks this mapping — your application doesn't have to.

The short exp limits blast radius if a token leaks. The vault handles silent refresh — your application always gets a live token via get_connected_account, never needs to detect expiry or trigger a refresh cycle itself.

Revocation

This one gets underweighted in most agent auth discussions. With a hardcoded API key or a service account, revocation is a blunt instrument — you revoke the key, everything breaks, you scramble to reissue and reconfigure. With delegated tokens tied to per-user authorization events, revocation is precise: the user withdraws consent, that token is invalidated, the agent loses access for exactly that user and no one else. Nothing else in your system is disrupted.

This is the property that makes enterprise customers comfortable. They want to be able to say “if I change my mind, I can revoke access in one click”. Delegated OAuth gives you that. Service accounts do not.

The Audit Trail You’ll Actually Need

At some point, a customer is going to ask you what your agent did. Maybe it’s a compliance audit. Maybe something went wrong and they’re trying to figure out what happened. Maybe their InfoSec team just wants to see the logs before they renew.

With delegated, scoped auth, answering this question becomes straightforward. Every token carries user identity, org context, and scope. Every action the agent takes is traceable to a specific authorization event — when the user approved it, what they approved, and whether that authorization is still valid.

“What did the agent do on behalf of John from Sales at XCorp last Tuesday?” becomes a query, not an investigation.

Implementing This Pattern

Rolling delegated agent auth from scratch is doable — you’re essentially building an OAuth authorization server with a token vault, per-tenant scoping logic, rotation policies, and audit hooks. Most teams building on top of this pattern reach for an existing implementation rather than owning that infrastructure, especially when it needs to be multi-region, SOC 2 compliant, and available at 99.99%.

The example below uses Scalekit’s Agent Auth, which handles the OAuth flows, token vault, rotation, and audit logging described above. The pattern is identical whether you use Scalekit or build it yourself — the goal is to make the mechanics concrete.

A Python Example: Creating a Notion Page on Behalf of a User

This example walks through a minimal but complete implementation of the full flow: user consent, token issuance, scoped API call, no hardcoded keys.

Set Up Your Environment

Get your API credentials from the Scalekit dashboard at scalekit.com → Developers → Settings → API Credentials, then install the SDK:

pip install scalekit-sdk-python python-dotenv requests

Initialize the client:

import scalekit.client
import os
import requests
from dotenv import load_dotenv

load_dotenv()

scalekit_client = scalekit.client.ScalekitClient(
    client_id=os.getenv("SCALEKIT_CLIENT_ID"),
    client_secret=os.getenv("SCALEKIT_CLIENT_SECRET"),
    env_url=os.getenv("SCALEKIT_ENV_URL"),
)
actions = scalekit_client.actions

Step 1: Authenticate the User

Before the agent can create anything on the user’s behalf, the user needs to authorize access. Call get_authorization_link to generate a Notion OAuth consent URL — Scalekit handles the entire flow from here: getting the token, storing it in the vault, and refreshing it automatically when it expires.

# Generate Notion OAuth consent link for this user
link_response = actions.get_authorization_link(
    connection_name="notion",
    identifier="Sachin"  # Unique identifier for this user in your system
)

print(f"Click this link to authorize Notion: {link_response.link}")
input("Press Enter after completing authorization...")

Note: Make sure the notion connection is set up in your Scalekit dashboard under Agent Actions → Connections → Create Connection. Use Scalekit's built-in credentials for faster development, no need to create your own Notion OAuth app.

The user clicks the link, sees Notion’s standard OAuth consent screen, approves access, and that’s it. They’ve defined what the agent is allowed to do. Everything from here is bounded by that decision.

Step 2: Fetch the OAuth Token

Now that the user has authorized, retrieve a fresh, valid access token. Scalekit keeps it refreshed in the background — you always get a live token without managing refresh cycles yourself.

# Retrieve the connected account to get the current OAuth token
response = actions.get_connected_account(
    connection_name="notion",
    identifier="Sachin"
)
connected_account = response.connected_account

# Extract the access token
tokens = connected_account.authorization_details["oauth_token"]
access_token = tokens["access_token"]

This token is the user’s delegated identity. It’s scoped to exactly what they approved in the Notion consent screen — their workspaces, their pages, nothing else.

Step 3: Create a New Notion Page

Now use the token to call Notion’s API and create a page. Notion’s backend sees this request as the authorized user — their workspace, their permissions, no one else’s.

headers = {
    "Authorization": f"Bearer {access_token}",
    "Content-Type": "application/json",
    "Notion-Version": "2022-06-28",  # Always pin the Notion API version
}

# Find an accessible parent page to create under
search_response = requests.post(
    "https://api.notion.com/v1/search",
    headers=headers,
    json={
        "filter": {"value": "page", "property": "object"},
        "page_size": 1
    }
)
results = search_response.json().get("results", [])

if not results:
    print("❌ No accessible pages found. Make sure the user shared a page with the integration.")
else:
    parent_page_id = results[0]["id"]

    # Create a new page under the found parent
    create_response = requests.post(
        "https://api.notion.com/v1/pages",
        headers=headers,
        json={
            "parent": {"page_id": parent_page_id},
            "properties": {
                "title": {
                    "title": [{"text": {"content": "Page Created by AI Agent 🤖"}}]
                }
            },
            "children": [
                {
                    "object": "block",
                    "type": "paragraph",
                    "paragraph": {
                        "rich_text": [
                            {
                                "type": "text",
                                "text": {
                                    "content": "This page was created by an AI agent on behalf of Sachin using Scalekit Agent Auth. The agent had exactly the permissions this user approved — nothing more."
                                }
                            }
                        ]
                    }
                }
            ]
        }
    )

    new_page = create_response.json()
    print(f"\n✅ Notion page created successfully!")
    print(f"Page ID  : {new_page.get('id')}")
    print(f"Page URL : {new_page.get('url')}")
    print(f"Created  : {new_page.get('created_time')}")

Notion’s backend sees this request as the authorized user — their workspaces, their permissions, scoped to exactly what they approved. The agent cannot access private pages, other users’ workspaces, or anything outside the approved scope. That constraint isn’t enforced by application logic — it’s encoded in the credential itself.

No Raw APIs? Use Scalekit’s Built-in Tools

If you’d rather not manage Notion’s API directly, Scalekit ships pre-built connectors for supported services. The same flow using Scalekit’s built-in tools:

import scalekit.client
import os
from dotenv import load_dotenv

load_dotenv()

# Initialize Scalekit client using environment variables
scalekit_client = scalekit.client.ScalekitClient(
    client_id=os.getenv("SCALEKIT_CLIENT_ID"),
    client_secret=os.getenv("SCALEKIT_CLIENT_SECRET"),
    env_url=os.getenv("SCALEKIT_ENV_URL"),
)
actions = scalekit_client.actions

# Generate Notion OAuth consent link for this user
link_response = actions.get_authorization_link(
    connection_name="notion",
    identifier="Sachin"
)
print(f"Click this link to authorize Notion: {link_response.link}")
input("Press Enter after completing authorization...")

# Step 1: Use Scalekit's built-in tool to search for existing Notion pages
# No raw API call needed — Scalekit handles auth injection internally
search_response = actions.execute_tool(   # <-- Scalekit tool call
    tool_name="notion_page_search",       # <-- built-in Notion tool
    identifier="Sachin",                  # <-- user identity passed here
    tool_input={
        "page_size": 3,
        "sort_direction": "descending",
        "sort_timestamp": "last_edited_time"
    }
)

# Response data lives in search_response.data — no json.loads() needed
results = search_response.data.get("results", [])
print(f"Pages found: {len(results)}")

if not results:
    print("❌ No pages found. Please share a page on the Notion consent screen.")
else:
    parent_page_id = results[0]["id"]
    print(f"✅ Parent page found: {parent_page_id}")

    # Step 2: Use Scalekit's built-in tool to create a new Notion page
    new_page_response = actions.execute_tool(   # <-- Scalekit tool call
        tool_name="notion_page_create",         # <-- built-in Notion tool
        identifier="Sachin",
        tool_input={
            "parent_page_id": parent_page_id,   # <-- from Step 1 result
            "properties": {
                "title": {
                    "title": [{"text": {"content": "Page Created by AI Agent 🤖"}}]
                }
            },
            "child_blocks": [
                {
                    "object": "block",
                    "type": "paragraph",
                    "paragraph": {
                        "rich_text": [{"type": "text", "text": {
                            "content": "This page was created by an AI agent on behalf of Sachin using Scalekit Agent Auth. The agent had exactly the permissions this user approved — nothing more."
                        }}]
                    }
                }
            ],
            "notion_version": "2022-06-28"
        }
    )

    new_page = new_page_response.data   # <-- response data directly accessible
    print(f"\n✅ Notion page created successfully!")
    print(f"Page ID  : {new_page.get('id')}")
    print(f"Page URL : {new_page.get('url')}")
    print(f"Created  : {new_page.get('created_time')}")

execute_tool handles auth injection internally — Scalekit looks up the connected account for that identifier, retrieves the live token from the vault, and injects it into the request. The response comes back as a Python dict. No token handling, no JSON parsing, no API version management.

Available tools for Notion include notion_page_search, notion_page_create, notion_database_create, notion_database_query, notion_comment_create, and more. Every supported connector has its own tool set — check the full list here.

What Actually Happens When You Run This

No magic, no hand-waving. Here’s exactly what the flow looks like end to end once you run the program:

1. You run the program

Your terminal prints a Scalekit-generated authorization link and waits. The program is paused, nothing happens until you say so.

2. You open the link — Scalekit shows an authorization interface

You follow the link in your browser. Scalekit presents a clean authorization screen that tells you exactly what the agent is asking for — which app (Notion), which permissions, on whose behalf. No fine print. No vague “access to everything.”

You click Allow access.

3. Notion’s OAuth flow completes in the background

Scalekit handles the entire OAuth handshake with Notion — exchanges the auth code for an access token, stores it securely in the token vault, and marks the connected account for identifier="Sachin" as ACTIVE. You don't see any of this. It just works.

4. You come back to the terminal and press Enter

The program resumes, fetches the live token from the vault, and moves on to the Notion API call.

5. The agent creates a page in Notion on your behalf

You access the page URL. A new page is sitting right there, created by the agent, using your delegated identity, with exactly the permissions you approved and nothing more.

The agent acted as you. Notion knew it was you. And you stayed in control the whole time.

Conclusion

Agents are no longer just internal tools, they’re acting on behalf of real users, inside real organizations, touching real data. A hardcoded API key got you to the demo. It won’t get you to production.

The pattern is simple: delegated auth, scoped tokens, full audit trail. Scalekit gives you the infrastructure to do it right, without rebuilding your entire auth stack.

Your users are trusting your agent with their data. Make sure it’s worthy of that trust.

That’s all for now.

Keep Coding✌️✌️.

Okay so I need to start this with some honesty.

I have started, and abandoned, more side projects than I can count. Not because I ran out of ideas, not because I got bored. Every single time, it was the same thing. The backend.

I would get an idea, get excited, open my editor, start building the frontend, and everything would feel great for maybe an hour. Then I’d realize I need users to log in. Which means I need auth. Which means I need a database. Which means I need to figure out hosting, connection strings, environment variables, migrations, and suddenly I’m reading a Stack Overflow answer from 2019 wondering if it’s still relevant.

The idea doesn’t die dramatically. It just slowly suffocates under the weight of infrastructure.

And look, I know some of you reading this are backend engineers who genuinely enjoy this stuff. Good for you, seriously. But for the rest of us, people who just want to build things that work, the backend has always been this annoying tax you pay before you’re allowed to do the thing you actually wanted to do.

So when I heard about InsForge and how it’s designed specifically for AI coding agents to handle the backend automatically, I was curious but skeptical. I’ve been burned by “it just works” promises before. But I tried it anyway, built a real app with it, and here’s everything that happened — the good parts, the broken parts, all of it.

Let’s Talk About Why Backend Development Is Actually Hard

I don’t want to just skim past this part because I think it’s important. When people say “the backend is hard,” they’re usually vague about what specifically is hard. Let me be specific.

Problem 1: Decision Paralysis Before You’ve Written One Line

You decide you need a database. Cool. Now which one?

Postgres is the safe, serious choice. MySQL is what a lot of tutorials use. MongoDB is document-based and people swear by it for flexibility. SQLite is great for local dev but gets complicated in production. There’s also PlanetScale, Turso, Neon, CockroachDB — all Postgres-compatible but with different tradeoffs around scaling and pricing.

You spend 45 minutes reading comparison articles. Each one recommends something different. You pick Postgres because it seems the most “serious.” Now where do you host it? Railway? Supabase? Render? AWS RDS? Neon? Each has a free tier with different limitations. Each has slightly different connection string formats. You pick one.

You haven’t written a single line of application code yet. You’ve been at this for an hour.

Problem 2: Authentication Is a Trap

Authentication looks simple from the outside. Users log in. Users log out. How hard can it be?

Very hard, as it turns out.

First, you decide on an approach. Sessions or JWT tokens? Sessions are simpler to reason about but require server-side state. JWT tokens are stateless but then how do you handle logout properly? If you just let the token expire, a logged-out user can still use that token until it expires. You need a token blacklist, which requires more database infrastructure.

Okay, let’s say you pick sessions. Now you need to hash passwords. bcrypt? argon2? You use bcrypt because most tutorials do. You implement registration, you implement login, it works locally.

Now you add email verification. You need to send emails, which means you need an email provider such as Sendgrid, Resend, Postmark, Amazon SES. You pick one, you set up API keys, you write the email templates, you implement the verification token logic, you store tokens in the database with expiry times, you write the endpoint that handles the verification click.

Registration now works end to end. You test login. It works. You test logout. It works. You test “what happens if someone tries to log in with an unverified email” and your app throws an uncaught exception and crashes.

You fix it. You add Google OAuth because users expect it. OAuth has its own entire complexity surface like redirect URIs, client IDs, callback handling, merging OAuth accounts with existing email accounts if the same email was used for both.

You’ve been working for two days and you haven’t built a single feature of your actual app.

Problem 3: File Storage Is Deceptively Annoying

Your app needs to let users upload a profile photo. Or attach an image to a post. Or upload a document. Seems simple.

You need cloud storage. S3 is the standard. You create an AWS account, create a bucket, figure out the IAM permissions system (which has its own learning curve), generate access keys, configure CORS so your frontend can talk to S3, implement presigned URLs so you’re not exposing your credentials to the client, write the upload logic, write the delete logic, handle errors when uploads fail.

Alternatively you use Supabase Storage or Cloudflare R2, which are simpler, but you still need to understand the permission model, configure buckets, write the integration code.

After all that, file uploads work. But now when you test on a slow connection, you notice there’s no progress indicator, and if the upload fails halfway through, the user gets no feedback. You go back and implement that too.

Problem 4: Local Works, Production Doesn’t

The worst moment in any project. You’ve built everything locally. It all works. You deploy it to Vercel, or Railway, or wherever and something is broken.

The database connection string is different in production. The environment variables aren’t loading correctly. The file upload URLs are using localhost. CORS is blocking requests because you forgot to add your production domain to the allowed origins. Email verification links are pointing to localhost.

You spend three hours debugging things that have nothing to do with your actual application and everything to do with the gap between your local environment and production.

Problem 5: Keeping Everything in Sync

As your app grows, you add a new feature that requires a new database column. Now you need to write a migration. But your production database already has data in it, so you need to write the migration carefully so it doesn’t break existing records. You test it locally, it works. You run it in production, something unexpected happens.

Or you change your authentication logic and now sessions from before the change are invalid, and users are getting logged out randomly, and you don’t fully understand why until you spend an afternoon tracing through the session handling code.

None of this is insurmountable. Experienced backend developers handle all of this routinely. But if you’re someone who just wants to build an app, if backend infrastructure is a means to an end rather than the thing itself then this is a brutal amount of overhead before you get to do anything interesting.

Enter AI Coding Agents — And Their Limitations

AI coding agents like Cursor and Claude Code have helped a lot with this. The experience of describing what you want and watching code appear is genuinely remarkable. For frontend work especially — React components, UI logic, state management — these tools are fantastic.

But they struggle with backend setup in a specific, frustrating way.

The problem is that AI agents are working from training data, and backend infrastructure tools update constantly. Supabase changes their SDK. AWS updates their SDK. Authentication libraries deprecate methods. The agent writes code based on what it knows, which might be six months out of date, and then you spend an hour debugging why the auth isn’t working only to realize the agent used a method that was deprecated in the last SDK update.

Beyond that, setting up backend services involves a lot of clicking through dashboards, configuring settings in UIs, copying values from one place to another. AI agents can’t do that — they can only write code. So the setup process still has a significant manual component, and the seams between “what the agent wrote” and “what you set up manually” are often where bugs hide.

What would actually solve this is a backend platform that’s built from the ground up for AI agents. Not a platform that has an AI feature bolted on, but one where the AI agent is the primary user — where every capability is exposed as a tool the agent can call directly, with documentation structured for machine consumption rather than human reading.

That’s InsForge.

What InsForge Actually Is

InsForge calls itself “the backend for agentic development”. The key word there is agentic, it’s designed specifically to be used by AI coding agents, not human developers clicking through dashboards.

Here’s what you get with every InsForge project:

Postgres Database — A proper relational database, not a toy. Production-grade Postgres, ready immediately when you create a project. The agent can create tables, run queries, manage relationships — all through native MCP tools, not by writing raw SQL and hoping it runs.

Authentication — Full user management including email/password signup, email verification, session management, and OAuth providers including Google. The kind of auth that represents days of work to implement correctly from scratch.

Cloud Storage — File storage for images, documents, anything your app needs to store. No S3 configuration, no IAM policies, no presigned URL boilerplate. The agent can create buckets and upload files through the same tool interface as everything else.

Edge Functions — Serverless backend logic that runs globally. Email sending, webhook handling, scheduled tasks, anything that needs to run server-side without a dedicated server.

Realtime — Live data subscriptions. If you want your app to update automatically when data changes — think collaborative features, live dashboards, notifications, it’s built in.

AI Model Gateway — Built-in access to AI models if your app needs them. No separate API keys to manage.

Deployment — Ship your app through InsForge without needing a separate hosting platform.

The reason this matters more than just having a good feature list is the way these features are exposed. Every single capability is available as a native MCP (Model Context Protocol) tool. Your AI agent doesn’t read documentation and write API calls, it directly invokes tools. Create a database table. Set up email auth. Create a storage bucket. These are direct function calls the agent makes against InsForge’s infrastructure.

The practical result of this is measurable. According to benchmarks run at mcpmark.ai, AI agents using InsForge are 1.6x faster than with Supabase, use 30% fewer tokens, and achieve nearly double the accuracy, means the agent gets things right the first time significantly more often, which means fewer debugging loops, which means you actually ship things.

Setting Up InsForge With Cursor: Every Step

Let me walk through the setup in detail, because it’s actually much simpler than I expected and I want you to see exactly what it looks like.

Step 1: Create Your Account and Project

Go to insforge.dev and sign up. Once you’re in, you’ll see your organization dashboard. Click to create a new project and give it a name that reflects what you’re building.

When InsForge creates your project, it’s actually provisioning a real Postgres database, configuring authentication infrastructure, and setting up storage, all in the background while you’re looking at the UI. By the time the loading spinner is done, you have a complete backend environment waiting for you.

Compare this to the alternative: spinning up a Postgres instance on Railway, then going to Supabase for auth, then configuring S3 for storage, then figuring out how to make all three talk to each other. InsForge does that entire setup in about ten seconds.

Step 2: Connect Your Editor

Navigate to the Terminal section in the InsForge dashboard. You’ll see a list of supported editors such as Cursor, Claude Code, GitHub Copilot, Cline, Windsurf, and more.

Click on Cursor. Then click “Add to Cursor”.

Cursor opens, and every field in the MCP configuration is already populated. The server URL, the authentication credentials, the project identifier — all filled in without you doing anything. You just confirm the installation.

If you’re using a different editor like VS Code, Claude Code, anything else, InsForge recommends the extension method instead of the direct MCP approach.

Step 3: Verify the Connection

Once installed, open Cursor and run this prompt:

I'm using InsForge as my backend platform, call InsForge MCP's fetch-docs tool to learn about InsForge instructions.

InsForge will confirm the connection and come back with a setup guide. But here’s the part I didn’t expect — along with the confirmation, it gives you three steps. And those three steps aren’t just “you’re good to go.” They’re actually instructions for setting up InsForge for your frontend as well.

So if you take those three steps and give them back to the agent as a prompt — just paste them in — your frontend will also be wired up to InsForge automatically. No extra configuration, no hunting through docs. Backend and frontend, both connected, from a single setup flow.

Building the App: Everything That Happened

Now for the actual build. I’m going to be honest about the process, including the things that didn’t work perfectly the first time, because I think sanitized tutorials where everything works on the first try are actually misleading and not that helpful.

Writing the Prompt

Before typing anything, I spent a few minutes thinking through what the app needed to do. This is worth doing, a vague prompt produces a vague app, and you’ll waste iteration cycles fixing things that could have been specified upfront.

I decided to build a calories and hydration tracking app called FitTrack. Here’s the exact prompt I used:

Build a lightweight Diet & Hydration Tracker app named "Fittrack" using InsForge as the backend platform with these features:
- User profiles with basic details (age, weight, height, activity level)
- Daily meal tracking with meal type (breakfast, lunch, dinner, snacks) and calories
- Custom food items with calories, macros, and portion size
- Water intake tracking with daily hydration goals
- Quick add buttons for water intake (250ml, 500ml, custom)
- Daily summary showing total calories consumed vs target
- Hydration progress indicator for the day
- History view to track meals and water intake by date
- Notes for each day (cheat day, fasting, workout, etc.)
- Reminders for meals and water intake throughout the day
- Simple analytics showing weekly calorie intake and hydration trends
- Data stored using InsForge database with strict user-specific access control

Authentication:
- User registration using email and verification code (OTP)
- After successful OTP verification, automatically log the user in and create a valid auth session
- Authentication sessions must persist correctly across page refreshes and devices
- Signing out should fully clear the active session without affecting future logins
- Users must be able to sign in again normally after signing out without any auth conflicts

That’s it. No tech stack instructions, no database schema, no API design. Just a description of what the app should do and how auth should behave. InsForge and the agent figure out the rest.

What the Agent Actually Does

After submitting the prompt, the agent doesn’t immediately start writing code. The first thing it does is fetch InsForge’s documentation through the MCP tools. It reads through the available capabilities, understands the tool interfaces, and then it makes a plan.

You can literally watch it think. It outlines what it needs to build, in what order, with what dependencies. Auth first, then database schema, then the pages that depend on those. It’s not just blindly generating code, it’s reasoning about the build sequence.

Then it starts.

Files appear. The project structure fills in. Auth utilities, database helpers, the registration flow, the login page, session handling, the dashboard layout, the meal form, the chart components for analytics. You’re watching an app assemble itself.

When it’s done, it gives you a summary of every table it created, every page it built, what auth configuration is now in place, where the storage bucket was set up. A complete accounting of what exists.

Round One: Auth Flow Was Broken

First thing I did after the initial build was test the auth flow — registration, OTP verification, login. And it broke immediately.

The specific issue: after entering the OTP and verifying the email, users were not being redirected to the dashboard. The verification was completing on InsForge’s side — the user was marked as verified — but the session wasn’t being established correctly on the frontend. So you’d verify, and then just… land back at the login screen. No error, no explanation. Just a blank redirect like nothing happened.

This is the exact kind of auth edge case that’s infuriating to debug manually. The backend did its job. The problem was in how the frontend was handling the post-verification state — the session token wasn’t being picked up after OTP confirmation.

I sent this prompt:

Fix the authentication flow for the "Fittrack" app built using InsForge. The current issue is that after email OTP verification, users are not redirected to the dashboard and sessions are not being established correctly.

The agent traced through the OTP verification callback, found where the session initialization was being dropped, corrected the order of operations, and added proper handling for the post-verification redirect. One prompt, problem fixed.

I tested again — registered, received the OTP, entered it, and this time landed directly on the dashboard. Session persisting across refresh too. Auth was solid.

Round Two: UI Fix

With auth working, I took a proper look at the interface and it needed work. The structure was all there — dashboard, meal log, hydration tracker, analytics — but the visual design was rough. Default styling, inconsistent spacing, the kind of thing that tells you immediately an AI built it without any design direction.

I prompted the agent to redesign the UI. It came back with a few questions first — color scheme, overall vibe, any preferences on layout. I told it: light mode, green accent color, clean and minimal, prioritize readability.

It went through every page and applied the design system consistently. Navigation, cards, forms, buttons, typography — all of it updated. The before and after was significant. Not perfect, but something I’d actually show someone without being embarrassed.

Round Three: Final Polish and Meal Photo Uploads

The prompt I sent:

Fix meal form reset null error, fetch and show user profile in navbar/profile, maintain auth state, add optional meal photo upload using InsForge storage.

A closer walkthrough after the redesign turned up a few more things — minor inconsistencies between pages, a form not resetting correctly after submission, a couple of small UI issues the redesign pass had missed.

More importantly, I realized I’d left meal photo uploads out of the original prompt entirely. That was a feature I actually wanted — being able to attach a photo to a meal entry.

I bundled everything into one prompt: the UI fixes, the form issues, and the photo upload feature.

The photo upload part is where InsForge’s integrated approach really shows its value. The agent didn’t reach for S3 or any third-party storage. It used InsForge Cloud Storage directly. It created a storage bucket, wrote the upload logic, updated the meal form with a file input, handled the optional case correctly, and stored the image URL in the database alongside the meal data.

The App That Exists Now

After those three passes, here’s what FitTrack actually does:

Auth that works correctly — Users register with email, receive a verification email, verify and get logged in. Sessions persist across browser refreshes. Logout works from any page and properly clears the session. Edge cases like “what if someone tries to log in before verifying” are handled with a clear error message.

A useful dashboard — The main screen shows today at a glance: meals logged, total calories, hydration intake for the day. Quick-add buttons that open the meal and hydration forms without leaving the page. Clean enough that you’d actually want to open it.

Meal logging with photos — Add a meal with a name, calorie count, optional description, and optional photo. If you attach a photo, it uploads to InsForge’s cloud storage and the image shows in the meal log. The form resets cleanly after submission. Validation tells you clearly what’s missing if you try to submit an incomplete entry.

Hydration tracking — Log water intake in whatever unit you prefer. The dashboard shows progress toward a daily goal. Small but actually useful for people who are bad at drinking water (me).

Notes — A simple text field for daily notes. Not everything fits into structured data. Sometimes you just want to write “had a headache all day, probably didn’t drink enough water.” The notes section handles that.

History and analytics — Browse your log by date. The analytics page has actual charts — weekly calorie trends, hydration averages, meal frequency. Built with real data from the Postgres database, updating as you add entries.

Profile management — Update your display name and basic details. Not complicated, but necessary.

This is not a prototype. It’s not a demo with hardcoded data. It’s a working application backed by a real Postgres database, with real authentication, and real cloud storage. If I wanted to, I could give this URL to someone and they could actually use it.

The InsForge Dashboard: Full Visibility Into What Was Built

One thing I want to highlight because it matters for understanding how InsForge works: you can see everything the agent built.

After the agent finished, I opened the InsForge dashboard and looked at what existed. The database section has multiple tables: users (managed by auth), meals, hydration, and notes. Each table had the right schema — meal records had a user_id foreign key, a name field, a calorie field, a description field, and a photo_url field for the storage reference. Properly structured, properly related.

The authentication section showed my test user account, verified status, creation timestamp. The storage section showed the bucket created for meal photos and the files that had been uploaded during testing.

The logs section showed every database operation that had occurred — inserts, reads, the whole history. If something had gone wrong, this is where I’d diagnose it.

And the deployment section — this is the final step. Navigate there, give the agent a prompt to deploy, and InsForge handles the build process and hosting. You get a live URL. That’s the whole process.

Honest Assessment: What This Workflow Is and Isn’t

I want to be clear about something. This is not a workflow where you write one prompt and a perfect app appears. That doesn’t exist. What this is:

It is a workflow where the feedback loop is so compressed that what would have taken a week of evenings now takes an afternoon.

It is a workflow where you’re thinking about features and user experience instead of connection strings and migration files.

It is a workflow where when things break — and things will break — fixing them is fast because you’re writing prompts, not debugging infrastructure.

It isn’t magic. The app needed three rounds of iteration before I was happy with it. Auth was broken in round one. The UI needed multiple passes. A feature I forgot in the original prompt required a separate pass to add.

It isn’t suitable for complex architectural decisions that need careful human judgment. If you’re building something with unusual performance requirements, complex data relationships, or tricky consistency guarantees — you’ll still need to think carefully about those things. InsForge handles the infrastructure; it doesn’t replace architectural thinking.

What it is, fundamentally, is a dramatic reduction in the overhead between having an idea and having a working version of that idea. The plumbing is handled. You focus on the building.

Wrap Up

We went from zero to a fully working Diet & Hydration Tracker — with auth, a real Postgres database, cloud storage for meal photos, analytics, and deployment — using nothing but prompts. No backend code written by hand. No infrastructure setup. No debugging sessions wondering why the connection string is wrong in production.

That’s all for now

Keep Coding✌️✌️

Picture this: You’ve just built a sleek MCP (Model Context Protocol) server that powers AI agents for multiple clients. Everything works beautifully until you realize that Client A’s AI assistant can access Client B’s sensitive data. Or worse, an unauthorized user creates, reads, and deletes data from any tenant’s workspace without breaking a sweat.

This isn’t a hypothetical nightmare. It’s the reality of unsecured multi-tenant MCP servers.

What is a Multi-Tenant MCP Server?

A multi-tenant MCP server is like an apartment building for AI tools. Instead of building separate servers for each client (tenant), you create one powerful server that serves multiple organizations simultaneously. Each tenant gets their own isolated workspace, data, and resources, at least, that’s how it should work.

The Model Context Protocol (MCP) has revolutionized how AI agents interact with external tools and data sources. But with great power comes great responsibility, especially when you’re serving multiple clients from a single instance.

The Multi-Tenant Security Minefield

Multi-tenant architectures introduce unique security challenges that can turn your innovative AI solution into a liability. But when AI agents become your clients instead of humans, the threat landscape changes fundamentally.

Why AI Agents Change Everything

Traditional multi-tenant applications serve human users through web browsers or mobile apps. Humans make mistakes, but they’re generally predictable. AI agents, however, operate differently:

Humans:

• Navigate through UIs with guardrails
• Limited by typing speed and attention span
• Social engineering requires conversation and time
• Can be detected by behavioral anomalies

AI Agents:

• Make API calls programmatically at machine speed
• Can enumerate thousands of tenant IDs in seconds
• Execute complex multi-step attacks automatically
• Adapt strategies based on responses

The Critical Difference: An AI agent acting as an MCP client can systematically probe your server’s security boundaries far more efficiently than any human attacker. Without proper isolation, a compromised or malicious AI agent doesn’t just leak one tenant’s data — it can exfiltrate entire databases before you notice.

The Cross-Tenant Threat Model: Deep Dive

Let’s analyze each threat vector in the context of AI-powered MCP clients:

1. Cross-Tenant Data Leakage

Traditional Risk: User A accidentally sees User B’s data through a UI bug.

AI Agent Risk: An AI agent systematically queries all possible tenant identifiers, building a complete map of your multi-tenant architecture.

Why It Matters: AI agents don’t get tired. They don’t make random typos. They systematically exploit every weakness until they find what works. Without authentication, your entire multi-tenant database is one enumeration attack away from exposure.

2. Unauthorized Access at Machine Speed

Traditional Risk: An unauthorized user manually creates a few records.

AI Agent Risk: A malicious agent creates thousands of poisoned records across multiple tenants simultaneously, corrupting your entire dataset.

Why It Matters: AI agents can inject malicious data at scale. Without authentication, you can’t even trace which agent caused the damage. Was it a bug? A malicious actor? You’ll never know.

3. Scope Creep and Permission Escalation

Traditional Risk: A user with read access somehow gets write permissions through a UI bug.

AI Agent Risk: An agent probes every endpoint systematically, discovering which operations lack permission checks, then exploits them to gain unauthorized capabilities.

Why It Matters: An AI agent will find every permission hole in your API surface within minutes of first connection. It doesn’t need to understand your business logic — it just tries everything.

4. Compliance Violations at Scale

Traditional Risk: One user’s data is mishandled, triggering a GDPR complaint.

AI Agent Risk: An automated agent accesses data across all tenants, triggering simultaneous violations for every organization you serve.

Why It Matters: With human attackers, breaches are usually isolated. With AI agents in a multi-tenant system, every security failure affects every tenant. Your liability multiplies by your customer count.

5. The Identity Crisis: Who Did What?

Traditional Risk: Can’t track which user performed an action.

AI Agent Risk: Can’t even identify which AI agent from which tenant made a request. Complete loss of attribution.

Why It Matters:

• No audit trail for compliance audits
• No incident response — can’t identify attack source
• No rate limiting per tenant — one agent can DoS everyone
• No accountability — agents act with impunity

The Insecure Foundation

To illustrate these risks, let’s examine an unsecured MCP server implementation (don’t worry, we’ll fix it soon):

# ❌ INSECURE: No authentication, no tenant isolation
@mcp.tool
def create_todo(title: str, tenant_id: str, description: Optional[str] = None):
    # Anyone can pass ANY tenant_id - zero verification!
    tenant_store = TODO_STORE.setdefault(tenant_id, {})
    todo = TodoItem(id=str(uuid.uuid4()), tenant_id=tenant_id, title=title)
    tenant_store[todo.id] = todo
    return {"todo": todo.to_dict()}

What’s wrong here?

• No authentication: Anyone can call this endpoint
• Client-controlled tenant_id: The user provides their own tenant ID. They could claim to be anyone!
• No scope validation: Even if we added auth, there’s no check for write permissions
• Zero accountability: No audit trail of who did what

Our Mission: From Vulnerable to Unbreakable

In this blog post, we’ll transform that vulnerable server into a secured one. Using Scalekit’s scoped authentication and robust MCP security patterns, we’ll demonstrate how to:

✅ Implement proper authentication so only authorized users access your server
✅ Enforce true tenant isolation where tenant_id comes from verified tokens, not user input
✅ Apply granular permission scopes (read vs. write) for fine-grained access control
✅ Eliminate cross-tenant threats completely
✅ Build a production-ready, secure multi-tenant MCP server you can deploy with confidence

By the end of this journey, you’ll understand not just how to secure your MCP server, but why each security layer matters. You’ll see the exact code transformation from vulnerable to secure, and you’ll have a blueprint you can apply to your own MCP implementations.

Part 1: Building the Vulnerable Server

Before we build the secured server, let’s first understand the vulnerabilities by building an intentionally insecure MCP server. This hands-on approach will make the security improvements crystal clear.

Setting Up the Development Environment

Let’s start by creating a clean Python environment for our MCP server.

Step 1: Create a Virtual Environment

First, create a new directory for your project and set up a virtual environment:

# Create project directory
mkdir insecure-mcp-server
cd insecure-mcp-server

# Create virtual environment
python3 -m venv todovenv

Activate the environment, and you should see (todovenv) appear in your terminal prompt, indicating the virtual environment is active.

Step 2: Install FastMCP

FastMCP is a Python framework that makes building MCP servers simple and intuitive. Let’s install it:

pip install fastmcp

This will install FastMCP along with all its dependencies. You should see output confirming the installation.

Step 3: Install Additional Dependencies

We’ll need a few more packages for our server:

pip install python-dotenv

The python-dotenv package allows us to manage environment variables easily (though we won't use them much in the insecure version).

The Insecure Server: A Line-by-Line Breakdown

Now, let’s create our vulnerable MCP server. Create a file called server.py and let's walk through each section:

import os
import uuid
from dataclasses import dataclass, asdict
from typing import Optional, Dict

from dotenv import load_dotenv
from fastmcp import FastMCP

load_dotenv()

What’s happening here?

• We import the necessary libraries for our server
• uuid will generate unique IDs for our todo items
• dataclasses provides a clean way to define our data models
• FastMCP is the core framework for building our MCP server
• load_dotenv() loads environment variables (not critical for this insecure version)

# -------------------------------------------------
# MCP Server (INSECURE ❌)
# -------------------------------------------------

mcp = FastMCP(
    "Multi-Tenant Todo MCP",
    stateless_http=True,
)

🚨 SECURITY FLAW #1: No Authentication

Notice what’s missing here — there’s no auth parameter! This means:

• Anyone can connect to this server
• No verification of who’s making requests
• No way to identify which tenant is accessing data
• Zero accountability or audit trail

# -------------------------------------------------
# Data Model
# -------------------------------------------------

@dataclass
class TodoItem:
    id: str
    tenant_id: str
    title: str
    description: Optional[str]
    completed: bool = False

    def to_dict(self):
        return asdict(self)

Data Model Breakdown:

Our TodoItem is a simple dataclass that represents a single todo entry:

• id: Unique identifier for each todo
• tenant_id: Which tenant owns this todo (this becomes crucial for isolation)
• title: The todo's main text
• description: Optional additional details
• completed: Status flag (defaults to False)
• to_dict(): Converts the dataclass to a dictionary for JSON responses

The model itself is fine — it’s how we use it that creates vulnerabilities.

# -------------------------------------------------
# In-Memory Store
# tenant_id -> { todo_id -> TodoItem }
# -------------------------------------------------

TODO_STORE: Dict[str, Dict[str, TodoItem]] = {}

Storage Architecture:

This is a nested dictionary structure:

• Outer dictionary: Keys are tenant_id strings, representing different tenants
• Inner dictionary: Keys are todo_id strings, values are TodoItem objects

Structure visualization:

TODO_STORE = {
    "tenant_abc": {
        "todo_001": TodoItem(...),
        "todo_002": TodoItem(...),
    },
    "tenant_xyz": {
        "todo_003": TodoItem(...),
    }
}

Why in-memory? For this demo, we’re keeping it simple. In production, you’d use a real database (PostgreSQL, MongoDB, etc.), but the security principles remain the same.

The Vulnerable Tools: Where Things Go Wrong

Now let’s look at the actual MCP tools — this is where the security holes become glaringly obvious.

@mcp.tool
def create_todo(
    title: str,
    tenant_id: str,
    description: Optional[str] = None,
) -> dict:
    tenant_store = TODO_STORE.setdefault(tenant_id, {})
    
    todo = TodoItem(
        id=str(uuid.uuid4()),
        tenant_id=tenant_id,
        title=title,
        description=description,
    )
    
    tenant_store[todo.id] = todo
    return {"todo": todo.to_dict()}

🚨 SECURITY FLAW #2: Client-Controlled Tenant ID

This is the worst security mistake you can make in a multi-tenant system:

1. The user provides tenant_id as a parameter - They can claim to be any tenant
2. No verification — We blindly trust whatever tenant_id they send
3. Direct data access — We immediately use that tenant_id to access the store

Attack scenario:

# Attacker discovers tenant IDs through enumeration or social engineering
create_todo(title="Malicious todo", tenant_id="victim_company_123")
# Boom! They just injected data into another tenant's workspace

What we should do instead: Extract tenant_id from a verified authentication token, never from user input.

@mcp.tool
def list_todos(tenant_id: str) -> dict:
    tenant_store = TODO_STORE.get(tenant_id, {})
    return {
        "todos": [todo.to_dict() for todo in tenant_store.values()]
    }

🚨 SECURITY FLAW #3: Unrestricted Data Access

Same problem, different tool:

• User controls which tenant’s data to retrieve
• No authentication means anyone can call this
• No authorization means anyone can read any tenant’s data

Attack scenario:

# Attacker iterates through possible tenant IDs
for tenant_id in ["company_a", "company_b", "company_c"]:
    todos = list_todos(tenant_id=tenant_id)
    # Exfiltrate all todo data from all tenants!

@mcp.tool
def get_todo(tenant_id: str, todo_id: str) -> dict:
    tenant_store = TODO_STORE.get(tenant_id, {})
    todo = tenant_store.get(todo_id)
    
    if not todo:
        return {"error": "Todo not found"}
    
    return {"todo": todo.to_dict()}

🚨 SECURITY FLAW #4: No Access Control

Even though we check if the todo exists, we still allow anyone to:

• Probe for valid todo IDs
• Read any todo from any tenant

@mcp.tool
def delete_todo(tenant_id: str, todo_id: str) -> dict:
    tenant_store = TODO_STORE.get(tenant_id, {})
    
    if todo_id not in tenant_store:
        return {"error": "Todo not found"}
    
    del tenant_store[todo_id]
    return {"deleted": todo_id}

🚨 SECURITY FLAW #5: Destructive Operations Without Verification

Deletion is permanent and destructive, yet:

• No authentication required
• No authorization check
• No confirmation mechanism
• No audit trail

Attack scenario:

# Attacker deletes all todos from a competitor
delete_todo(tenant_id="competitor_company", todo_id="critical_project_todo")
# Data is gone forever (in this in-memory example)

# -------------------------------------------------
# Run Server
# -------------------------------------------------

if __name__ == "__main__":
    mcp.run(transport="http", port=3002)

Server Startup:

This launches the MCP server on port 3002 using HTTP transport:

• transport="http" makes it accessible via HTTP requests
• port=3002 is the local port the server listens on

Testing the Insecure Server

Let’s run this vulnerable server and see it in action:

python server.py

You should see output indicating the server is running on http://localhost:3002. Actually, you’ll see the server hosting on http://localhost:3002/mcp, this is the default feature of FastMCP.

Now, let’s use the MCP Inspector — a powerful tool for testing and debugging MCP servers. Open a new terminal window (keep the server running in the first one) and run:

npx @modelcontextprotocol/inspector@latest

This will launch the MCP Inspector interface in your browser. The Inspector provides a user-friendly GUI to interact with your MCP server.

Connecting to Our Insecure Server

Once the Inspector opens:

1. Connect to the server by entering the server URL: http://localhost:3002/mcp
2. Click on “Tools”
3. Click “List Tools” to see all available MCP tools

You’ll see all our tools displayed:

• create_todo
• list_todos
• get_todo
• delete_todo

Notice something alarming? There’s no login screen, no authentication prompt, nothing. You’re directly connected to the server with full access.

Demonstrating the Vulnerability: Creating a Todo

Let’s create a todo as a legitimate user:

1. Click on the create_todo tool
2. Fill in the parameters:

3. Click “Run Tool”

Response received:

Great! The todo was created successfully. Everything seems to work fine… until we demonstrate the cross-tenant threat.

The Cross-Tenant Attack: A Nightmare Scenario

Now, imagine a different scenario. Either:

• Maliciously: An attacker discovers or guesses the tenant_id
• Accidentally: Another user coincidentally uses the same tenant_id
• Through social engineering: Someone tricks a user into revealing their tenant ID

Let’s simulate this attack:

1. Click on the list_todos tool
2. Enter the same tenant_id we used before:

3. Click “Run Tool”

Response received:

What just happened?

• ❌ No authentication required — Anyone could make this request
• ❌ No verification of identity — The server has no idea who is asking
• ❌ Complete data exposure — The entire todo list is now visible to an unauthorized party
• ❌ Confidential information leaked

The Attack Chain Continues…

An attacker can now:

1. Read all todos:

// list_todos with tenant_id: "SaP Tech"
// Result: Full visibility into company's internal tasks

2. Create malicious todos:

{
  "title": "Cancel all vendor contracts",
  "tenant_id": "SaP Tech",
  "description": "CEO approved - urgent"
}
// Injecting false information into another tenant's workspace

3. Delete critical tasks:

{
  "tenant_id": "SaP Tech",
  "todo_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}
// Permanently destroying important business data

The Real-World Impact

This isn’t just a theoretical exercise. In a production environment with this insecure setup:

Technical Consequences:

• 🎯 Zero tenant isolation: Every tenant’s data is accessible to everyone
• 🚫 No audit trail: Can’t even track who did what
• 🔓 Unlimited scope: Even a “read-only” user could delete everything
• 🌐 Public exposure: Anyone on the network can access the server

Why Traditional Solutions Fall Short

You might be thinking: “Can’t I just add a simple API key?”

That’s not enough for multi-tenant systems:

# ❌ STILL VULNERABLE: Simple API key check
API_KEY = "secret_api_key"

@mcp.tool
def create_todo(api_key: str, tenant_id: str, title: str):
    if api_key != API_KEY:
        return {"error": "Unauthorized"}
    # Problem: tenant_id is STILL user-controlled!
    # One API key = access to ALL tenants

What we need:

✅ Authentication that identifies the user
✅ Authorization that verifies the tenant
✅ Scope validation that limits permissions
✅ Token-based tenant extraction (never trust user input)
✅ Granular access control (read vs. write vs. delete)

This is where Scalekit’s scoped authentication becomes essential.

Part 2: Securing with Scalekit

Now comes the transformation. We’re going to take that vulnerable server and turn it into a production-grade, secure multi-tenant MCP server using Scalekit’s authentication and scoped authorization.

What is Scalekit?

Scalekit is an enterprise-ready authentication platform that specializes in multi-tenant B2B applications. It provides:

• Enterprise SSO — SAML, OIDC support for seamless login
• Multi-tenancy built-in — Tenant isolation is core to its design
• Scoped permissions — Granular control over what users can do
• Token-based auth — Secure JWT tokens with embedded claims
• Admin portal — Easy management of organizations and users

For MCP servers, Scalekit solves our critical security problems:

1. Authentication — Verifying who is making requests
2. Tenant Isolation — Ensuring users only access their data
3. Authorization — Controlling what users can do (read vs. write)

The Secure Server: Code Transformation

Create a new file server_secured.py (or update your existing server.py). Let's walk through the critical changes:

1. New Imports: Scalekit Authentication

from fastmcp.server.auth.providers.scalekit import ScalekitProvider
from fastmcp.server.dependencies import AccessToken, get_access_token

What’s new?

• ScalekitProvider: The authentication provider that integrates Scalekit with FastMCP
• AccessToken: Type definition for the authenticated token object
• get_access_token(): Dependency injection to retrieve the current user's token

These imports are the foundation of our security layer.

2. Environment Variables for Configuration

load_dotenv()

Before initializing the server, we load environment variables. Create a .env file in your project root:

# .env
SCALEKIT_ENVIRONMENT_URL=https://{your-workspace}.scalekit.{dev/com}
SCALEKIT_RESOURCE_ID=res_your_resource_id_here
SCALEKIT_BASE_URL=http://localhost:3002/

Why environment variables?

• 🔒 Security: Never hardcode credentials in your source code
• 🔄 Flexibility: Easy to change between dev/staging/production
• ✅ Best practice: Industry standard for configuration management

3. Secured MCP Server Initialization

mcp = FastMCP(
    "Multi-Tenant Todo MCP (SECURED)",
    stateless_http=True,
    auth=ScalekitProvider(
        environment_url=os.getenv("SCALEKIT_ENVIRONMENT_URL"),
        resource_id=os.getenv("SCALEKIT_RESOURCE_ID"),
        base_url=os.getenv("SCALEKIT_BASE_URL"),
    ),
)

🔐 SECURITY TRANSFORMATION #1: Authentication Layer Added

This is the single most important change. Let’s break down each parameter:

environment_url - Your Scalekit environment

• To obtain environment url, go to Scalekit Dashboard → Settings → Copy the Environment URL
• This is your unique Scalekit instance
• All authentication requests go through this URL

resource_id - The protected resource

• Format: res_xxxxxxxxxxxxx
• Used for scope validation

base_url - Your MCP server's URL

• Where your server is running (e.g., http://localhost:3002/)

What happens now?

• ✅ Every request is authenticated — No more anonymous access
• ✅ Valid JWT tokens required — Scalekit issues and validates tokens
• ✅ Automatic tenant extraction — Tenant ID comes from the token, not user input
• ✅ Scope enforcement — Users can only perform allowed actions

4. Scope Validation Helper Function

def _require_scope(scope: str) -> Optional[str]:
    token: AccessToken = get_access_token()
    if scope not in token.scopes:
        return f"Insufficient permissions: `{scope}` scope required."
    return None

🎯 SECURITY TRANSFORMATION #2: Granular Permissions

This helper function enforces scoped authorization:

How it works:

1. Retrieves the current user’s access token using get_access_token()
2. Checks if the required scope exists in token.scopes
3. Returns an error message if the scope is missing
4. Returns None if the scope is present (permission granted)

Why this matters:

• 📖 Read-only users can’t accidentally delete data
• ✏️ Write permissions are explicitly required for modifications
• 🔒 Principle of least privilege — Users only get necessary permissions
• 🛡️ Defense in depth — Multiple layers of security checks

5. Secured Tool: create_todo

@mcp.tool
def create_todo(
    title: str,
    description: Optional[str] = None,
) -> dict:
    
    error = _require_scope("todo:write")
    if error:
        return {"error": error}

    
    token: AccessToken = get_access_token()
    tenant_id = token.claims.get("oid")

    if not tenant_id:
        return {"error": "tenant_id missing in access token"}

    tenant_store = TODO_STORE.setdefault(tenant_id, {})

    todo = TodoItem(
        id=str(uuid.uuid4()),
        tenant_id=tenant_id,
        title=title,
        description=description,
    )

    tenant_store[todo.id] = todo
    return {"todo": todo.to_dict()}

🛡️ CRITICAL SECURITY IMPROVEMENTS:

1. No tenant_id parameter!

# ❌ BEFORE (Insecure):
def create_todo(title: str, tenant_id: str, ...):

# ✅ AFTER (Secure):
def create_todo(title: str, description: Optional[str] = None):

Why? Users can no longer provide their own tenant_id. This eliminates the entire attack vector!

2. Scope validation first:

error = _require_scope("todo:write")
if error:
    return {"error": error}

Result: Only users with todo:write scope can create todos. Read-only users are blocked immediately.

3. Tenant extraction from token:

token: AccessToken = get_access_token()
tenant_id = token.claims.get("oid")

Result: The oid comes from Scalekit's cryptographically signed JWT token, not user input. Tampering is impossible.

Attack prevention:

• ❌ Can’t specify a different tenant_id
• ❌ Can’t bypass authentication
• ❌ Can’t escalate privileges (no write scope = no creation)
• ✅ Can ONLY create todos in your own tenant

6. Secured Tool: list_todos

@mcp.tool
def list_todos() -> dict:
    
    error = _require_scope("todo:read")
    if error:
        return {"error": error}

    
    token: AccessToken = get_access_token()
    tenant_id = token.claims.get("oid")

    if not tenant_id:
        return {"error": "tenant_id missing in access token"}

    tenant_store = TODO_STORE.get(tenant_id, {})
    return {
        "todos": [todo.to_dict() for todo in tenant_store.values()]
    }

🔒 TRANSFORMATION HIGHLIGHTS:

Before (Insecure):

def list_todos(tenant_id: str):  # User controls which tenant!
    tenant_store = TODO_STORE.get(tenant_id, {})
    return {"todos": [...]}

After (Secure):

def list_todos():  # NO tenant_id parameter!
    error = _require_scope("todo:read")  # Must have read permission
    tenant_id = token.claims.get("oid")  # From verified token
    tenant_store = TODO_STORE.get(tenant_id, {})
    return {"todos": [...]}

Result: Users can only see their own tenant’s todos. Cross-tenant data access is impossible.

7. Secured Tool: get_todo

@mcp.tool
def get_todo(todo_id: str) -> dict:
    error = _require_scope("todo:read")
    if error:
        return {"error": error}

    token: AccessToken = get_access_token()
    tenant_id = token.claims.get("oid")

    if not tenant_id:
        return {"error": "tenant_id missing in access token"}

    tenant_store = TODO_STORE.get(tenant_id, {})
    todo = tenant_store.get(todo_id)

    if not todo:
        return {"error": "Todo not found"}

    return {"todo": todo.to_dict()}

🎯 SECURITY IMPROVEMENT:

Even though the user provides todo_id, they can only access todos from their own tenant:

tenant_store = TODO_STORE.get(tenant_id, {})  # tenant_id from token!
todo = tenant_store.get(todo_id)

Attack scenario prevented:

❌ Attacker tries: get_todo(todo_id="other_tenant_todo_id")
✅ Result: "Todo not found" (because it's not in THEIR tenant_store)

The todo_id lookup is scoped to the authenticated tenant automatically!

8. Secured Tool: delete_todo

@mcp.tool
def delete_todo(todo_id: str) -> dict:
    
    error = _require_scope("todo:write")
    if error:
        return {"error": error}

    token: AccessToken = get_access_token()
    tenant_id = token.claims.get("oid")

    if not tenant_id:
        return {"error": "tenant_id missing in access token"}

    tenant_store = TODO_STORE.get(tenant_id, {})

    if todo_id not in tenant_store:
        return {"error": "Todo not found"}

    del tenant_store[todo_id]
    return {"deleted": todo_id}

CRITICAL PROTECTION FOR DESTRUCTIVE OPERATIONS:

Notice: _require_scope("todo:write") - not todo:read!

Why this matters:

• Read-only users can view todos but cannot delete them
• Only users with explicit write permissions can perform destructive actions
• Prevents accidental data loss from over-privileged accounts

Defense layers:

1. ✅ Must be authenticated (Scalekit token required)
2. ✅ Must have todo:write scope (not just todo:read)
3. ✅ Can only delete from their own tenant (token-based tenant_id)
4. ✅ Todo must exist in their tenant (not someone else’s)

Now that we understand the code, let’s configure the authentication layer in Scalekit. But first, let’s understand Why this architecture works and How the security actually functions under the hood.

Understanding the Technical Foundation: Why Scalekit Works

Before clicking through dashboards, it’s crucial to understand the cryptographic and architectural principles that make this secure.

The JWT Token

When Scalekit authenticates a user, it issues a JSON Web Token (JWT). This isn’t just a random string — it’s a cryptographically signed proof of identity.

JWT Structure:

A JWT has three parts, separated by dots: header.payload.signature

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiMTIzIiwidGVuYW50X2lkIjoiYWNtZV9jb3JwIiwic2NvcGVzIjpbInRvZG86cmVhZCIsInRvZG86d3JpdGUiXX0.signature_hash

Let’s decode each part:

1. Header (Algorithm + Token Type):

{
  "alg": "RS256",  // RSA signature with SHA-256
  "typ": "JWT"     // Token type
}

2. Payload (The Claims — This is what matters):

{
  "user_id": "user_abc123",
  "oid": "xyz_org",  // ← THE CRITICAL CLAIM
  "scopes": ["todo:read", "todo:write"],
  "iss": "https://2minutespy.scalekit.dev",  // Issuer
  "sub": "user_abc123",  // Subject
  "aud": "res_112158011463566594",  // Audience (your resource)
  "exp": 1735689600,  // Expiration timestamp
  "iat": 1735603200,  // Issued at
  "jti": "unique-token-id"  // JWT ID
}

3. Signature (Cryptographic Proof):

RSASHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  scalekit_private_key
)

Why This Is Secure:

🔐 Tamper-Proof: The signature is created using Scalekit’s private key. If you change even one character in the header or payload, the signature becomes invalid. Your MCP server verifies the signature using Scalekit’s public key.

🎯 oid (similar to tenant id) in the Claims: Notice "oid": "xyz_org" in the payload? This is set by Scalekit based on which organization the user belongs to. The user never provides this - Scalekit determines it during authentication.

⚡ Scopes Embedded: The scopes array is also in the token. Your code checks token.scopes - these scopes were assigned in Scalekit's dashboard and are cryptographically bound to this user.

⏰ Time-Bounded: The exp (expiration) claim means tokens automatically expire. Even if somehow compromised, the window of vulnerability is limited.

How tenant_id (oid) Ends Up in token.claims

Let’s trace exactly how tenant_id flows from Scalekit to your code:

Step 1: User Authentication

User → Scalekit Login → "Who is this user?"
Scalekit checks: email → user_abc123 → belongs to organization → xyz_org

Step 2: JWT Generation

Scalekit creates JWT payload:
{
  "user_id": "user_abc123",
  "tenant_id": "xyz_org",    Determined by Scalekit, not user input
  "scopes": ["todo:read", "todo:write"]
}

Signs it with private key → JWT token

Step 3: Token Delivery

JWT → Browser → MCP Inspector → Stored in Authorization header

Step 4: Request to Your MCP Server

HTTP Request:
POST /create_todo
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Body: { "title": "My todo" }

Step 5: FastMCP + ScalekitProvider Validation

# Inside FastMCP's authentication middleware
token_string = request.headers["Authorization"].replace("Bearer ", "")

# ScalekitProvider validates:
1. Verify signature using Scalekit's public key
2. Check expiration (exp claim)
3. Verify audience (aud) matches your resource_id
4. Extract all claims into AccessToken object

access_token = AccessToken(
    user_id="user_abc123",
    tenant_id="xyz_org",  # From JWT claims
    scopes=["todo:read", "todo:write"],
    claims={...}  # Full JWT payload
)

Step 6: Your Code Accesses It

@mcp.tool
def create_todo(title: str):
    token: AccessToken = get_access_token()  # Injected by FastMCP
    tenant_id = token.claims.get("oid")  # "xyz_org"
    
    # THIS tenant_id:
    # ✓ Came from a cryptographically signed JWT
    # ✓ Was determined by Scalekit based on user's org
    # ✓ Cannot be forged or modified
    # ✓ Is absolutely trustworthy

Part 3: Where Do These Scopes and Resource IDs Come From?

You might be wondering: “Where did todo:read, todo:write, and resource_id come from?"

Great question! These aren’t magical — they’re configured in Scalekit’s dashboard.

Step-by-Step Dashboard Configuration

Let’s walk through registering our MCP server in Scalekit:

Step 1: Access the Scalekit Dashboard

First, head over to the Scalekit website and log in to your account:

1. Navigate to https://scalekit.com
2. Click “Sign In” and enter your credentials

Once logged in, you’ll see the main dashboard.

Step 2: Add Your MCP Server

Now let’s register our MCP server:

1. In the sidebar, under Configure, click on “MCP Server”
2. Click the “Add MCP Server” button

You’ll see a form to configure your new MCP server.

Step 3: Name Your Server

In the form, enter a descriptive name for your server:

Server Name:

ToDo MCP Server

This name helps you identify this server in the dashboard.

Step 4: Configure Server URL

In the Configuration section, specify your MCP server’s URL:

Server URL:

http://localhost:3002/

Important notes:

• For local development: http://localhost:3002/
• For production: https://api.yourdomain.com/
• Always include the trailing slash (/)
• Make sure the port matches your MCP server’s port (3002)

Step 5: Add Scopes (Advanced Configuration)

Click on “Advanced Configuration” to expand the scopes section.

Now add your two scopes:

Scope 1: Read Permission

Scope Name: todo:read
Description: To read todo

Click “Add Permission”.

Scope 2: Write Permission

Scope Name: todo:write
Description: To create, update and delete todo

Click “Add Permission”.

Step 6: Save All Changes

Review your configuration:

✅ Server Name: ToDo MCP Server
✅ Server URL: http://localhost:3002/
✅ Scopes: todo:read, todo:write

Click “Save” to finalize the configuration.

Step 7: Copy the Resource ID

After saving, you’ll see your server in the list. Next to your server name, you’ll see a Resource ID displayed:

res_11215801146356xxxx

📋 Copy this Resource ID — you’ll need it in your .env file!

The Resource ID format always starts with res_ followed by numbers. This uniquely identifies your MCP server in Scalekit.

Step 8: Update Your .env File

Now, add this Resource ID to your environment configuration.

Open (or create) your .env file in your project root directory:

# .env file
# Your Scalekit environment URL
SCALEKIT_ENVIRONMENT_URL=https://{your-workspace}.scalekit.{dev/com}
# The Resource ID you just copied (starts with res_)
SCALEKIT_RESOURCE_ID=res_11215801146356xxxx
# Your MCP server's base URL
SCALEKIT_BASE_URL=http://localhost:3002/

Where to find the other values:

• SCALEKIT_ENVIRONMENT_URL: Found in your Scalekit dashboard settings
• SCALEKIT_BASE_URL: Your MCP server’s running URL (same as configured in Step 4)

Part 4: Testing the Secured Server — Scoped Auth in Action

Now comes the exciting part, let’s test our secured MCP server and see how Scalekit’s scoped authentication protects our multi-tenant system.

Starting the Server and MCP Inspector

First, let’s get both components running:

Terminal 1: Start the Secured MCP Server

# Make sure you're in your project directory
# and virtual environment is activated
python server.py

You should see output indicating the server is running.

Important: Keep this terminal running!

Terminal 2: Start the MCP Inspector

Open a new terminal window and run:

npx @modelcontextprotocol/inspector@latest

The MCP Inspector will open in your browser.

Configuring Scoped Permissions

Before we test, let’s configure our user to have read-only permissions to demonstrate scope enforcement.

In your Scalekit Dashboard:

1. Navigate to your registered MCP server
2. Edit your MCP server by clicking the three (…) dots
3. Go to Configuration section and then Advanced Configuration section
4. Assign only the todo:read scope
5. Do NOT assign todo:write (we'll test this restriction)
6. Save the changes

This simulates a read-only user — someone who should be able to view todos but not create or delete them.

Authenticating with OAuth

Now let’s authenticate properly using Scalekit’s OAuth flow.

In MCP Inspector (center of the screen):

1. Look for the “Open Auth Settings” button

2. Click “Open Auth Settings”

3. You’ll see authentication options — click “Quick OAuth Flow”

Authentication Flow Begins:

A new browser window/tab will open with the Scalekit login page.

Steps:

1. Enter your email address
2. Complete the authentication
3. Authorize the MCP Inspector to access your MCP server

4. You’ll be redirected back to the Inspector

Expected Result: ✅ Connection Successful

Key Security Point: The server now knows exactly who you are, which tenant you belong to, and what permissions you have.

The OAuth Flow: End-to-End

Let’s visualize the complete OAuth flow that happens when a user authenticates:

1. User Opens MCP Inspector
   └─> Clicks "Connect"
       └─> Inspector sees: Authentication Required
   
2. Inspector → Scalekit Authorization Endpoint
   GET https://myorg.scalekit.dev/oauth/authorize?
       &resource_id=res_11215801146356xxxx
       &redirect_uri=http://localhost:6274/oauth/callback
       &response_type=code
       &scope=todo:read

3. User Redirected to Scalekit Login Page
   └─> Enters email: user@xyz.com
       └─> Scalekit identifies: "This user belongs to xyz_org"
   
4. User Completes Authentication
   └─> Password / SSO / Magic Link
       └─> Scalekit verifies identity
   
5. User Grants Permission
   └─> "Allow MCP Inspector to access your todos?"
       └─> User clicks "Authorize"
   
6. Scalekit → Inspector Redirect with Authorization Code
   GET http://localhost:6274/oauth/callback?code=AUTHORIZATION_CODE_123
   
7. Inspector → Scalekit Token Exchange
   POST https://myorg.scalekit.dev/oauth/token
   Body:
   {
     "grant_type": "authorization_code",
     "code": "AUTHORIZATION_CODE_123",
     "redirect_uri": "http://localhost:6274/oauth/callback"
   }
8. Scalekit Generates JWT
   └─> Looks up user's organization: xyz_org
   └─> Looks up user's scopes: ["todo:read"]
   └─> Creates JWT payload with tenant_id and scopes
   └─> Signs with private key
   
9. Scalekit → Inspector: Access Token
   Response:
   {
     "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
     "token_type": "Bearer",
     "expires_in": 3600,
     "scope": "todo:read"
   }

10. Inspector Stores Token
    └─> All future requests include:
        Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

11. Inspector → MCP Server Request
    POST http://localhost:3002/mcp/create_todo
    Headers: { "Authorization": "Bearer eyJh..." }
    Body: { "title": "My todo" }

12. FastMCP Middleware Intercepts
    └─> Extracts JWT from Authorization header
    └─> ScalekitProvider validates signature
    └─> Checks expiration, audience, issuer
    └─> Decodes claims
    └─> Creates AccessToken object
    
13. Your Tool Function Executes
    def create_todo(title: str):
        token = get_access_token()
        tenant_id = token.claims.get("oid")  # "xyz_org"
        # Operates on correct tenant's data
        
14. Response → Inspector → User

Attempting to Create a Todo

Now for the critical test — let’s try to create a todo with read-only permissions.

In MCP Inspector:

1. Click on “Tools” in the navigation
2. Click “List Tools” to see all available tools

3. Click on create_todo tool

Fill in the parameters:

Notice: We’re not providing tenant_id. The server will extract it from our token

4. Click “Run Tool”

Expected Result: ❌ Permission Denied

🎯 SCOPED AUTH IN ACTION!

What just happened:

# Inside create_todo function:
error = _require_scope("todo:write")  # Checks token.scopes
if error:
    return {"error": error}  # Blocked here!

The function checked our token and found:

• We are authenticated (valid token)
• We belong to a tenant (tenant_id present)
• We don’t have todo:write in our scopes
• Result: Access denied before any data operation

Compare to Insecure Version:

# ❌ Insecure version:
def create_todo(title: str, tenant_id: str):
    # No checks! Anyone can create anything!
    tenant_store = TODO_STORE.setdefault(tenant_id, {})
    todo = TodoItem(...)

vs.

# ✅ Secured version:
def create_todo(title: str):
    error = _require_scope("todo:write")  # Scope check first!
    if error:
        return {"error": error}
    
    token = get_access_token()
    tenant_id = token.claims.get("oid")  # From verified token

Final Thought

Building secure multi-tenant systems doesn’t have to be complicated. With the right tools like Scalekit and proper architectural patterns, you can transform a vulnerable prototype into a production-ready, enterprise-grade MCP server in hours, not weeks.

Whether you’re building MCP servers, B2B SaaS applications, or enterprise tools — Scalekit makes authentication and authorization simple, secure, and scalable.

That’s all for now

Keep Coding✌✌

When you’re building an application, one thing you can’t skip is API testing. Whether it’s a login flow, payment gateway, or a complex e-commerce workflow, ensuring your APIs behave correctly saves you from nasty surprises in production.

I had already explored EchoAPI earlier, but while working on my recent project, I revisited it. And guess what? They’ve supercharged it with AI-powered features.

This update caught my attention immediately:

• ✅ One-click Docs
• ✅ Fake data generator
• ✅ Bulk parameter updates
• ✅ AI Convert
• ✅ AI Test-case generator
• ✅ AI-powered script & assertion generator

In this blog, I’ll take you through my full experience, step by step, so you’ll know exactly how these features can save you hours of manual testing.

Installing and Setting Up EchoAPI

Before we dive into the AI features, let’s start with the basics.

I downloaded and installed EchoAPI’s desktop app. The interface is clean and very intuitive, something between Postman and Insomnia, but with its own unique AI touch.

For this demo, I connected my FastAPI e-commerce backend. This app has typical endpoints like:

• POST /signup
• POST /login
• GET/cart
• POST /cart/add
• POST /order/place
• POST /payment
• GET/products
• GET/products/{product_id}

Perfect playground to test EchoAPI’s AI magic.

AI-Generated Test Cases

Let’s start with the AI Test-case Generator.

Normally, writing test cases for each endpoint is a tedious process:

• You have to decide scenarios.
• Write expected outcomes.
• Prepare data for each run.
• And then execute them manually.

But EchoAPI just makes it one-click.

Step 1: Pick an Endpoint

Inside EchoAPI, I selected an endpoint from my FastAPI project. Let’s say the signup endpoint.

Step 2: Go to the Cases Section

Here, EchoAPI shows 8 standard testing dimensions (like API Specification Compliance Tests, Invalid Input Handling Tests, HTTP Method Validation, etc.). I kept all of them selected.

Step 3: Generate

I clicked Generate, and instantly, the AI created:

• Case Objectives (e.g., “Test signup with valid data”, “Test signup with missing email”)
• Expected Outcomes (e.g., “Should return 200 OK”, “Should return 400 Bad Request”)
• Test Data (realistic values automatically generated)

Step 4: Apply & Run

When I clicked Apply and Test, EchoAPI ran 13 cases with 35 different sets of data.

That’s a massive workload handled automatically. Imagine writing these manually; it could easily take a couple of hours per endpoint.

And here’s the best part: if something fails, EchoAPI shows why it exactly failed, with every detail in the response section.

Tip: You can re-run failed cases separately to debug faster.

AI-Powered Scripts & Assertions

Sometimes you need more than automated test cases; you want custom scripts and validation rules. EchoAPI covers that too.

AI Script Generator

Let’s say you want a test script for checking a complex payment flow. Instead of writing it yourself, you just ask the AI:

I typed “Generate a script to test a payment API with both valid and invalid card details.”

EchoAPI writes it out, and the script is ready to run.

You can edit these AI-generated scripts or chain them with your own logic if needed.

AI Assertions

Assertions are what validate your API’s response. Doing this manually is slow, especially when responses are large.

Example:

• You send a request.
• You get a JSON response like the following:

{ "status": "success", "order_id": "12345" }

Now, instead of manually writing like this:

assert response.status == "success"
assert "order_id" in response

You just click AI Assert in the response section, and EchoAPI generates these checks for you.

Even better, you can add or modify assertions in plain English:

“Assert that the response returns status 201 and user_id should not be empty”

And it updates your tests. This makes it super friendly even for non-coders who just want to validate business logic.

Chaining Multiple APIs

Real-world apps rarely run on a single endpoint. You usually need a workflow: signup → login → add-to-cart → place-order → make-payment.

EchoAPI lets you chain APIs together so you can test them all in one flow.

Here’s how I did it:

Step 1: Create Folder & Subfolder

First, go to the “Tests” section. Here, I created a folder in EchoAPI for my test flows, then a subfolder for this specific checkout flow.

Step 2: Add Endpoints by Reference

I selected my endpoints into this folder by reference (not by copy). This way, if my endpoint changes, it stays automatically synchronized here.

Step 3: Configure Each Endpoint

• Signup Endpoint: Entered new user data and saved.

• Login Endpoint: Used the same credentials. This gives me access_token.

• Captured the access token from the response and stored it as a variable using JSONPath expression in the Post-response section.

• Add-to-Cart Endpoint: Added a product. Passed the access token in the Auth header.

• Place-Order Endpoint: Placed the order. Passed the access token in the Auth header. Captured the order ID and stored it as a variable in the Post-response section.

• Make-Payment Endpoint: Used the captured order ID and passed the access token in Auth header to complete the payment.

Step 4: Run the Flow

After choosing the preferred environment, I saved everything and ran the whole chain.

Result? EchoAPI executed the flow step by step, showing me where things passed or failed.

This is a game-changer; instead of manually juggling values between requests, everything flows automatically.

EchoAPI vs Postman & Thunder Client: AI Features Comparison

When it comes to developer tools, positioning matters, not just what features you have, but how they stand out and why someone should choose your solution over existing ones. Let’s break down how EchoAPI compares with Postman and Thunder Client.

Postman: AI Features & Strengths

Postman has long been the industry leader for API testing and collaboration, and over time, they’ve been adding AI capabilities. Some highlights include:

• Postbot (AI Assistant): Helps debug APIs, write tests, and analyze large responses or datasets with ease.
• AI Agent Builder: Lets you build agent-like workflows by combining AI models with APIs. You can design drag-and-drop visual workflows, use templates, and even tap into Postman’s growing network of APIs and MCP servers.
• Flows, MCP & AI Developer Tools: Postman supports experiments with AI models, evaluating multiple LLMs, generating prompts, and building test suites.
• Autocomplete, Suggestions & Docs Assistance: Useful for writing tests, analyzing large responses, and keeping documentation in sync.

Limitations:

• Test-case generation isn’t fully automatic: Postbot can help, but often requires manual tweaking.
• Workflows like chaining APIs, extracting variables, or setting up environments still require a lot of manual setup.
• Postman’s depth comes with complexity, meaning a steeper learning curve and heavier overhead for new users.

Thunder Client: AI Features & Strengths

Thunder Client takes a different approach: lightweight API testing inside VS Code. Its philosophy is simplicity and speed.

• Scriptless Testing & GUI Assertions: Instead of writing code, you can define tests via dropdowns and GUI selectors (e.g., status codes, response fields).
• Core Features: Collections, environments, request history, and local storage — all the basics you need for quick API testing.
• AI Integration (Early Stages): Thunder Client has announced AI-generated tests as “coming soon”, meaning their AI feature set is still developing.
• CI/CD & Git Sync: Useful for teams to collaborate, share collections, and integrate tests into workflows.

Limitations:

• AI support is limited and still maturing.
• Not ideal for complex workflows like chained requests or dynamic variable management.
• Lacks no-code flow builders or advanced automation beyond simple assertions.

EchoAPI’s Edge

Here’s where EchoAPI differentiates itself: AI isn’t just an add-on; it’s the engine of the testing workflow.

At a Glance

• Postman: Best for power users who want deep control, integrations, and community-driven workflows.
• Thunder Client: Great for developers who prefer simplicity, speed, and testing inside VS Code.
• EchoAPI: Combines the best of both worlds: advanced AI automation, full workflow chaining, variable management, and a friendly UI that works for both coders and non-coders.

Why This Comparison Matters

There are plenty of API tools out there. But the real value is in how much time you save, how many bugs you prevent, and how easily your team can scale test coverage.

• If you’re working on a big codebase, managing dozens of endpoints, or testing chained workflows, EchoAPI gives you automation that cuts down boilerplate and speeds up debugging.
• If you’re working on a small project, Thunder Client might be enough for its simplicity. If you want the biggest ecosystem and integrations, Postman is still a solid choice.
• But if you want AI-native testing that actually handles the heavy lifting, EchoAPI offers a strong alternative; one that’s already delivering mature, practical automation today.

Why This Matters

EchoAPI’s AI features literally compress hours of manual work into seconds.

• AI Test-case generator: No need to brainstorm test cases.
• AI Scripts: No need to code repetitive test scripts.
• AI Assertions: Validation without writing manual checks.
• Chained APIs: End-to-end workflow testing in one go.

For developers, it means faster testing and less frustration. For QA engineers, it means scaling test coverage without extra effort. For teams, it means fewer bugs slip into production.

Results Summary

After spending time with EchoAPI’s AI-powered tools, here’s my honest takeaway:

• The auto test-case generation is the highlight; it gives you complete coverage in seconds.
• The AI script & assertion generator saves tons of time when building complex validations.
• The multi-API chaining feels like real-world automation without the complexity of writing a giant test framework yourself.

Wrapping Up

EchoAPI with AI isn’t just another API client. It’s like having a QA assistant sitting beside you.

Instead of writing, organizing, and debugging everything manually, you just guide the AI and let it handle the heavy lifting.

That’s my full walkthrough of EchoAPI’s AI features. Have you tried AI-assisted testing yet?

That’s it for now…

Keep Coding✌✌

In the world of artificial intelligence, especially large language models (LLMs), there’s a quiet revolution happening. It’s called Model Context Protocol, or simply MCP. You may have encountered the term in AI communities or tool integrations, but what exactly is MCP, and why should you care?

Let’s break it down, step by step, and show you how this simple yet powerful concept is solving one of the biggest headaches in AI, which is accessing real-time web data.

What Is MCP (Model Context Protocol)?

Imagine you’ve trained a brilliant AI that knows history, science, programming, and can even write poetry. But ask it what’s trending on Twitter or what the latest YouTube comments are on a viral video, and you’ll likely get outdated, static responses. Why? Because LLMs are not built for real-time web interaction out of the box.

That’s where MCP steps in.

MCP is an open standard that acts as a bridge between AI agents (like Claude, GPT, etc.) and real-time data sources like websites, APIs, or databases. Think of it as a universal translator that allows AI models to interact with the constantly-changing web securely and efficiently.

Instead of hardcoding access to different websites or APIs, MCP standardizes the way AI tools request data. It makes live data scraping and interaction much more streamlined and predictable — no more breaking scripts or bot detection errors.

Why Do LLMs Struggle with Real-Time Data?

Let’s address the elephant in the room.

LLMs like Claude, ChatGPT, and others are trained on massive datasets, but that training is static. This means the AI only knows what it was trained on. If you ask it for stock prices, breaking news, or fresh YouTube comments, it simply doesn’t know. Even worse, if it tries to guess, it might give you hallucinated or flat-out wrong answers.

Sure, you could plug in some APIs or attempt to write your own scraping scripts. But anyone who’s tried this knows how quickly you hit roadblocks:

• JavaScript rendering
• CAPTCHA and anti-bot detection
• Proxy rotation and management
• Data formatting inconsistencies
• Rate limits
• And much more…

To obtain a list of recent comments or product prices, you find yourself immediately immersed in backend development.

A Real-World Example: When LLMs Fail

Let me give you a quick example.

I asked Claude to fetch the latest comments from a YouTube video. It understood the request just fine… but couldn’t get the data. That’s because it doesn’t have native access to YouTube’s dynamic content. Claude can only interpret requests, but it can’t execute scraping logic on its own.

This is a classic scenario where even the smartest LLMs fall short without real-time access tools.

Building Your Own MCP? It’s Harder Than It Looks

Technically, you can build your own MCP setup. You’d need to:

• Set up a scraping infrastructure.
• Manage rotating proxies.
• Handle headless browser environments.
• Deal with dynamic web rendering.
• Write adapters to plug data into your AI agent.

Sounds doable at first, right? But trust me, you’ll soon find yourself debugging edge cases and fighting CAPTCHAs, all for a task that should feel simple. What starts as a weekend project quickly turns into a full-time scraping job.

That’s why most developers and AI researchers look for managed solutions.

Bright Data’s MCP: Your AI’s Web Gateway

This is where Bright Data’s MCP changes the game.

Bright Data, a leading data collection platform, has created a plug-and-play MCP service that gives your AI agent real-time access to the web without dealing with any of the complexity.

Here’s what it offers:

• Unblockable access to websites like Amazon, YouTube, LinkedIn, Instagram, X (Twitter), Facebook, TikTok, Zillow, Reddit, and even Google.
• Built-in proxy handling — no need to rotate or manage IPs.
• Headless browser support — for rendering JavaScript-heavy pages.
• Remote browser APIs — so your agent can interact with pages like a real user.
• Plenty of ready-made scraping tools — for different websites and use cases.

Everything is handled under the hood, and all you need to do is configure the access; no scraping code required.

Let’s See It in Action

I ran the same prompt with more tasks using Bright Data’s MCP: “Fetch the latest comments from a YouTube video and provide that data in a json file”.

You can see that it worked and that too without any hassle.

Behind the scenes, Bright Data’s tools were doing all the heavy lifting: launching a browser, unlocking the page, pulling the data, formatting it, and sending it back to the AI agent.

No errors. No retries. Just results.

How to Integrate Bright Data’s MCP with Claude Desktop

Okay, now let’s go through how to actually connect Bright Data’s MCP with Claude Desktop. It’s simpler than you might think.

Step 1: Install Node.js

Make sure Node.js is installed on your system. You’ll need the npx command to run the MCP server.

Step 2: Create a Bright Data Account

Head over to Bright Data and sign up. Once your account is ready, log in to the user dashboard.

Step 3: Prepare the Claude Desktop Configuration

1. Open the Claude desktop app
2. Click on File → Settings → Developer → Edit File.
3. This opens a file named claude-desktop-config.json.
4. Open it in your favorite text editor.

Step 4: Add MCP Configuration

Now, go to the GitHub repository provided by Bright Data and copy the MCP config code.

Paste that into the claude-desktop-config.json file.

Step 5: Insert Your Real MCP Credentials

Once you’ve pasted the configuration block into the claude-desktop-config.json file, it’s time to replace the placeholders with your actual values. This is what will connect your Claude Desktop app to Bright Data’s MCP system.

Here’s how to do it:

Head to Your Bright Data Dashboard
Log in to your Bright Data account and navigate to the Proxies & Scraping section. This is where you’ll manage the tools needed to enable real-time scraping.

Create a Scraping Zone
Click the “Add” button and choose “Web Unlocker API” as your tool. Once created, you’ll see a dashboard showing your new zone.

Copy the API Key
You’ll find your API key in the “Account Settings” section. Alternatively, Bright Data may have emailed it to you when you signed up. Either way, copy this key and paste it into the relevant "API_TOKEN" field in your config file.

Add the Web Unlocker Zone Name
Still in your dashboard, find the name of the Web Unlocker zone you just created. Copy it and paste it into the "WEB_UNLOCKER_ZONE" field in your configuration.

Enable Remote Browsing with Browser API
Want to supercharge your scraping setup with headless browser access? You can!
Just add a Browser API by clicking “Browser API” in the “Add” section.

• Give it a name — something like my-browser-api.
• After it’s created, you’ll see a string.
• Copy just the key part (not the full URL) and paste it into the "BROWSER_AUTH" field in your config.

This optional step enables your AI agent to interact with websites that require full browser emulation, which is perfect for scraping JavaScript-heavy pages or logging into websites.

Step 6: Restart Claude

Save the configuration file, quit Claude Desktop, and restart the app.

Once you open it again, you’ll see that all Bright Data MCP tools are now available to use directly within Claude. That’s it, now you’re ready to start scraping real-time web data with zero friction.

The Big Picture

The MCP isn’t just another API — it’s a protocol that aims to standardize how AI tools interact with dynamic data sources. And with platforms like Bright Data offering powerful plug-and-play integrations, you can start building real-time, context-aware agents without worrying about the plumbing.

Instead of writing your own scrapers, debugging browser sessions, or juggling proxies, you can focus on what matters: creating intelligent workflows that adapt to live information.

Whether you’re working on:

• Competitive intelligence
• Social media monitoring
• Real-time news summaries
• E-commerce pricing trackers
• AI research assistants

…MCP opens up a whole new world of possibilities.

Conclusion

Large Language Models are impressive — but without live data, they’re limited. MCP is the missing puzzle piece, and Bright Data’s implementation makes it incredibly easy to adopt.

If you’re tired of watching your AI fumble on basic real-time tasks, give MCP a shot. It’s fast, powerful, and surprisingly easy to set up. And if you’re using Claude Desktop, the whole thing takes under 10 minutes to integrate.

Your AI just got a whole lot smarter.

That’s all for now.

Keep Coding✌✌

You might have heard of Thunder Client, a REST API client extension for Visual Studio Code that allows developers to test APIs. Thanks to its lightweight nature, it quickly became the first choice for developers worldwide.

Thunder Client was once completely free, but that’s no longer the case. It has now transitioned to a paid model, pushing many key features behind a paywall. With the free plan offering limited functionality, users have few options left.

Thunder Client used to be a one-stop destination for developers to perform basic API testing and debugging. However, with the shift to a paid model, developers are increasingly turning to alternatives like Postman. Among these, EchoAPI for Visual Studio Code stands out as a strong and worthy alternative.

Why EchoAPI is a Better Alternative?

While EchoAPI and Thunder Client share some common features, EchoAPI excels in the following areas:

• Completely Free: EchoAPI is entirely free to use, with a commitment to remain so.
• Ultra-Lightweight: Its minimalistic design ensures that it doesn’t burden your system.
• No Login Required: Start testing immediately without the need for sign-ups or logins.
• Scratchpad Feature: Dive straight into testing APIs without any setup.
• Postman Script Compatibility: Migrating from Postman? No problem! EchoAPI supports Postman script syntax, so you don’t need to learn anything new.
• Collaboration Ready: Enjoy team workflows for shared testing without extra costs.
• Unlimited Requests: There’s no limit to the number of requests you can send.
• Unlimited Collection Runs: Run your collections as many times as needed, without restrictions.
• Local Storage: Store your data securely and access it from anywhere.

Let’s explore these features in detail.

Install EchoAPI

Getting started with EchoAPI is easy. Simply install it from the Visual Studio Code extensions marketplace:

Search for “EchoAPI”. Click on the first result and hit Install.

Once installed, the EchoAPI logo will appear in the sidebar, giving you access to the extension’s user interface (UI).

Now we can start testing our APIs. Let’s take a tour of the UI and explore EchoAPI functionalities.

Get Started with EchoAPI

EchoAPI provides demo APIs to help you explore its features. Let’s use these demo APIs for testing and debugging before moving on to testing our own.

For example, the first API in the “Samples” collection creates a new user with fields like id, username, firstName, lastName, email, password, phone, and userStatus.

Let’s tweak this data and send a request to the server.

After sending the request, we can see a successful response (HTTP status code 200).

Here, we can also test Server-sent Events (SSE) requests, which are used to send real-time updates to clients. These are often used in web applications for real-time notifications, live data feeds, or status updates.

Running Collections Without Limit

One of EchoAPI’s standout features is its unlimited collection runs. Here’s how you can run a collection:

Navigate to the Tests tab and select the collection or folder containing your requests.

In this case, we selected the “Samples” collection and then clicked on the Run All button. It brings up this interface where we can set configurations to the test.

You can configure the following options:

• Iterations: Specify how many times the test should execute.
• Intervals: Set time intervals between each request.
• Data: Upload a .csv file containing test data.
• Environment: Choose the testing environment with pre-configured environment variables.

In this case, the iterations are set to 3, and the interval between the execution of each request is set to 1000 ms (1 second).

Once configured, click Run to execute the collection. This will start executing requests with the specified configurations.

A report is generated showing the stats of the performed test and if we click on any request, we’ll see an individual report of the request.

Setting up Environment Variable

We can set up environment variables like API keys, URLs, authentication tokens, etc. Depending on the sensitivity of the data, these variables can be used in the header or body of the request.

Let’s see how we can set up an environment in EchoAPI.

Access the environment setup interface via the three dots menu in the top left corner or directly from the request interface.

Click on the “New Environment” button to set up a new environment.

We can set a name for the environment, the base URL of the server, and environment variables.

Testing APIs

Here’s a practical example using a Python FastAPI application with three routes. We’ll test these routes using EchoAPI.

from fastapi import FastAPI, HTTPException, Depends
from pydantic import BaseModel
from typing import List
from fastapi.security import OAuth2PasswordBearer
import jwt
import datetime

app = FastAPI()
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token")

key = 'secretkey'

books = []
current_id = 1

class Book(BaseModel):
    title: str
    author: str
    price: float

class BookOut(Book):
    id: int

def authenticate_user(token: str = Depends(oauth2_scheme)):
    try:
        payload = jwt.decode(token, key, algorithms=["HS256"])
        return payload
    except jwt.ExpiredSignatureError:
        raise HTTPException(status_code=401, detail="Token has expired")
    except jwt.InvalidTokenError:
        raise HTTPException(status_code=401, detail="Invalid token")

@app.post("/token")
def get_token():
    expiration = datetime.datetime.now(datetime.timezone.utc) + datetime.timedelta(hours=1)
    token = jwt.encode({"exp": expiration}, key, algorithm="HS256")
    return {"access_token": token, "token_type": "bearer"}

@app.post("/books", response_model=BookOut)
def create_book(book: Book, user: dict = Depends(authenticate_user)):
    global current_id
    new_book = book.model_dump()
    new_book["id"] = current_id
    books.append(new_book)
    current_id += 1
    return new_book

@app.get("/books", response_model=List[BookOut])
def list_books(user: dict = Depends(authenticate_user)):
    return books

Setting up EchoAPI for Testing

First, we can create a folder, let’s say Books, to make our requests more organized.

Next, we need to create individual requests within the “Books” folder.

We created three requests as shown in the image below.

According to the code, we need to generate an authentication token, so we need to send a POST request to http://127.0.0.1:8000/token to obtain an auth token and then we can use this token in other requests to authenticate a user.

Authentication

If we try to hit this URL (http://127.0.0.1:8000/books) to create a book without passing the auth token, we’ll get an error in the response.

We need to pass the previously generated auth token in the “Auth” section.

EchoAPI supports various authentication methods such as API Key, Basic Auth, and JWT Bearer. You can choose the type of authentication required in your project.

Debugging APIs

We can debug the APIs from the “Post-response” section. In this section, we can write custom scripts (Postman script) and set assertions to debug APIs, extract variables for dynamic testing, and simulate delays in API execution.

Let’s perform a simple debugging. We are setting an assertion for the response code equal to 200 and deliberately making a mistake in the request.

We can see detail in the response indicating that the price field is missing and it returned the response code 422, which is not equal to 200, so the assertion failed.

This is not limited to response code only, we can set assertions for different target objects.

More Features

Server sent event Requests:

Server-sent events (SSE) enable a server to push real-time updates to the client over a single HTTP connection. They are widely used for real-time notifications, live data feeds, status updates, or chat applications.

With Thunder Client, creating and testing SSE requests is locked behind a paywall. This makes it less appealing for developers who rely on free tools for basic functionality.

EchoAPI, however, provides full support for SSE requests free of charge. Here’s how EchoAPI simplifies SSE testing:

1. Ease of Setup: You can create and test SSE requests directly within EchoAPI’s user interface, without any advanced configuration.
2. Real-Time Stream Support: It allows you to see real-time data streams as they are sent from the server.
3. No Cost: Unlike Thunder Client, there are no charges or restrictions for using this feature.

For example, you can set up an SSE endpoint in your API, like /notifications, and use EchoAPI to connect to it. EchoAPI will display live updates sent by the server in a clean and intuitive interface.

Imports data from cURL:

cURL is a command-line tool used to send HTTP requests. Developers often use cURL commands to test APIs quickly in a terminal. However, when transitioning to a GUI-based tool like EchoAPI, manually re-entering the details of API requests can be tedious and error-prone.

Here’s how it works:

1. Copy cURL Command: Simply copy the cURL command from your terminal or documentation.
2. Paste in EchoAPI: Select the Import cURL option in EchoAPI, and paste the cURL command.
3. Automatic Conversion: EchoAPI automatically parses the command and converts it into a structured API request within its interface.

Import data from Postman:

Postman is one of the most popular API testing tools, often used for creating and managing collections of API requests. If you’re moving from Postman to EchoAPI, re-creating collections from scratch can be a daunting task.

Here’s how it works:

1. Export from Postman: In Postman, go to the collection you want to migrate, click on the options menu (three dots), and choose Export. Postman will generate a JSON file containing all the details of the collection.
2. Import to EchoAPI: Select the Import from Postman option in EchoAPI, and upload the Postman JSON file.
3. Seamless Integration: EchoAPI will parse the file and recreate the collection, including all requests, headers, parameters, and body configurations.

Team Collaboration and Data Sync

To collaborate with the team and sync data in EchoAPI, we need to sign up. After signing up for EchoAPI, we can push data to EchoAPI storage easily.

Click on the cloud icon and then select the workspace folder where the data will be stored and then select the collection to push to EchoAPI.

Now we can easily access the data from the EchoAPI desktop app or Webapp.

We can invite our team members through URL in the EchoAPI web app or desktop app. Click on the “Invite” button in the top right corner, and then click on the “Copy Link” button to copy the invitation link.

Conclusion

While Thunder Client once ruled as a lightweight API testing extension for Visual Studio Code, its shift to a paid model has left many developers searching for viable alternatives. EchoAPI emerges as a strong contender, offering a feature-rich, completely free, and ultra-lightweight solution tailored for seamless API testing and debugging.

With its no-login requirement, Postman script compatibility, limitless testing capabilities, and team collaboration features, EchoAPI sets itself apart as a powerful tool for both individual developers and teams. Its intuitive interface, support for server-sent events, and extensive customization options make it a go-to choice for API testing directly within VS Code.

If you’re looking for an efficient, no-cost alternative to Thunder Client that doesn’t compromise on functionality, EchoAPI is worth exploring.

That’s all for now.

Keep Coding✌✌.

FastAPI is a fast and modern web framework known for its support for asynchronous REST API and ease of use.

In this article, we’ll see how to stream videos on frontend in FastAPI.

StreamingResponse

Stream Local Video

FastAPI provides a StreamingResponse class that is dedicated to streaming purposes. The StreamingResponse class takes a generator or iterator and streams the response.

Here’s a simple example of streaming local video to the browser.

# localvid.py
from fastapi import FastAPI
from fastapi.responses import StreamingResponse

app = FastAPI()

# Video path
vid_path = 'sample_video.mp4'

# Function to stream local video
def stream_local_video():
    with open(vid_path, 'rb') as vid_file:
        yield from vid_file

# Path to stream video
@app.get("/")
def video_stream():
    return StreamingResponse(stream_local_video(), media_type='video/mp4')

We imported the StreamingResponse class from the fastapi.responses module.

In the video_stream() path operation function, we returned the response using StreamingResponse. We passed the generator function stream_local_video() and media_type as an argument to the StreamingResponse class.

The generator function stream_local_video() reads the bytes of the video and yield from iterates over the bytes and each part iterated is then yielded.

The following command will run the server and stream the video on http://127.0.0.1:8000/.

> fastapi dev localvid.py

 ╭────────── FastAPI CLI - Development mode ───────────╮
 │                                                     │
 │  Serving at: http://127.0.0.1:8000                  │
 │                                                     │
 │  API docs: http://127.0.0.1:8000/docs               │
 │                                                     │
 │  Running in development mode, for production use:   │
 │                                                     │
 │  fastapi run                                        │
 │                                                     │
 ╰─────────────────────────────────────────────────────╯

Stream Online Video

# onlinevid.py
from fastapi import FastAPI
from fastapi.responses import StreamingResponse
import requests

app = FastAPI()

# Video URL
vid_url = 'https://cdn.pixabay.com/video/2023/07/28/173530-849610807_large.mp4'

# Function to stream online video
def stream_online_video(url):
    response = requests.get(url, stream=True)
    for portion in response.iter_content(chunk_size=1024*1024):
        yield portion

# Path to stream video
@app.get("/")
def video_stream():
    return StreamingResponse(stream_online_video(vid_url), media_type='video/mp4')

In this example, we used the requests library to fetch the content of the video from the URL and we set the stream=True (avoids reading the video at once into memory). Then we iterated and yielded the video content in chunks (1024 bytes at a time).

When we run the server, it will serve the video from the URL.

Instead of a hardcoded URL, we can specify the URL in the endpoint.

from fastapi import FastAPI
from fastapi.responses import StreamingResponse
import requests

app = FastAPI()

# Function to stream online video
def stream_online_video(url):
    response = requests.get(url, stream=True)
    for portion in response.iter_content(chunk_size=1024*1024):
        yield portion

# Path to stream video
@app.get("/")
def video_stream(url):
    return StreamingResponse(stream_online_video(url), media_type='video/mp4')

In this example, we modified the path operation function video_stream() to accept a URL.

Now we can specify the URL of the video in the endpoint in the following format.

http://127.0.0.1:8000/?url=https://cdn.pixabay.com/video/2023/07/28/173530-849610807_large.mp4

We can also make the path operation function asynchronous using async.

FileResponse

Stream Local Video

The FileResponse class simply takes a file and streams the response.

from fastapi import FastAPI
from fastapi.responses import FileResponse

app = FastAPI()

# Video path
vid_path = 'video.mp4'

# Path to stream video
@app.get("/")
def video_stream():
    return FileResponse(vid_path, media_type='video/mp4')

In the above example, we simply passed a video file in the FileResponse class and returned the response.

We didn’t read and iterate over the bytes of the video to stream it like we did in the case of StreamingResponse.

The FileResponse class is ideal for relatively small or medium-sized files as it loads the file in the memory. Large files will consume more memory.

Stream Online Video

Streaming video from the URL using FileResponse isn’t the same as streaming the local video. As we know, the FileResponse class takes a file and streams it.

from fastapi import FastAPI
from fastapi.responses import FileResponse
import requests
import os

app = FastAPI()

# Video URL
vid_url = 'https://cdn.pixabay.com/video/2023/07/28/173530-849610807_large.mp4'
local_vid = 'sample_video.mp4'

# Function to save video from URL
def save_as_file(url, path):
    if not os.path.exists(path):
        response = requests.get(url)
        with open('sample_video.mp4', 'wb') as vid:
            vid.write(response.content)

save_as_file(vid_url, local_vid)

# Path to stream video
@app.get("/")
def video_stream():
    return FileResponse(local_vid, media_type='video/mp4')

In this example, instead of streaming the local video, we streamed the video from the URL using FileResponse.

This isn’t the best practice because we first saved the video from the URL in the local machine and then streamed the video.

The FileResponse class can be best utilized for local files, not web content.

That was all about streaming video directly to the browser but we don’t want to do that every time, instead, we want the video to be streamed on our website’s landing page.

Stream Video on Frontend

So, how to stream video on the frontend using FastAPI? We need to create a frontend using HTML and then stream the video.

First, create a directory named serve_video or whatever you want to name it, and create the following files and sub-directories.

serve_video/
   - templates/
      - display_video.html
   - app.py

The app.py file will contain our backend code and the display_video.html file will contain frontend code.

app.py

from fastapi import FastAPI, Request
from fastapi.responses import StreamingResponse, HTMLResponse
from fastapi.templating import Jinja2Templates
import requests

app = FastAPI()
templates = Jinja2Templates(directory="templates")

vid_urls = [
    "https://cdn.pixabay.com/video/2023/07/28/173530-849610807_large.mp4",
    'https://cdn.pixabay.com/video/2024/03/31/206294_large.mp4',
    'https://cdn.pixabay.com/video/2023/10/11/184510-873463500_large.mp4',
    'https://cdn.pixabay.com/video/2023/06/17/167569-837244635_large.mp4'
]

# Stream the video from the URL
def stream_video(url):
    response = requests.get(url, stream=True)
    for portion in response.iter_content(chunk_size=1024*1024):
        yield portion

# Endpoint to render the HTML template with the video player
@app.get("/", response_class=HTMLResponse)
async def video_template(request: Request):
    return templates.TemplateResponse("display_video.html", {"request": request})

# Endpoint to stream the video
@app.get("/video/{video_id}")
async def video_stream(vid_id: int):
    if 0 <= vid_id < len(vid_urls):
        return StreamingResponse(stream_video(vid_urls[vid_id]), media_type="video/mp4")
    else:
        return HTMLResponse("Video not found", status_code=404)

In this example, we are streaming multiple videos on the frontend. We have a list of video URLs stored within vid_urls.

We have a stream_video() generator function that yields the video in smaller chunks.

We created an asynchronous path operation function video_template() that returns a response from HTML (@app.get("/", response_class=HTMLResponse)) file.

We are serving HTML from a template stored within the templates directory, so, we set up a Jinja2 template directory where HTML templates are stored (templates = Jinja2Templates(directory="templates")). This is where FastAPI will look for .html files.

Then we returned the response using templates.TemplateResponse("display_video.html", {"request": request}). We passed our HTML template display_video.html and along with it, a dictionary containing Request object ({"request": request}). This Request object provides information about the incoming HTTP request, such as headers, cookies, and URLs, which can be accessed within the HTML template.

Next, we created an endpoint (@app.get("/video/{video_id}")) to stream individual videos based on the ID in the vid_ulrs. The video_stream(vid_id: int) path operation functions accept the index of the video in vid_urls.

Within the video_stream(), the if condition checks if the vid_id is within the range, if not, then raises an error otherwise the video is streamed based on the specified index.

display_video.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Stooooockzz</title>
</head>
<body>
    <h1>What we do?</h1>
    <p>We create awesome stock videos for free usage</p>
    <h3>Video Samples</h3>
    <div style="display: flex; justify-content: space-evenly;">
        <video width='20%' height='30%' style="border-radius: 10px;" controls autoplay>
            <source src="/video/0" type="video/mp4">
        </video>
        <video width='20%' height='30%' style="border-radius: 10px;" controls autoplay>
            <source src="/video/1" type="video/mp4">
        </video>
        <video width='20%' height='30%' style="border-radius: 10px;" controls autoplay>
            <source src="/video/2" type="video/mp4">
        </video>
        <video width='20%' height='30%' style="border-radius: 10px;" controls autoplay>
            <source src="/video/3" type="video/mp4">
        </video>
    </div>
</body>
</html>

This HTML file contains multiple <video> tags with the source pointing to the /video/{video_id} endpoint that streams the video based on ID.

Here, we passed <source src="/video/0" type="video/mp4"> within the <video> tag that represents streaming the first video from the vid_urls (in app.py) list. Similarly, we specified the same source but changed the ID within each <video> tag.

> fastapi dev app.py

Upon running the server using the above command, we get the following response on the frontend.

Conclusion

We’ve used StreaminResponse and FileResponse classes to stream local and web videos directly on the browser, and along with this we’ve also streamed multiple videos using StreamingResponse which was rendered using HTML files on the browser.

In this article, we’ve used URLs of the video residing on the internet but you can also fetch URLs from databases, local files, disks, etc.

That’s all for now.

Keep Coding✌✌.

Different Ways to Stream Videos on the Frontend in FastAPI was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Both functions have a common objective: to execute Python code from the string input or code object. Even though they both have the same objective, exec() and eval() are not the same.

Return Values

The exec() function doesn't return any value whereas the eval() function returns a value computed from the expression.

expression = "3 + 5"

result_eval = eval(expression)
print(result_eval)

result_exec = exec(expression)
print(result_exec)

When we run this code, we’ll get 8 and None. This means that eval(expression) evaluated the result and stored it inside result_eval whereas exec(expression) returned nothing, so the value None gets stored into result_exec.

8
None

Execution

The exec() function is capable of executing multi-line and multi-statment code, it doesn't matter whether the code is simple, complex, has loops and conditions, classes, and functions.

On the other hand, the eval() function is restricted to executing the single-line code which might be a simple or complex expression.

expression = """
for x in range(5):
    print(x, end=" ")
"""

exec(expression)
eval(expression)

Look at this code, we have a multi-line code that prints numbers up to the given range. The exec(expression) will execute it and display the result but the eval(expression) will display the error.

0 1 2 3 4
SyntaxError: invalid syntax

However, if we convert the same expression into a single line as the following, the eval(expression) will not throw any error.

expression = "[print(x, end=' ') for x in range(5)]"
eval(expression)

--------------------
0 1 2 3 4

Summary

🏆Other articles you might be interested in if you liked this one

✅Execute complex code blocks from string input using exec() function.

✅Template inheritance in Flask.

✅Type hints in Python — Callable objects, Return values, and more?

✅Best Practices: Positional and Keyword Arguments in Python

✅Yield Keyword in Python with Examples?

✅Create a WebSocket Server and Client in Python.

That’s all for now

Keep Coding✌✌

You must have used functions provided by the os module in Python several times in your projects. These could be used to create a file, walk down a directory, get info on the current directory, perform path operations, and more.

In this article, we’ll discuss the functions that are as useful as any function in the os module but are rarely used.

1. os.path.commonpath()

When working with multiple files that share a common directory structure, you might want to find the longest shared path. os.path.commonpath() does just that. This can be helpful when organizing files or dealing with different paths across environments.

Here’s an example:

import os

paths = ['/user/data/project1/file1.txt', '/user/data/project2/file2.txt']
common_path = os.path.commonpath(paths)
print("Common Path:", common_path)

This code will give us the common path shared by these two paths.

Common Path: /user/data

You can see that os.path.commonpath() takes a list of path names, which might be impractical to manually write them down.

In that case, it is best to iterate over all of the directories, subdirectories, and file names and then look for the common path.

import os

def get_file_paths(directory, file_extension=None):
    # Collect all file paths in the directory (and subdirectories, if any)
    file_paths = []
    for root, dirs, files in os.walk(directory):
        for file in files:
            if file_extension is None or file.endswith(file_extension):
                file_paths.append(os.path.join(root, file))
    return file_paths


# Specify the root directory to start from
directory_path = 'D:/SACHIN/Pycharm/Flask-Tutorial'

# If you want to filter by file extension
file_paths = get_file_paths(directory_path, file_extension='.html')

# Find the common path among all files
if file_paths:
    common_path = os.path.commonpath(file_paths)
    print("Common Path:", common_path)
else:
    print("No files found in the specified directory.")

In this example, the function get_file_paths() traverses a directory from top to bottom and appends all the paths found in the file_paths list. This function optionally takes a file extension if we want to look out for specific files.

Now we can easily find the common path of any directory.

Common Path: D:\SACHIN\Pycharm\Flask-Tutorial\templates

2. os.scandir()

If you’re using os.listdir() to get the contents of a directory, consider using os.scandir() instead. It’s not only faster but also returns DirEntry objects, which provide useful information like file types, permissions, and whether the entry is a file or a directory.

Here’s an example:

import os

with os.scandir('D:/SACHIN/Pycharm/osfunctions') as entries:
    for entry in entries:
        print(f"{entry.name} : \n"
              f">>>> Is File: {entry.is_file()} \n"
              f">>>> Is Directory: {entry.is_dir()}")

In this example, we used os.scandir() and passed a directory and then we iterated over this directory and printed the info.

.idea : 
>>>> Is File: False 
>>>> Is Directory: True
main.py : 
>>>> Is File: True 
>>>> Is Directory: False
sample.py : 
>>>> Is File: True 
>>>> Is Directory: False

3. os.path.splitext()

Let’s say you’re working with files and need to check their extension, you can get help from os.path.splitext() function. It splits the file path into the root and extension, which can help you determine the file type.

import os

filename = 'report.csv'
root, ext = os.path.splitext(filename)
print(f"Root: {root} \n"
      f"Extension: {ext}")

Output

Root: report 
Extension: .csv

Look at some cases where paths can be weird, at that time how os.path.splitext() works.

import os

filename = ['.report', 'report', 'report.case.txt', 'report.csv.zip']
for idx, paths in enumerate(filename):
    root, ext = os.path.splitext(paths)
    print(f"{idx} - {paths}\n"
          f"Root: {root} | Extension: {ext}")

Output

0 - .report
Root: .report | Extension: 
1 - report
Root: report | Extension: 
2 - report.case.txt
Root: report.case | Extension: .txt
3 - report.csv.zip
Root: report.csv | Extension: .zip

4. os.makedirs()

There’s already a frequently used function that allows us to create directories. But what about when you create nested directories?

Creating nested directories can be a hassle with os.mkdir() since it only makes one directory at a time. os.makedirs() allows you to create multiple nested directories in one go, and the exist_ok=True argument makes sure it doesn’t throw an error if the directory already exists.

import os

os.makedirs('project/data/files', exist_ok=True)
print("Nested directories created!")

When we run this program, it will create specified directories and sub-directories.

Nested directories created!

If we run the above program again, it won’t throw an error due to exist_ok=True.

5. os.replace()

Similar to os.rename(), os.replace() moves a file to a new location, but it safely overwrites any existing file at the destination. This is helpful for tasks where you’re updating or backing up files and want to ensure that old files are safely replaced.

import os

os.replace(src='main.py', dst='new_main.py')
print("File replaced successfully!")

In this code, main.py file will be renamed to new_main.py just as os.rename() function but this operation is like take it all or nothing. It means the file replacement happens in a single, indivisible step, so either the entire operation succeeds or nothing changes at all.

File replaced successfully!

6. os.urandom()

For cryptographic purposes, you need a secure source of random data. os.urandom() generates random bytes suitable for things like generating random IDs, tokens, or passwords. It’s more secure than the random module for sensitive data.

os.urandom() uses randomness generated by the operating system you are using from various resources to make bytes (data) unpredictable.

In Windows, it uses BCryptGenRandom() to generate random bytes.

import os

secure_token = os.urandom(16)  # 16 bytes of random data
print("Secure Token:", secure_token)
#Making it human-readable
print("Secure Token:", secure_token.hex())

Output

Secure Token: b'\x84\xd6\x1c\x1bKB\x7f\xcd\xf6\xb7\xc4D\x92z\xe3{'
Secure Token: 84d61c1b4b427fcdf6b7c444927ae37b

7. os.path.samefile()

The os.path.samefile() function in Python is used to check if two paths refer to the same file or directory on the filesystem. It’s particularly helpful in scenarios where multiple paths might point to the same physical file, such as when dealing with symbolic links, hard links, or different absolute and relative paths to the same location.

import os

is_same = os.path.samefile('/path/to/file1.txt', '/different/path/to/symlink_file1.txt')
print("Are they the same file?", is_same)

os.path.samefile() is designed to return True only if both paths reference the same file on disk, such as a file that’s hard-linked or symlinked to the same data on the filesystem.

8. os.path.relpath()

os.path.relpath() is a computation function that computes the relative path between two paths. This is particularly useful when building file paths dynamically or working with relative imports.

Consider the following example:

import os

# Target file path
target_path = "D:/SACHIN/Pycharm/osfunctions/project/engine/log.py"
# Starting point
start_path = "D:/SACHIN/Pycharm/osfunctions/project/interface/character/specific.py"

relative_path = os.path.relpath(target_path, start=start_path)
print(relative_path)

In this example, we have target_path which contains a path where we have to navigate and start_path contains a path from where we have to start calculating the relative path to target_path.

When we run this, we get the following output.

..\..\..\engine\log.py

This means we have to go up three directories and then down to engine/log.py.

9. os.fsync()

When we perform a file writing (file.write()) operation, the data isn’t saved to disk instantly instead the data is saved into the system’s buffer and if something unexpected happens before writing the data to the disk, the data gets lost.

os.fsync() forces the data to be written, ensuring data integrity. It’s especially useful in logging or when writing critical data that must not be lost.

import os

with open('data.txt', 'w') as f:
    f.write("gibberish!")
    os.fsync(f.fileno())  # Ensures data is written to disk

os.fsync(f.fileno()) is called to make sure the data is immediately written to the disk and not left in the buffer.

os.fsync() takes file descriptor that’s why we passed f.fileno() which is a unique integer assigned by the system to the file on which we are operating.

10. os.get_terminal_size()

If you’re creating CLI tools, formatting the output to fit the terminal width can make the output cleaner. os.get_terminal_size() gives you the current terminal width and height, making it easy to dynamically format content.

import os

size = os.get_terminal_size()
print(f"Terminal Width: {size.columns}, Terminal Height: {size.lines}")

When we run this code in the terminal, we get the size of the terminal on which we are running this script.

PS > py sample.py
Terminal Width: 158, Terminal Height: 12

Note: You may get an error when directly running the script on IDE where the program doesn’t have access to the terminal.

🏆Other articles you might be interested in if you liked this one

✅Streaming videos on the frontend in FastAPI.

✅How to fix circular imports in Python.

✅Template inheritance in Flask.

✅How to use type hints in Python?

✅How to find and delete mismatched columns from datasets in pandas?

✅How does the learning rate affect the ML and DL models?

That’s all for now.

Keep Coding✌✌.

When you read the documentation of some functions you see a slash (/) and an asterisk (*) passed in the function definition. Why are they passed in a function?

Why Slash and Asterisk are Used?

The slash (/) and asterisk (*) are used to determine how an argument should pass when a function is called.

Simply said, the parameters on the left side of the slash (/) must be supplied as positional-only arguments, whereas the parameters on the right side can be passed as either positional or keyword arguments.

An asterisk (*) indicates that the parameters on the right side must be supplied as keyword-only arguments, while the parameters on the left side can be passed as positional or keyword arguments.

def func(pos1, pos2, /, pos_or_kwd, *, kwd1, kwd2):
      -----------    ----------     ----------
        |             |                  |
        |        Positional or keyword   |
        |                                - Keyword only
         -- Positional only

Slash and Asterisk in Function Parameter

Here’s a simple example to show that when slashes and asterisks appear in a function definition, then parameters are bound to positional-only and keyword-only arguments, respectively.

# Normal Function
def func_params(x, y, /, *, z):
    print(x, y, z)

You can conclude that x and y are positional-only parameters, while z is keyword-only. Let's experiment to see if the parameters are bound to positional-only and keyword-only arguments.

params = func_params(2, y=3, z=4)

The parameter x is supplied as a positional argument, while y and z are passed as keywords or named arguments. When you run the code, the following output will be produced.

Traceback (most recent call last):
  ...
    params = func_params(2, y=3, z=4)
             ^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: func_params() got some positional-only arguments passed as keyword arguments: 'y'

Python raises a TypeError indicating that the positional-only argument (y) was given as a keyword argument. If you simply supply y as a positional argument, the code will not generate any errors.

# Normal Function
def func_params(x, y, /, *, z):
    print(x, y, z)

# x & y passed as positional argument and z as a keyword argument
params = func_params(2, 3, z=4)

--------------------
2 3 4

Can Asterisk Be Used Ahead of Slash

The asterisk (*) must come after the slash (/). Now, you may be wondering if this is a rule.

You may think of it as a rule, if you use both a slash and an asterisk, the slash must come before the asterisk, otherwise, Python will throw a syntax error.

# Used asterisk before slash
def func_params(x, y, *, /, z):
    print(x, y, z)

params = func_params(2, 3, z=4)

The code has been modified, and the asterisk is used before the slash. When you run the code, you’ll get a syntax error.

...
    def func_params(x, y, *, /, z):
                             ^
SyntaxError: / must be ahead of *

Logically inserting an asterisk before the slash doesn’t make sense because the parameters on the right side of the asterisk are keyword-only, but the parameters on the left side of the slash are positional-only.

This will not work at all. Here is an example to demonstrate this situation.

# Used asterisk before slash
def func_params(x, y, *, a, b, /, z):
    print(x, y, a, b, z)

params = func_params(2, 3, a=5, b=6, z=4)

The parameters a and b are between the asterisk and the slash, making it unclear if they are positional or keyword-only parameters. This code will still throw a syntax error even after passing a and b as keyword arguments.

Using Either One of Slash (/) or Asterisk (*) in the Function’s Parameter?

You can utilise either one depending on the type of parameters you require, whether positional-only or keyword-only. Here’s an example showing the use of only a slash (/) in a function definition.

def func_params(pos1, pos2, /, pos_or_kw):
    print(pos1, pos2, pos_or_kw)

params = func_params(2, 3, pos_or_kw=4)

--------------------
2 3 4

The parameters pos1 and pos2 are positional-only parameters and pos_or_kw is a positional-or-keyword parameter.

Similarly, you can use a bare asterisk (*) also in the function definition.

def func_params(pos_or_kw, *, kw1, kw2):
    print(pos_or_kw, kw1, kw2)

params = func_params(4, kw1=3, kw2=2)

--------------------
4 3 2

Writing a Function that Accepts Positional-only Arguments

If you want to create a function or class that only accepts positional arguments, add the slash (/) at the end of the parameter list.

# Function that takes only positional arguments
def prescription(med1, med2, med3, /):
    print("Prescribed Meds:")
    print(f"Med 1: {med1}")
    print(f"Med 2: {med2}")
    print(f"Med 3: {med3}")

prescription("Paracetamol", "Omeprazole", "Ibuprofen")

--------------------
Prescribed Meds:
Med 1: Paracetamol
Med 2: Omeprazole
Med 3: Ibuprofen

The function prescription() takes three arguments: med1, med2, and med3. You can see that a slash (/) is written at the end of the parameters which makes them positional-only.

You’ll get an error if you try to pass a keyword argument to the function prescription().

prescription("Paracetamol", "Omeprazole", med3="Ibuprofen")
--------------------
Traceback (most recent call last):
  ...
    prescription("Paracetamol", "Omeprazole", med3="Ibuprofen")
TypeError: prescription() got some positional-only arguments passed as keyword arguments: 'med3'

Writing a Function that Accepts Keyword-only Arguments

You can use a bare asterisk (*) in a function definition to make the parameters on the right side keyword-only.

If you want a function that only accepts keyword parameters, simply include a bare asterisk (*) at the beginning of the function parameter list.

# Function that takes only keyword arguments
def prescription(*, med1, med2, med3):
    print("Prescribed Meds:")
    print(f"Med 1: {med1}")
    print(f"Med 2: {med2}")
    print(f"Med 3: {med3}")

prescription(med1="Paracetamol", med2="Omeprazole", med3="Ibuprofen")

-------------------
Prescribed Meds:
Med 1: Paracetamol
Med 2: Omeprazole
Med 3: Ibuprofen

The function prescription() now only accepts keyword arguments and disallows positional arguments.

Valid & Invalid Function Definitions

Here are some valid function definitions that can go well with slash and asterisk. Source

def f(p1, p2, /, p_or_kw, *, kw):
def f(p1, p2=None, /, p_or_kw=None, *, kw):
def f(p1, p2=None, /, *, kw):
def f(p1, p2=None, /):
def f(p1, p2, /, p_or_kw):
def f(p1, p2, /):

You are most likely familiar with the rules for defining positional and keyword parameters, and the function definitions mentioned above are valid in accordance with those rules.

However, the following function definitions are considered invalid because they aren’t defined as per the rules.

def f(p1, p2=None, /, p_or_kw, *, kw):
def f(p1=None, p2, /, p_or_kw=None, *, kw):
def f(p1=None, p2, /):

Once the parameter with default value has been defined, all subsequent parameters (optional for parameters after the asterisk) must be defined with the default value to avoid ambiguity in function calls.

Conclusion

The slash (/) and asterisk (*) determine how an argument should be passed when you call the function.

A slash (/) in the function definition indicates that the parameters on the left side must be treated as positional-only.

A bare asterisk (*) in function definition indicates that the parameters on the right side must be treated as keyword-only.

You can use either both of them or a single in the function definition. When you are using both slash and asterisk, the slash must be inserted before the asterisk.

🏆Other articles you might be interested in if you liked this one

✅Why if __name__ == “__main__” is used in Python programs?

✅What is the yield keyword in Python?

✅Create a WebSocket server and client in Python.

✅How do decorators in Python work and how to create a custom decorator?

✅What is __getitem__ method in Python class?

✅The map() function in Python for mapping a function to each item in the iterable?

That’s all for now

Keep Coding✌✌