DEV Community: Mario Semper

How AI Agents Pay for API Calls — And How to Verify They Did

Mario Semper — Tue, 17 Mar 2026 14:59:10 +0000

The x402 protocol just made machine-to-machine payments real. Here's what the verification layer looks like.

PayWatcher · March 2026 · 4 min read

HTTP has had a status code sitting unused for 30 years.

402: Payment Required.

It was reserved for a future where machines could pay for things directly. That future is here. Stripe and Coinbase are both building around x402 — a protocol that revives 402 to enable AI agents to pay for API calls in USDC, automatically, without a human in the loop.

An AI agent requests a resource. The server responds with 402. The agent pays in USDC. Access is granted. No checkout page. No credit card. No human approval.

This is what machine-to-machine payments look like.

The Problem Nobody Is Talking About

Everyone is focused on the rails. Stripe built the payment layer. Coinbase built the protocol. A16z, Galaxy, Outlier Ventures are all writing theses about agentic payments.

But there's a step everyone is glossing over.

How does the server know the payment actually arrived?

An agent sends 0.01 USDC to your wallet on Base. Your server needs to:

Detect the transfer happened
Match it to the specific request
Confirm it's not a reorg
Wait for enough block confirmations
Grant access

If you build this yourself, you're looking at subscribing to USDC transfer events via ethers.js, handling edge cases like chain reorgs, managing confirmation thresholds, building retry logic for missed events. Two weeks of work, minimum — and that's if you've done it before.

If you use a payment processor, you're paying 0.5–1% per transaction. On $0.01 micropayments, that's a fee larger than the payment itself.

The verification layer for x402 doesn't exist yet. That's the gap.

What x402 Assumes You Already Have

The x402 protocol defines the payment flow beautifully:

Agent → GET /api/resource
Server → 402 Payment Required
        { "accepts": [{ "scheme": "exact", "network": "base", 
          "maxAmountRequired": "1000", "asset": "USDC",
          "payTo": "0xYourWallet" }] }
Agent → Pays USDC on Base
Agent → GET /api/resource (with payment proof)
Server → 200 OK

Clean. Elegant. Stateless.

But that last step — "Server verifies payment proof" — assumes your server can confirm the transfer actually happened on-chain. In practice, that means you need:

A blockchain listener watching your wallet
Amount matching logic (how do you distinguish two 0.01 USDC payments in the same block?)
Confirmation waiting (Base finalizes fast, but you still need to handle reorgs)
A webhook or callback system to notify your application

That's infrastructure. Non-trivial infrastructure.

The Verification Layer

This is exactly what PayWatcher is built for.

You create a Payment Intent before the agent pays. PayWatcher gives back a unique_amount — a slightly adjusted figure (e.g., $0.0103 instead of $0.01) that makes the payment uniquely identifiable on-chain.

POST https://api.paywatcher.dev/v1/payments
{
  "amount": "0.01",
  "token": "USDC",
  "network": "base",
  "recipient": "0xYourWallet",
  "webhook_url": "https://yourapi.com/webhook/payment",
  "reference": "agent-request-abc123"
}

Response:

{
  "id": "pay_xyz789",
  "status": "watching",
  "unique_amount": "0.0103",
  "expires_at": "2026-03-16T15:00:00Z"
}

You give the agent unique_amount as the amount to pay. When the transfer hits Base, PayWatcher fires a webhook:

{
  "event": "payment.confirmed",
  "payment_id": "pay_xyz789",
  "reference": "agent-request-abc123",
  "amount": "0.0103",
  "token": "USDC",
  "network": "base",
  "tx_hash": "0xabc...def",
  "confirmed_at": "2026-03-16T14:47:22Z"
}

Your server grants access. Done.

$0.05 flat fee. No percentage. No custody. No checkout.

The Full x402 + PayWatcher Flow

Agent → GET /api/resource
Server → 402 + PayWatcher unique_amount
Agent → Sends USDC to your wallet
PayWatcher → Detects transfer on Base
PayWatcher → Fires webhook to your server
Server → Grants access
Agent → GET /api/resource (authorized)
Server → 200 OK

Your server never touches the funds. PayWatcher never touches the funds. The agent pays directly to your wallet.

Why Flat Fee Matters for Micropayments

Percentage fees break at micropayment scale.

Payment Size	Coinbase Commerce (1%)	PayWatcher ($0.05 flat)
$0.01	$0.0001 ✓ (but min fees apply)	$0.05 ✗ too expensive
$0.10	$0.001	$0.05
$1.00	$0.01	$0.05
$10.00	$0.10	$0.05 ✓
$100.00	$1.00	$0.05 ✓
$10,000.00	$100.00	$0.05 ✓✓✓

For high-value payments, flat fee wins decisively. For true micropayments under $0.05, neither model works well — but that's a Base gas cost problem, not a PayWatcher problem.

The sweet spot for PayWatcher is $1–$10,000+ payments where you want automatic verification without giving up 0.5–1%.

Who This Is For

Build with PayWatcher if you:

Accept USDC payments on Base and want automatic confirmation
Are building x402-compatible APIs that AI agents will call
Don't want to give up 0.5–1% per transaction
Want webhook notifications instead of polling Basescan
Need non-custodial verification (regulatory, preference, or principle)

Don't use PayWatcher if you:

Need fiat on/off ramps
Need a hosted checkout page
Need multi-currency support
Are transacting under $0.05 per payment (the fee exceeds the payment)

Try It

PayWatcher is live on Base. Free tier: 50 verifications/month — enough to build and test your x402 integration.

→ Get API Key → Read the Docs

Built by masemIT — we also build ChainSights, identity-first analytics for DAOs.

Questions? Reach out on Farcaster or X.

Building a Context API for AI Agents: Goodbye GitHub Raw URLs

Mario Semper — Sun, 22 Feb 2026 19:45:14 +0000

How I solved Claude's "amnesia problem" with a simple microservice

Every conversation with an AI assistant starts the same way: from scratch.

If you're using Claude, ChatGPT, or any LLM for serious work – coding, product development, writing – you know the pain. You have project briefs, architecture docs, PRDs, and user stories. And every single chat, you're either:

Copy-pasting walls of text
Re-explaining context you've explained 100 times
Watching the AI confidently hallucinate details it should know

I got tired of this. So I built a Context API that gives Claude persistent, structured access to my project documentation. Here's how – and why you might want something similar.

The Problem: GitHub Raw URLs Suck for AI Context

My first attempt was simple: store all project docs in a GitHub repo and have Claude fetch them via raw URLs.

https://raw.githubusercontent.com/myorg/context/master/projects/chainsights/prd.md

Elegant, right? Version controlled, easy to update, free hosting.

Except it doesn't work.

GitHub's CDN caches raw files aggressively. Even with ?nocache=1 appended, I'd often get stale content. Claude would reference outdated requirements. Bugs would slip through because the AI was working with last week's architecture doc.

The Solution: A Dedicated Context Service

I built a simple API service that:

Receives docs from GitHub Actions – when I push to _bmad-output/ in any project, a webhook syncs to the API
Serves structured JSON to Claude – not raw markdown, but typed documents with metadata
Supports delta queries – "give me only what changed since yesterday"
Keeps version history – every update is preserved
Detects orphans – renamed or deleted docs don't become zombies

The architecture looks like this:

┌─────────────────┐     GitHub Action      ┌─────────────────┐
│  Project Repo   │ ───────────────────▶  │  Context API    │
│  (chainsights)  │   POST /sync           │  (api.masem.at) │
└─────────────────┘                        └────────┬────────┘
                                                    │
┌─────────────────┐                                 │
│  Project Repo   │ ───────────────────────────────▶│
│  (tellingcube)  │                                 │
└─────────────────┘                                 │
                                                    ▼
                                           ┌─────────────────┐
                                           │    Claude       │
                                           │  GET /context   │
                                           └─────────────────┘

The Data Model

Three tables. That's it.

Projects

CREATE TABLE ctx_projects (
  id UUID PRIMARY KEY,
  slug VARCHAR(50) UNIQUE NOT NULL,  -- "chainsights"
  name VARCHAR(100) NOT NULL,        -- "ChainSights"  
  github_repo VARCHAR(200),          -- "myorg/chainsights"
  is_active BOOLEAN DEFAULT true
);

Documents

CREATE TABLE ctx_documents (
  id UUID PRIMARY KEY,
  project_id UUID REFERENCES ctx_projects(id),
  doc_type VARCHAR(50) NOT NULL,     -- "brief", "prd", "epic", "story"
  doc_key VARCHAR(100) NOT NULL,     -- "prd", "epic-auth-flow"
  title VARCHAR(200),
  content TEXT NOT NULL,
  file_sha VARCHAR(40),              -- Git SHA for change detection
  version INTEGER DEFAULT 1,
  updated_at TIMESTAMPTZ,

  UNIQUE(project_id, doc_type, doc_key)
);

Document History

CREATE TABLE ctx_document_history (
  id UUID PRIMARY KEY,
  document_id UUID REFERENCES ctx_documents(id),
  content TEXT NOT NULL,
  file_sha VARCHAR(40),
  version INTEGER NOT NULL,
  created_at TIMESTAMPTZ
);

The file_sha is key – when the GitHub Action syncs, we compare SHAs. Same SHA? Skip the update. Different SHA? Archive the old version, update the current.

Idempotent syncs. No duplicate writes. Clean history.

The API

Reading (for Claude)

# Get all docs for a project
GET /v1/context/chainsights

# Get only briefs and PRDs
GET /v1/context/chainsights?types=brief,prd

# Get changes since a timestamp
GET /v1/context/chainsights?since=2024-02-20T00:00:00Z

# Get a specific document
GET /v1/context/chainsights/epic/auth-flow

Response:

{
  "project": {
    "slug": "chainsights",
    "name": "ChainSights"
  },
  "documents": [
    {
      "doc_type": "prd",
      "doc_key": "prd",
      "title": "Product Requirements Document",
      "content": "# ChainSights PRD\n\n## Overview...",
      "version": 7,
      "updated_at": "2024-02-21T09:15:00Z"
    }
  ],
  "updated_at": "2024-02-21T09:15:00Z"
}

Writing (from GitHub Actions)

POST /v1/context/chainsights/sync

{
  "documents": [
    {
      "doc_type": "prd",
      "doc_key": "prd",
      "title": "Product Requirements Document",
      "content": "...",
      "file_path": "_bmad-output/prd.md",
      "file_sha": "a1b2c3d4..."
    }
  ],
  "known_paths": [
    "_bmad-output/prd.md",
    "_bmad-output/epics/auth-flow.md"
  ]
}

Response:

{
  "synced": 2,
  "created": 0,
  "updated": 1,
  "unchanged": 1,
  "orphaned": [
    {
      "doc_type": "epic",
      "doc_key": "old-feature",
      "file_path": "_bmad-output/epics/old-feature.md"
    }
  ]
}

The known_paths array is clever – it tells the API "these are all the docs that currently exist." Anything in the database but not in this list? That's an orphan. Maybe it was renamed, maybe deleted. The API flags it so I can clean up.

The GitHub Action

name: Sync BMAD Output to Context API

on:
  push:
    paths:
      - '_bmad-output/**'

jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Sync to Context Service
        env:
          MMS_API_KEY: ${{ secrets.MMS_CONTEXT_API_KEY }}
        run: |
          # Collect all docs, build JSON payload
          # POST to api.masem.at/v1/context/chainsights/sync

Configuration per project (.github/mms-context.yml):

project: chainsights
documents:
  - path: _bmad-output/brief.md
    type: brief
    key: brief
  - path: _bmad-output/prd.md
    type: prd
    key: prd
  - path: _bmad-output/epics/*.md
    type: epic
    # key derived from filename

Every push to _bmad-output/ triggers a sync. Docs flow from my repo to the API automatically.

Integrating with Claude

Here's the magic part. In Claude's system prompt (or custom instructions), I add:

You have access to the MMS Context Service for project documentation.

API-Key: mms_context_claude_xxxxx
Base-URL: https://api.masem.at

Endpoints:
- GET /v1/context/{project}?types=brief,prd&format=summary
- GET /v1/context/{project}/{doc_type}/{doc_key}

When the user mentions "Context: {project}", fetch the relevant documents.
Load summaries first, then fetch details as needed.

Now when I start a chat with "Context: chainsights", Claude:

Fetches the project summary (titles + first 500 chars)
Understands what docs are available
Loads specific docs when needed for the task

No more copy-pasting. No more "as I mentioned in our last conversation." Claude just knows.

Caching Done Right

Since we're solving a caching problem, we better cache properly:

Server-side (Redis):

context:chainsights:full           → 5 min TTL
context:chainsights:prd            → 5 min TTL
context:chainsights:epic:auth-flow → 5 min TTL

When a sync happens, we invalidate only the affected keys. Granular, not nuclear.

Client-side (ETag):

Response: ETag: "sha256-of-content"
Request:  If-None-Match: "sha256-of-content"
Response: 304 Not Modified

Claude's requests include the ETag from the last fetch. If nothing changed, we return 304 – fast and bandwidth-friendly.

Delta updates:

GET /v1/context/chainsights?since=2024-02-20T00:00:00Z

Claude can ask "what changed since my last sync?" and only get the deltas. Perfect for long-running conversations.

Results

After two weeks of using this:

Zero stale context issues – Claude always has the latest docs
Faster conversations – no preamble, no re-explaining
Better AI output – consistent terminology, accurate references
Cleaner repos – no more masemit-context sync repo

The service handles 7 projects, ~50 documents, and costs me exactly $0/month extra (it runs on existing infrastructure).

Should You Build This?

Yes, if:

You use AI assistants for ongoing project work (not just one-off questions)
You have structured documentation (PRDs, specs, architecture docs)
You're frustrated by context limits and repetition
You already have some API infrastructure

Maybe not, if:

You're doing ad-hoc AI tasks with no recurring context
Your docs change rarely (just upload to Claude Projects)
You don't want to maintain another service

What's Next

I'm considering open-sourcing this as a standalone service. If there's interest, I'll clean up the code and publish it.

Features I'm still thinking about:

Full-text search across all documents
Task write-back – Claude can create tasks that sync back to GitHub Issues
Webhooks – notify Slack when syncs fail
Multi-tenant – let other teams use it

TL;DR

GitHub raw URLs have caching problems that break AI context
A simple Context API solves this: sync via GitHub Actions, serve via REST
SHA-based idempotency prevents duplicate writes
Delta queries and ETags keep things fast
Claude gets reliable, structured, up-to-date project context

If you're building something similar or want to discuss the approach, drop a comment or find me on LinkedIn, Farcaster or X.

Mario Semper is the founder of masemIT, building developer tools and Web3 analytics. He's currently shipping ChainSights (DAO governance analytics), tellingCube (synthetic business data), PayWatcher (stablecoin payment verification), and occasionally yelling at GitHub's CDN.

How to Verify USDC Payments on Base Without a Payment Processor

Mario Semper — Sun, 22 Feb 2026 07:10:48 +0000

The Problem Nobody Talks About

You want to accept a $10,000 USDC payment. You have two options:

Option A: Integrate a payment processor like Coinbase Commerce. Set up an account, embed their checkout widget, handle their SDK. Pay $100 in fees (1%).

Option B: Build your own blockchain listener. Learn ethers.js, subscribe to USDC transfer events, handle reorgs, confirmations, edge cases. Two weeks of work, minimum.

There's no middle ground. No service that just tells you: "Yes, this specific payment arrived."

Until now.

What If Verification Was a Simple API Call?

PayWatcher is a verification layer for stablecoin payments on Base. It doesn't process payments. It doesn't touch your funds. It doesn't require a checkout flow.

You tell it what payment you expect. It watches the blockchain. When the payment arrives, you get a webhook.

That's it.

Here's the cost comparison for verifying a $10,000 USDC transfer:

Service	Fee	Model
Coinbase Commerce	$100.00	1% of transaction
NOWPayments	$50.00	0.5% of transaction
PayWatcher	$0.05	Flat fee, always

The fee is the same whether you're verifying $1 or $1,000,000.

How It Works (3 Steps)

Step 1: Create a Payment Intent

Tell PayWatcher what payment you're expecting:

curl -X POST https://api.paywatcher.dev/v1/payments \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": "10000.00",
    "token": "USDC",
    "network": "base",
    "recipient": "0xYourWalletAddress",
    "webhook_url": "https://yourapp.com/webhook/payment",
    "reference": "invoice-2026-001"
  }'

Response:

{
  "id": "pay_abc123",
  "status": "watching",
  "unique_amount": "10000.03",
  "expires_at": "2026-02-23T12:00:00Z"
}

Notice the unique_amount? PayWatcher adds a few cents to make your payment uniquely identifiable on-chain. Your customer sends $10,000.03 instead of $10,000.00 — and that tiny difference is how we match the exact transfer to your intent.

Step 2: Your Customer Sends USDC

Your customer sends USDC directly to your wallet. No checkout page, no intermediary, no redirect. Just a standard USDC transfer on Base.

You keep 100% of the payment. PayWatcher never has custody.

Step 3: Get Notified

When the transfer is confirmed on Base, PayWatcher fires a webhook:

{
  "event": "payment.confirmed",
  "payment_id": "pay_abc123",
  "reference": "invoice-2026-001",
  "amount": "10000.03",
  "token": "USDC",
  "network": "base",
  "tx_hash": "0xabc...def",
  "confirmed_at": "2026-02-22T10:30:00Z"
}

Your backend processes the webhook, marks the invoice as paid, and you're done. No polling, no manual checking on Basescan.

JavaScript Example

Here's a minimal Node.js integration:

// Create a payment intent
const response = await fetch('https://api.paywatcher.dev/v1/payments', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.PAYWATCHER_API_KEY}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    amount: '500.00',
    token: 'USDC',
    network: 'base',
    recipient: '0xYourWallet',
    webhook_url: 'https://yourapp.com/api/webhook',
    reference: `order-${orderId}`
  })
});

const payment = await response.json();
// Show payment.unique_amount to your customer

And the webhook handler:

// Express webhook endpoint
app.post('/api/webhook', (req, res) => {
  const { event, reference, amount, tx_hash } = req.body;

  if (event === 'payment.confirmed') {
    // Mark order as paid
    await db.orders.update({
      where: { reference },
      data: { status: 'paid', tx_hash }
    });
  }

  res.status(200).send('ok');
});

When to Use PayWatcher (and When Not To)

Use PayWatcher when:

You accept USDC payments and want automatic confirmation
You don't want to give up 0.5–1% per transaction
You need a non-custodial solution (regulatory, preference, or principle)
You want webhook notifications instead of polling Basescan
You're building on Base

Don't use PayWatcher when:

You need fiat on/off ramps (use Coinbase Commerce or Stripe)
You need multi-currency checkout flows
You want a hosted payment page (PayWatcher is API-only)

PayWatcher is verification, not processing. We don't hold, transfer, or have custody of funds.

What's Unique About This Approach?

Most crypto payment solutions are trying to be the next Stripe for crypto — full checkout flows, currency conversion, custody, settlement. That's valuable for some use cases.

But if you're already comfortable with USDC on Base, you don't need all that. You need someone to watch the blockchain and tell you when money arrived. That's a fundamentally different service, and it should be priced differently.

A flat $0.05 per verification instead of a percentage of the transaction value.

Architecture Overview

Your App                    PayWatcher                  Base Network
   │                            │                            │
   ├── POST /v1/payments ──────►│                            │
   │   (create intent)          │                            │
   │◄── { unique_amount } ──────┤                            │
   │                            │                            │
   │   Show amount to customer  │                            │
   │                            │                            │
   │                            │◄── Monitor USDC transfers ─┤
   │                            │    (event listener)        │
   │                            │                            │
   │                            │── Match transfer to intent │
   │                            │── Wait for confirmations   │
   │                            │                            │
   │◄── Webhook: confirmed ─────┤                            │
   │                            │                            │
   └── Process payment          │                            │

PayWatcher sits between your application and the blockchain. It handles the complexity of monitoring transfers, matching amounts, waiting for confirmations, and handling edge cases like reorgs — so you don't have to.

Try It

PayWatcher is live on Base. We're onboarding early testers now.

Free tier: 50 verifications/month — enough to test and validate your integration.

→ Request API Access
→ Read the Docs

Built by masemIT — we also build ChainSights, identity-first analytics for DAOs.

Questions? Reach out on Farcaster or X.

PayWatcher is Live

Mario Semper — Sat, 21 Feb 2026 19:18:24 +0000

We just shipped PayWatcher — payment verification for USDC on Base.

The problem:
verify a $10k stablecoin payment and you either pay $100 to a processor or build your own blockchain listener from scratch.

PayWatcher is the missing middle: create a payment intent, we watch Base for the transfer, webhook fires when confirmed. $0.05 flat. Non-custodial. You keep 100%.

Live now → paywatcher.dev

Looking for devs building on Base who accept USDC.
Free tier available.

How I Built a Donation Website in 8 Hours (And Why)

Mario Semper — Sun, 18 Jan 2026 00:33:21 +0000

The Mission

Yesterday, I built hoki.help – a donation platform for HoKi NÖ, a children's hospice organization in Lower Austria.

HoKi supports families with seriously ill children. From diagnosis through illness to bereavement support. Completely free of charge.

The Tech Stack

Component	Technology
Framework	Next.js 14 (App Router)
Styling	Tailwind CSS
Payments	Stripe Checkout
Database	Neon (Serverless Postgres)
Hosting	Vercel
Domain	hoki.help

What We Built

In approximately 8 hours:

✅ Responsive landing page (mobile-first)
✅ Donation widget (€10/25/50/100 + custom amounts)
✅ One-time and monthly recurring donations
✅ Anonymous donation option
✅ Stripe Checkout integration
✅ Webhook handling for donation tracking
✅ Donation barometer (shows progress after €500)
✅ Legal pages (Impressum, Privacy Policy - GDPR compliant)
✅ FAQ section with Schema.org structured data
✅ SEO optimization

The Key Decisions

1. Stripe Checkout (Not Custom Forms)

Why handle PCI compliance ourselves? Stripe Checkout is secure, trusted, and supports Apple Pay / Google Pay out of the box.

2. Neon over Vercel KV

We only need to store aggregate donation stats (total amount, count). Neon's serverless Postgres in Frankfurt keeps data in the EU and I already use it for other projects.

3. No User Accounts

Donations should be frictionless. No registration, no passwords. Just donate and go.

4. Anonymous by Design

Donors can choose to remain anonymous. Their name won't be stored or shared with the charity – only Stripe has it for payment processing.

The Result

🔗 hoki.help

100% of donations go to HoKi NÖ. I cover all hosting costs through my company.

Open for Questions

Have questions about the implementation? Drop a comment below!

Built with ❤️ for the children and families supported by HoKi NÖ.

🛠️ Devs, want automatic README generation + usage diagrams in every repo?

Mario Semper — Sat, 05 Jul 2025 17:00:24 +0000

Try GitHub Tools — a new suite of reusable GitHub workflows from masem.at for streamlining your docs & release automation. Zero setup. Just plug and ship.

⚡️ README.md from your code
📊 SVG/ASCII diagrams auto-generated
🤖 Social post drafts via OpenAI

Experimental & open for all!
👉 https://masem.at/projects/github-tools

Announcing pyseoa-ts v0.2.0 – More Power, More Control

Mario Semper — Mon, 23 Jun 2025 20:35:48 +0000

We're excited to release pyseoa-ts v0.2.0, a TypeScript-based SEO audit library designed for modern web apps.

🚀 What’s New in v0.2.0

Progress Type Enhancements

Progress callbacks now include type: "crawl" | "analyze" for more detailed reporting in the UI.
Request Delay / Rate Limiting

You can now throttle requests when crawling large sites.
Custom User-Agent Support

Specify your own User-Agent string for SEO testing and bot behavior emulation.
DX Improvements

All key result types like.... Read more

I just published pyseoa-ts — a modern, type-safe SEO analyzer for HTML in React/Vite/TS projects 🚀

Mario Semper — Sun, 22 Jun 2025 14:50:54 +0000

Includes tag audits, keyword density, and a scoring summary – all powered by clean TypeScript and designed to work well in Vercel, serverless and SPA contexts.

👉 npm install pyseoa-ts
🔗 https://www.masem.at/blog/introducing-pyseoa-ts-typescript-seo-analyzer-for-modern-web-apps

typescript #seo #react #vite #opensource

gq-to-sql v0.2.0 — Grouping, Joins, and PostgreSQL Support

Mario Semper — Thu, 19 Jun 2025 23:12:47 +0000

🚀 gq-to-sql v0.2.0 — Now with Grouping, Joins, and PostgreSQL Support!

I'm excited to announce the release of gq-to-sql v0.2.0 — a powerful JavaScript utility that turns Microsoft Graph-style query strings into safe, parameterized SQL.

Whether you're building a REST API, internal tool, or dashboard interface, this utility gives you clean SQL generation from URLs like:

$select=name&$expand=roles($select=label)&$filter=roles.label eq 'admin'

✅ What’s New in v0.2.0

$expand=table($select=...) with JOIN support
$apply=groupby(..., aggregate(...))
Combine $apply + $filter in one query
Support for SQL dialects:
- mysql (default): ?
- postgres: $1, $2, ...
Improved alias mapping & schema-based JOINs

📦 Example

const query = "$select=name&$expand=roles($select=label)&$filter=roles.label eq 'admin'";

const { sql, params } = buildSQL(query, {
  table: 'users',
  schema: {
    users: {
      alias: 'u',
      columns: ['id', 'name', 'role_id'],
      joins: {
        roles: {
          type: 'LEFT',
          on: 'u.role_id = r.id',
          alias: 'r'
        }
      }
    },
    roles: {
      alias: 'r',
      columns: ['id', 'label']
    }
  },
  placeholderStyle: 'postgres'
});

👉 Output:
SELECT u.name, r.label FROM users u LEFT JOIN roles r ON u.role_id = r.id WHERE r.label = $1

Install it:

npm install gq-to-sql

Source: github.com/masem1899/graphql-to-sql
npm: npmjs.com/package/gq-to-sql
Website: https://masem.at

Introducing gq-to-sql: Convert Graph-Style URL Queries into SQL

Mario Semper — Wed, 18 Jun 2025 10:17:30 +0000

As a developer working with Graph-like APIs and SQL databases, I often wished for an easy way to parse $filter, $select, and similar query strings and convert them into SQL. So I built gq-to-sql — a lightweight, safe utility for just that.

Features

✅ Parse Graph-style query strings: $filter, $select, $orderby, $top, $skip

✅ Safe SQL output with parameters (?)

✅ Nested condition support ((age gt 20 or age lt 10))

Example

Input:

?$filter=age gt 20 and city eq 'Vienna'&$select=name,age&$orderby=age desc

Output:

SELECT name, age FROM users WHERE age > ? AND city = ? ORDER BY age desc

Try It Out

npm install gq-to-sql

👉 View it on GitHub: https://github.com/masem1899/graphql-to-sql
👉 Website: https://masem.at/s/devto
👉 Blog Article: https://www.masem.at/blog/introducing-gqtosql-graphstyle-url-filtering-for-sql

🎛️ vercel-debug-bar: inspect feature flags + web vitals like a boss

Mario Semper — Fri, 13 Jun 2025 11:04:13 +0000

Tired of guessing which flag is active or what INP means? vercel-debug-bar is a plug-and-play React overlay for inspecting:

✅ Vercel Feature Flags

📊 Core Web Vitals (real-time via web-vitals)

📈 Analytics and A/B data

It’s fully TailwindCSS styled, positionable, and now publishes GOOD / POOR performance zones.


bash
npm install vercel-debug-bar

🚀 New Release: pyseoa v0.2.3

Mario Semper — Sun, 08 Jun 2025 20:32:52 +0000

🚀 New Release: pyseoa v0.2.3
A modern Python-powered SEO analysis toolkit 🐍

✅ Smart internal link crawling
✅ CLI & FastAPI-ready
✅ PDF, HTML, CSV, Markdown exports
✅ Customizable feature flags (title, meta, OpenGraph, etc.)
✅ Threaded performance for crawl, analyze, export

📦 Now on PyPI: pip install pyseoa
🔗 Link in bio or visit: pypi.org/project/pyseoa
🔗 https://seo.masem.at/
🔗 https://github.com/sempre76/pyseoa

🔧 Built for devs, open source tools, and SaaS dashboards.

Python #SEO #OpenSource #DevTools #FastAPI #CLI #Automation #PythonTools #SEOTools #WebTools