DEV Community: Kilo Spark

Debug Stripe Webhooks Without Guessing What Your Server Sends Back

Kilo Spark — Sun, 15 Feb 2026 20:57:03 +0000

You get a Stripe webhook. Your server processes it. Something breaks — maybe the charge succeeds but your database doesn't update, or the customer gets double-charged.

The problem isn't Stripe. It's that you can't see what your server is actually sending to Stripe during that webhook flow.

The Blind Spot

When a Stripe webhook fires, your handler probably:

Verifies the signature
Reads the event
Makes API calls back to Stripe (update subscription, create invoice, refund, etc.)

Steps 1 and 2 are easy to log. Step 3? You're flying blind unless you dig through Stripe's dashboard and match timestamps manually.

One-Line Fix

toran.sh lets you see every outbound API call by swapping a base URL. Instead of:

stripe.api_base = "https://api.stripe.com"

You use:

stripe.api_base = "https://stripe.toran.sh"

That's it. No SDK. No middleware. No code beyond changing one string.

What You See

Every request your server makes to Stripe now shows up in real time at toran.sh:

Full request body — see exactly what parameters you're sending
Response — see what Stripe sent back (including error details)
Timing — spot slow calls that might be causing timeouts
Headers — verify you're sending the right API version, idempotency keys, etc.

Real Example: Debugging a Double-Charge

A user reported being charged twice. Here's how you'd debug it:

Set stripe.api_base = "https://stripe.toran.sh" in your webhook handler
Re-send the webhook from Stripe's dashboard (they have a "Resend" button)
Watch toran.sh — you see your handler makes two POST /v1/charges calls
The bug is obvious: your idempotency check runs after the first charge instead of before

Without seeing the outbound calls, you'd be reading logs and guessing for hours.

Works With Any API

Stripe is just one example. The pattern works with any API:

openai.toran.sh for OpenAI calls
api.anthropic.toran.sh for Anthropic
api.github.toran.sh for GitHub API

Swap the base URL, see what your code actually sends.

When to Use It

Webhook debugging — see what your handler sends back to the API
SDK debugging — see what the SDK actually sends vs. what the docs say
Integration testing — verify your code sends the right payloads before going to production
Teaching — show a junior dev exactly what happens when they call stripe.charges.create()

Try It

toran.sh is free — no signup required for basic usage. Swap a URL, see your API calls.

Built by Kilo Spark. We build dev tools that show you what's actually happening.

What Open Source Maintainers Miss in Large PRs (And How to Catch It)

Kilo Spark — Sun, 15 Feb 2026 08:01:23 +0000

Large pull requests are where bugs, security issues, and breaking changes go to hide.

If you maintain an open source project, you've been there: a 400-line PR lands in your review queue. You scroll through it, skim the obvious parts, approve it, and move on. Two weeks later, something breaks — and the culprit was buried on line 312 of that diff.

You're not lazy. You're human. And large PRs are designed (unintentionally) to exploit exactly how humans review code.

The Science of Skimming

Studies on code review consistently show that review effectiveness drops sharply after ~200 lines of diff. Beyond that threshold, reviewers start skimming. They focus on the parts they understand and gloss over the rest.

For open source maintainers, this is especially painful. You're reviewing code from contributors you may not know, in your spare time, often on a phone between meetings. The incentive structure practically guarantees things slip through.

What Actually Gets Missed

After looking at hundreds of open source PRs and the issues that followed them, patterns emerge. Here's what reviewers consistently miss in large diffs:

1. New Dependencies

A contributor adds a helper library — seems reasonable. But buried in package.json or go.mod, there's now a new transitive dependency tree you didn't audit. That tree might include packages with known vulnerabilities, packages with minimal maintenance, or packages with licenses incompatible with yours.

Real example pattern: A PR that refactors a utility module also adds lodash as a dependency — when the project previously had zero runtime dependencies. The refactor gets reviewed; the dependency change gets a rubber stamp.

2. Permission and Scope Changes

CI config changes are the ultimate "eyes glaze over" zone. A .github/workflows/ modification that adds write permissions to a workflow, or a Dockerfile change that switches from a non-root user to root — these are high-impact, low-visibility changes.

Real example pattern: A PR updates a GitHub Action workflow to fix a build issue. Buried in the YAML diff: permissions: contents: write was added. The contributor needed it for their fix, but now that workflow can push to your repo.

3. Configuration Modifications

Changes to .env.example, config.yaml, nginx.conf, or infrastructure-as-code files often ride along with feature PRs. Reviewers focus on the application logic and skip the config changes entirely.

Real example pattern: A PR adding a new API endpoint also modifies the CORS configuration to allow * origins. The endpoint code gets thorough review. The config change? Nobody notices.

4. Secrets and Credentials

Hardcoded API keys, tokens, or internal URLs sometimes appear in test fixtures, example configs, or debug code. In a large diff, they blend into the noise.

5. License and Legal Changes

A new file with a different license header gets added. A LICENSE file is modified. A vendored dependency brings its own licensing terms. These changes are invisible to most reviewers unless they're specifically looking for them.

Practical Tips for Reviewing Large PRs

If you maintain an open source project, here are concrete things you can do today:

Break the scroll habit. Don't review a large PR top-to-bottom in one pass. Start with the files that matter most: config files, CI/CD, dependency manifests, permission-related code.

Use GitHub's file filter. Filter the diff to show only .yml, .json, .toml, .lock files first. Review those separately from application code.

Check the dependency diff explicitly. If package-lock.json or go.sum changed, don't just collapse it. At minimum, check what was added.

Ask contributors to split large PRs. This is the single most effective policy. A 400-line PR should usually be 3-4 smaller ones. Make this a documented expectation in your CONTRIBUTING.md.

Set up automated guardrails. Manual review doesn't scale, especially for the boring-but-critical stuff like dependency changes and permission modifications.

Automating What Humans Miss

This is where tooling matters. Not as a replacement for human review, but as a safety net for the things humans predictably miss.

Axiomo was built specifically for this problem. It's a GitHub App that scans every PR and surfaces structured risk signals — new dependencies, permission changes, config modifications, and more — so you don't have to read 500 lines of diff hoping you'll catch the important parts.

It doesn't replace your judgment. It tells you where to focus it.

What Axiomo flags automatically:

New dependencies added to your project (and their risk profile)
CI/CD and workflow changes that modify permissions or secrets access
Configuration changes that affect security posture
License modifications across your dependency tree
Sensitive file patterns — env files, credentials, infrastructure config

For open source maintainers, Axiomo is free and unlimited for public repositories. You install the GitHub App, and it starts working on every PR — no configuration required.

The Maintainer's Dilemma

Open source maintainers are asked to be security experts, dependency auditors, license lawyers, and CI/CD specialists — on top of actually reviewing code logic. That's not sustainable.

The answer isn't "review harder." It's having structured signals that point you to what matters, so you can spend your limited review time on the things that actually need human judgment.

Large PRs will always exist. But missing what's hidden inside them doesn't have to be inevitable.

Axiomo is a free GitHub App that surfaces risk signals in every PR. Unlimited for public repos. Install it in 30 seconds → axiomo.app

How to Monitor Every API Call Your LangChain Agent Makes

Kilo Spark — Sun, 15 Feb 2026 08:01:20 +0000

How to Monitor Every API Call Your LangChain Agent Makes

Your LangChain agent is making API calls you never see. Here's how to watch them.

You built a LangChain agent. It works. It calls OpenAI, fetches from APIs, queries vector stores. But do you actually know what it's sending? What headers, what payloads, what tokens it's burning through on each request?

Most developers don't. LangChain abstracts away the HTTP layer — that's the point. But when something breaks, when costs spike, or when you're debugging a hallucination, you need to see the raw traffic.

In this tutorial, I'll show you how to use toran.sh to intercept and inspect every outbound API call from a LangChain agent — in real-time, with zero code changes beyond swapping a URL.

The Problem: LangChain's Black Box

Here's a typical LangChain agent:

from langchain.agents import initialize_agent, load_tools
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o", temperature=0)
tools = load_tools(["serpapi", "llm-math"], llm=llm)
agent = initialize_agent(tools, llm, agent="zero-shot-react-description", verbose=True)

agent.invoke("What is the population of Tokyo divided by the population of Paris?")

Even with verbose=True, you see the chain-of-thought — not the actual HTTP requests. You don't see:

How many API calls were made to OpenAI
The exact prompt tokens sent in each request
Response latencies for each call
Whether retry logic kicked in
What your SerpAPI calls actually looked like

LangSmith exists for tracing chains, but it operates at the framework level. Sometimes you need to see the raw HTTP — the actual bytes on the wire.

The Fix: Route Through toran.sh

toran.sh works by giving you a unique URL that proxies your API calls. You swap your base URL, and every request flows through toran's dashboard where you can inspect it in real-time.

No SDK. No proxy configuration. No code beyond changing one URL string.

Step 1: Get Your toran.sh Endpoint

Head to toran.sh and create a channel. You'll get a slug like my-langchain-debug. No signup required for basic use.

Your proxy URL becomes: https://my-langchain-debug.toran.sh

Step 2: Point LangChain at toran

Here's the key change — swap the base_url on your OpenAI client:

from langchain_openai import ChatOpenAI

# Before: calls api.openai.com directly
# llm = ChatOpenAI(model="gpt-4o")

# After: routes through toran.sh
llm = ChatOpenAI(
    model="gpt-4o",
    base_url="https://my-langchain-debug.toran.sh/v1",
)

That's it. One line. LangChain sends all OpenAI requests through toran, which forwards them to OpenAI and logs everything.

Step 3: Run Your Agent and Watch

Open your toran.sh dashboard in one window. Run your agent in another:

from langchain.agents import initialize_agent, load_tools
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    model="gpt-4o",
    temperature=0,
    base_url="https://my-langchain-debug.toran.sh/v1",
)

tools = load_tools(["serpapi", "llm-math"], llm=llm)
agent = initialize_agent(tools, llm, agent="zero-shot-react-description", verbose=True)

result = agent.invoke("What is the population of Tokyo divided by the population of Paris?")
print(result)

Now check your toran dashboard. You'll see every request in real-time:

POST /v1/chat/completions — the initial reasoning call
POST /v1/chat/completions — after the agent gets SerpAPI results and thinks again
POST /v1/chat/completions — the math step
POST /v1/chat/completions — the final answer synthesis

Click any request to see the full payload: the system prompt, the conversation history that LangChain assembled, the function definitions, token counts, and the complete response.

What You'll Discover

Once you start watching, you'll notice things:

1. Agents make more calls than you think

A simple ReAct agent answering one question might make 4-6 OpenAI calls. An agent with multiple tools can easily hit 10+. Each one costs tokens.

2. The prompts are massive

LangChain injects tool descriptions, formatting instructions, and conversation history into every call. Your "simple question" might be wrapped in 2,000 tokens of scaffolding.

3. Retries happen silently

If OpenAI returns a 429 or 500, the client retries. Without toran, you'd never know. With it, you see the failed request, the delay, and the retry.

4. Response times vary wildly

Some calls return in 500ms. Others take 8 seconds. The dashboard shows you exactly which calls are slow, so you can optimize the right thing.

Monitoring Multiple Services

LangChain agents often call more than just OpenAI. If you're using other LLM providers or APIs that support base URL configuration, you can route them through toran too:

from langchain_openai import ChatOpenAI
from langchain_anthropic import ChatAnthropic

# Monitor OpenAI calls
openai_llm = ChatOpenAI(
    model="gpt-4o",
    base_url="https://my-langchain-debug.toran.sh/v1",
)

# For any HTTP-based tool or API, swap the base URL
# to route through your toran channel

Every call from every service shows up in one dashboard.

Production Use: Keep It Running

toran.sh isn't just for debugging. Keep it in your staging or production pipeline:

import os

# Toggle monitoring via environment variable
base_url = os.getenv("TORAN_BASE_URL", "https://api.openai.com/v1")

llm = ChatOpenAI(
    model="gpt-4o",
    base_url=base_url,
)

Set TORAN_BASE_URL in staging to monitor. Remove it in production for direct calls. Or leave it on — the proxy adds minimal latency.

Pricing

toran.sh has a free tier that requires no signup — perfect for debugging sessions. If you need persistent logging and team features:

Free — No signup, basic real-time inspection
Pro ($29/mo) — Extended history, team access
Pro Plus ($99/mo) — Full retention, priority support

Wrap-Up

LangChain is powerful, but abstraction comes at a cost: you lose visibility into what's actually happening at the network level. toran.sh gives it back with a one-line change.

Next time your agent burns through $5 of tokens on a single question, or takes 30 seconds to respond, or returns something bizarre — don't guess. Watch the calls.

👉 toran.sh — start monitoring in 30 seconds.

The 5 Riskiest PRs Merged to Popular Open Source Projects This Week

Kilo Spark — Sun, 15 Feb 2026 03:22:03 +0000

Every week, thousands of pull requests get merged to major open source projects. Most are routine — dependency bumps, typo fixes, small refactors. But some are high-risk changes that touch critical paths, come from first-time contributors, or modify security-sensitive code.

I analyzed recent PRs across several popular repos to find the ones that deserved the most scrutiny. Here's what I found, and what it tells us about how we review code.

What makes a PR "risky"?

Before diving in, let's define what I mean by risk. It's not about the code being bad — it's about the probability that something important was missed during review. A few signals:

First-time contributor to the repo — they don't know the conventions yet
Large diff touching multiple subsystems — hard to review thoroughly
Changes to auth, payments, or data handling — high blast radius if wrong
Insufficient test coverage for the change — the safety net has holes
Quick merge with minimal discussion — maybe the reviewers were busy

None of these mean the PR is bad. They mean it deserved more attention than average.

How I analyzed them

I used axiomo.app to generate structured signals for each PR. Instead of reading through hundreds of lines of diff, axiomo produces a breakdown:

Contributor context — is this person a regular committer or brand new?
Risk score with specific drivers — what exactly makes this PR risky?
Focus areas — which files/changes deserve the most review attention?
Evidence — links to the specific lines that triggered each signal

The key difference from AI code review tools: axiomo doesn't try to tell you if the code is "good" or "bad." It tells you where to look and why it matters. The human reviewer still makes the call.

What patterns emerge

After analyzing hundreds of PRs across different repos, some patterns stand out:

1. The "drive-by refactor"

Someone new to the project opens a PR that "cleans up" a module they don't fully understand. The refactor looks reasonable line-by-line, but it subtly changes behavior that downstream code depends on. These PRs are especially dangerous because each individual change looks fine — the risk is in the aggregate.

2. The "dependency cascade"

A dependency update that looks like a simple version bump, but the new version has breaking changes in edge cases. The test suite passes because it doesn't cover those edges. These are hard to catch because the diff is small and looks innocuous.

3. The "Friday afternoon merge"

A large PR that's been open for weeks finally gets merged with a quick "LGTM" when the maintainer is trying to clear their review queue. The conversation thread shows early concerns that were never fully resolved, but the PR got approved anyway.

4. The "config change with code implications"

Changes to configuration files, environment variables, or feature flags that seem harmless but actually change runtime behavior in production. These often fly under the review radar because they're "just config."

Why structured signals matter

Traditional code review is human-powered, which is both its strength and its weakness. Reviewers bring context, judgment, and domain knowledge that no tool can replace. But they also get tired, skip files, and miss patterns across large diffs.

Structured signals don't replace the reviewer — they make the reviewer faster and more focused. Instead of scanning a 500-line diff wondering "what should I pay attention to?", you get a prioritized list of focus areas with explanations.

Think of it like a triage nurse in an ER. The nurse doesn't diagnose or treat — they make sure the most urgent cases get seen first. That's what structured PR signals do for code review.

Try it on your own repos

If you maintain an open source project (or work on any repo with regular PRs), you can try this yourself:

Go to axiomo.app
Paste any public GitHub PR URL
Get a structured signal breakdown in seconds

It's free for public repos, no signup required. There's also a GitHub App that auto-generates signals on new PRs.

The signal URLs are permanent — you can share them in PR discussions, link them in review comments, or reference them later.

What this isn't

This is not:

AI code review — axiomo doesn't leave line-by-line comments or suggest fixes
A replacement for human review — it's a lens, not a judge
Static analysis — it doesn't run your code or check for bugs
A CI gate — it's informational, not blocking

It's a structured, explainable breakdown of what deserves attention in a PR and why. The reviewer still does the thinking.

If you're curious about the methodology or want to see signals for specific repos, drop a comment. I'm happy to analyze any public PR.

How I Debug OpenAI API Calls Without Any SDK

Kilo Spark — Sun, 15 Feb 2026 03:21:58 +0000

You're building with the OpenAI API. Maybe directly, maybe through LangChain, maybe through an MCP tool. Something isn't working — the response is wrong, the model is ignoring your system prompt, or you're getting rate limited and don't know why.

Your options:

Add print(response) everywhere
Set up LangSmith or Helicone
Stare at the OpenAI dashboard usage page

All of these suck for quick debugging. Here's what I actually do.

The env var trick

Most OpenAI client libraries let you override the base URL. The official Python client uses OPENAI_BASE_URL. LangChain respects it. So does nearly every wrapper.

The trick: point that env var at an inspector that forwards to the real API while showing you everything.

# 1. Go to toran.sh/try
# 2. Enter: https://api.openai.com
# 3. Get your unique URL, e.g.: https://abc123.toran.sh
# 4. Set it:
export OPENAI_BASE_URL=https://abc123.toran.sh

Now run your code normally. Every request to OpenAI flows through your inspector URL, which forwards to the real API. You see the full request and response in your browser — live, as it happens.

What you can see

Once you're watching the traffic, some things become immediately obvious:

Token usage per request. Not the aggregate dashboard number — the actual usage object in each response. You can see exactly which call is burning through your quota.

System prompts hitting the API. If you're using a framework, you might not realize what system prompt it's actually sending. I've caught frameworks injecting 2,000-token system prompts I didn't write.

Retry behavior. Is your client retrying on 429s? How many times? With what backoff? You can see every retry as a separate request.

Streaming chunks. If you're using streaming, you can see the actual SSE chunks as they arrive. Useful when debugging why your streaming UI is stuttering.

Headers you didn't expect. Some wrappers add custom headers. Some send your API key in unexpected ways. Now you can see exactly what's going over the wire.

A real example

I was debugging why an agent kept giving wrong answers for a specific type of query. The logs showed the right tool was being called, the right function was executing, but the final answer was wrong.

I pointed the base URL at toran and watched the requests. Turned out the framework was sending the conversation history in the wrong order — tool results were appearing before the tool call in the messages array. The model was confused because it was seeing an answer before the question.

I would never have caught this from application logs. The logs showed "tool called, result returned, completion generated." Everything looked fine. But the actual HTTP request body told the real story.

Works with any OpenAI-compatible API

The same trick works with:

Anthropic — set ANTHROPIC_BASE_URL
Azure OpenAI — override the endpoint URL
Local models (Ollama, vLLM) — point at the local server through toran
Any OpenAI-compatible API — if it takes a base URL, it works

# Anthropic
import anthropic
client = anthropic.Anthropic(base_url="https://abc123.toran.sh")

# OpenAI
from openai import OpenAI
client = OpenAI(base_url="https://abc123.toran.sh/v1")

When to use this vs. proper observability

This isn't a replacement for LangSmith, Helicone, or OpenTelemetry. Those are production monitoring tools. This is for when you're sitting at your desk going "why the hell isn't this working" and you need to see the raw request right now.

Think of it as curl -v for your LLM calls. You don't leave curl -v in production, but you reach for it constantly during development.

Use toran when:

Something is broken and you need to see the actual request
You want to verify what a framework is sending on your behalf
You're debugging streaming behavior
You need to check retry/error handling logic
You want to see real token counts per request

Use proper observability when:

You need historical data and dashboards
You're monitoring production traffic
You need alerts on cost/latency
You want traces across multiple services

Try it

Go to toran.sh/try. Enter https://api.openai.com. Get your URL. Set OPENAI_BASE_URL. Run your code.

Takes 30 seconds. You'll see things you didn't know your code was doing.

What Your AI Agent Actually Sends to APIs (And Why You Should Care)

Kilo Spark — Sun, 15 Feb 2026 02:46:03 +0000

You built an MCP tool that creates Stripe charges. You tested it. It works. A customer gets double-charged. Now what?

You open your logs. The LLM decided to call your create_charge tool twice. Or maybe once with weird parameters. Or maybe your tool called Stripe's API three times because of retry logic you forgot about. You don't actually know, because you never saw the raw HTTP requests that left your machine.

This is the reality of building AI agent tooling right now: you're shipping code where the most important part — what actually goes over the wire — is invisible to you.

The black box problem

When you write a normal REST integration, you control the inputs. You write the fetch call, you set the headers, you know exactly what's being sent because you typed it.

AI agents flip this. The LLM decides when to call your tool, what arguments to pass, and sometimes how many times to call it. Your MCP tool or function-calling handler takes those arguments and fires off HTTP requests to third-party APIs. The gap between "what the LLM decided" and "what bytes hit Stripe's servers" is where bugs live.

And it's not a small gap.

Consider a typical MCP tool that manages Shopify products:

@mcp.tool()
async def update_product(product_id: str, title: str, price: float):
    async with httpx.AsyncClient() as client:
        resp = await client.put(
            f"https://your-store.myshopify.com/admin/api/2024-01/products/{product_id}.json",
            headers={"X-Shopify-Access-Token": TOKEN},
            json={"product": {"title": title, "variants": [{"price": str(price)}]}}
        )
    return resp.json()

Looks simple. But when an agent calls this, you can't see:

Did the agent pass a valid product_id, or did it hallucinate one?
What did the full request body actually look like after serialization?
Did Shopify return a 200, or a 422 that your tool swallowed?
How long did the request take? Was it retried?

You could add logging. You could add print statements. You could wire up OpenTelemetry. But now you're instrumenting every tool, and you still can't see the actual bytes on the wire — just what your code thinks it sent.

What you actually want

You want curl -v for your AI agent's API calls. Something that shows you the real request and response, in real time, without changing your tool's code.

The simplest approach I've found: swap a base URL and watch everything in your browser.

The idea is dead simple. Instead of your tool hitting https://api.stripe.com, it hits https://abc123.toran.sh. Toran forwards the request to the real API, records everything, and streams it to a live dashboard you can watch in your browser.

No install. No signup. No SDK to integrate. You change a base URL, and suddenly you can see everything.

What this looks like in practice

Go to toran.sh/try, enter the upstream API you want to inspect (e.g. https://your-store.myshopify.com), and you get a unique toran URL like https://abc123.toran.sh. Now swap it in:

# Before
BASE = "https://your-store.myshopify.com"

# After — point at your toran URL instead
BASE = os.environ.get("SHOPIFY_BASE_URL", "https://your-store.myshopify.com")

# Set the env var to your toran URL
export SHOPIFY_BASE_URL=https://abc123.toran.sh

That's it. Now every request your MCP tool makes to Shopify flows through toran, and you see the full request and response live in your browser.

No code changes beyond the base URL. When you're done debugging, unset the env var and you're back to production mode.

Why this matters more for AI agents than regular code

In traditional software, a bug in an API call is usually deterministic. Same input, same output, same broken request. You can reproduce it.

AI agents are stochastic. The LLM might call your tool differently every time. The arguments might be slightly wrong in ways you'd never think to test. The failure mode might be "it worked, but it sent the wrong thing" — the hardest kind of bug.

Being able to watch the actual HTTP traffic in real time turns debugging from archaeology into observation. You see the problem as it happens, not after your user reports it.

Some things I've caught this way:

An agent passing amount: 1000 (cents) vs amount: 10.00 (dollars) to Stripe — both "work," one costs 100x more
Retry logic firing three times because the first response was slow, not failed
Auth tokens being sent to the wrong endpoint because the agent mixed up two similar tools
A tool silently falling back to a default value when the agent passed null

Try it

If you're building MCP tools or any AI agent that talks to external APIs, go to toran.sh/try. Enter your upstream URL, get a toran URL, swap it in, and see what your agent is actually doing.

# 1. Go to toran.sh/try, enter: https://api.openai.com
# 2. Get your URL: https://abc123.toran.sh
# 3. Swap it in:
export OPENAI_BASE_URL=https://abc123.toran.sh

No install. No signup. You'll probably be surprised by what you find.