标签：#API

Receiving a webhook is easy. Building a webhook pipeline that survives duplicate deliveries, delayed events, missing messages, invalid signatures, and seller authorization changes is the real engineering work. This guide explains how to build a production-ready pipeline for TikTok Shop Customer Service messages—from HTTPS ingress to history reconciliation. First, Understand the Scope TikTok Shop Customer Service API is designed for conversations between buyers and sellers in a TikTok Shop. It is not an API for reading ordinary TikTok direct messages. Before implementation, confirm that: Your application has access to the required Customer Service API scopes. The seller has authorized your application. The target shop is correctly mapped to your internal workspace or tenant. Your webhook endpoint is publicly accessible over HTTPS. Customer Service API access is inactive by default and requires approval. See the official Customer Service API overview and app features documentation . If these prerequisites are missing, changing webhook code will not solve the problem. Recommended Architecture A reliable implementation separates webhook acknowledgement from business processing: TikTok Shop | v HTTPS webhook ingress | +-- Verify signature using raw request body | +-- Insert event into a durable inbox | +-- Return HTTP 200 within 3 seconds | v Message queue | v Normalize, deduplicate, and route | v Customer service workspace ^ | History reconciliation worker The webhook request should not wait for: CRM updates AI-generated replies Media downloads Ticket creation Search indexing External notifications Persist the event, acknowledge it, and process it asynchronously. Subscribe to the New Message Event For incoming customer service messages, subscribe to NEW_MESSAGE , identified as event type 14 . You can configure the subscription in TikTok Shop Partner Center or through the webhook configuration API. The official event reference is available in the New Message webhook docu

It's 3 AM. A production service is misbehaving, you're on-call, and you'd love an agent that can pull the service's health and tee up a restart for you. The catch is obvious: an agent with raw access to a DevOps API is a liability. One bad call could scale you into a huge bill or delete an incident record you needed. So the real question isn't "can the agent reach the API." It's "which calls should it be allowed to make at all, and how should the dangerous ones be treated differently from the safe ones." That decision is what Skillgate handles, and it's the part we actually build and run in this post. Scope, up front This post is about the classification and curation layer: turning an OpenAPI spec into a governed set of skills. Skillgate decides which endpoints become tools, marks which are read-only, flags which writes should require approval, and denies the destructive ones outright. Wiring an approval flag to a live human-approval pause, and making that pause survive a crash, is the job of the Agent OS runtime, not Skillgate. We link to it at the end. The demo here does not implement that runtime, and this post does not pretend it does. The problem Skillgate solves Point an LLM at a DevOps API and you have three bad options: Expose nothing. The agent is useless. Expose everything. Now the model can call DELETE and scale on a whim. Hand-whitelist every route. It works until the API changes, then it rots. Skillgate replaces all three with opt-in curation plus automatic risk classification. You choose a small surface, and every endpoint on it gets a class based on its method and shape. From REST endpoint to agent skill Skillgate's input is an ordinary REST API described by an OpenAPI spec. Nothing about the API is agent-aware. It's the same deploy, scaling, and incident routes your platform already exposes. Each endpoint is described in the standard OpenAPI shape: a method, a path, some parameters, a description, and tags. A representative operation from the DevOps

Most teams don't consciously choose their messaging infrastructure. They inherit it. Someone used Service Bus on the last project, it worked fine, and now it's the default answer for every async communication problem that comes up. Two years later, you're bending it into shapes it was never designed for, and the operational pain gets blamed on "distributed systems being hard" rather than on the actual culprit: a tool being asked to do a job it doesn't fit. The problem isn't that Service Bus, Event Grid, or Kafka are bad. It's that they solve genuinely different problems, and conflating them doesn't just create technical debt — it creates architectural liability that compounds over time. The Real Difference Is the Communication Contract, Not the Feature List When you put these three tools side by side in a comparison table, you'll find overlapping columns. All three move messages between systems. All three have some delivery guarantee story. That's where the surface-level comparison breaks down and people make bad decisions. The more useful question is: what contract does your system need to uphold with the data it moves? Service Bus is fundamentally about reliable, ordered processing with strong delivery guarantees. It's designed for the case where every message matters individually, where you need competing consumers pulling from a queue, where poison message handling and dead-lettering are first-class concerns. If you're coordinating business process steps or handling financial transactions where exactly-once semantics matter, this is the right shape of tool. Event Grid is about reactive routing. Something happened in your infrastructure or your application, and you want other things to respond to it. It's push-based, fan-out-friendly, and optimized for low-latency notification rather than high-volume throughput. It's not trying to be a buffer. If you're triggering downstream workflows in response to blob uploads, resource state changes, or custom application even

Here's a bug your test suite probably wouldn't catch. A backend developer refactors the user model. The id field — an integer since forever — starts coming back as a string: "42" instead of 42 . Every value is still "correct". Your assertion pm.expect(user.id).to.eql(42) fails, sure — but only on the one endpoint you asserted id on, not the other nine that return users. Meanwhile three client apps that did user.id + 1 are now computing "421" . That's structural drift , and it's what actually breaks API consumers: renamed fields, changed types, properties that quietly vanish. Field-by-field value assertions catch it patchily and by accident. Schema validation catches it systematically — and in Postman it costs about ten lines, because the ajv JSON-schema validator is built into the script sandbox. The ten lines In Scripts → Post-response on any request that returns a user: const userSchema = { type : " object " , required : [ " id " , " name " , " email " ], properties : { id : { type : " integer " }, name : { type : " string " }, email : { type : " string " , pattern : " @ " } } }; pm . test ( " Response matches the user schema " , () => { pm . expect ( pm . response . json ()). to . be . jsonSchema ( userSchema ); }); That single test now fails if id becomes a string, if email disappears, if name becomes an object — every structural mutation, whether or not you thought to assert on that field's value. For an endpoint returning an array of users: const userListSchema = { type : " array " , minItems : 1 , items : userSchema // reuse the object schema }; pm . test ( " List matches schema " , () => { pm . expect ( pm . response . json ()). to . be . jsonSchema ( userListSchema ); }); Share one schema across every endpoint The real power move: your API returns users from /users , /users/:id , /login , /teams/:id/members … and they should all be the same shape . Store the schema once as a collection variable (JSON, stringified), and every request validates against the sa

When building and validating US stock quantitative strategies, I used to focus solely on core market data metrics. Like most individual quantitative developers, I prioritized the integrity of price candlesticks and trading volume data, assuming that complete K-line datasets would guarantee reliable backtesting outcomes that align with real-market performance. This assumption held true for small-scale tests and short-cycle verification, until I encountered persistent inconsistencies between historical backtest reports and live trading results. After thorough troubleshooting of strategy logic, parameter settings, and sliding point simulation, I finally pinpointed the root cause — inconsistent and inaccurate timestamp processing from market data APIs, a trivial-looking but critical engineering detail that most developers overlook. Most engineering teams devote massive effort to verifying the accuracy of US stock API quote data, yet ignore standardized processing for time fields. In quantitative trading systems, timestamp offset and timezone disorder are far more impactful than superficial chart display errors. They directly distort candlestick combinations, disrupt technical indicator calculations, and ultimately mislead the entry and exit signal judgments of trading strategies. Core Requirement: Time-series consistency for valid backtesting Market data is essentially a continuous time-series stream, where price and volume merely represent transaction outcomes at specific timestamps. The time dimension acts as the fundamental anchor that defines the exact position of every single trade in the market timeline. Unlike A-share market data that adopts a unified time standard, US stock data providers deliver multiple incompatible time formats across different APIs, including pure UTC time, US Eastern trading time, and original exchange timestamp fields. Without unified parsing and conversion logic in your program, timestamp misalignment and data dislocation are inevitable.

We’ve all been there: hunched over a keyboard at 3 AM, neck craned forward like a turtle, debugging a race condition. "Tech neck" isn't just a meme; it’s a productivity killer. As developers, our spine is our most underrated hardware. In this tutorial, we are going to build a Real-Time Spine Posture Monitor . We will leverage real-time human pose estimation and MediaPipe Python libraries to track your posture via your webcam. By the end of this guide, you'll have a system that detects when you're slouching and sends a system notification to keep your ergonomics in check. This project is perfect for those looking into OpenCV computer vision and developer ergonomics solutions. The Architecture 🏗️ The logic is straightforward: we capture video frames, process them through a pre-trained neural network to find body landmarks, and apply some basic geometry to determine if your posture is healthy. graph TD A[Webcam Feed] --> B[OpenCV Frame Processing] B --> C[MediaPipe Pose Landmark Detection] C --> D{Extract Shoulder & Ear Coordinates} D --> E[Calculate Neck Inclination Angle] E --> F{Angle > Threshold?} F -- Yes --> G[Trigger System Notification] F -- No --> H[Continue Monitoring] G --> B H --> B Prerequisites 🛠️ Before we dive into the code, ensure you have the following installed: Python 3.9+ MediaPipe : Google’s framework for cross-platform ML. OpenCV : For video stream handling. PyObjC : (For macOS) to trigger native system alerts. pip install mediapipe opencv-python pyobjc Step 1: Initialize the Pose Engine MediaPipe makes pose estimation incredibly easy. We’ll use the Pose solution, which provides 33 3D landmarks for the human body. import cv2 import mediapipe as mp import math # Initialize MediaPipe Pose mp_pose = mp . solutions . pose pose = mp_pose . Pose ( static_image_mode = False , model_complexity = 1 , enable_segmentation = False , min_detection_confidence = 0.5 ) mp_drawing = mp . solutions . drawing_utils Step 2: Calculating the "Slouch" Angle 📐 To detect

Every API that sits behind an unreliable network eventually faces the same problem: a client sends a request, the connection drops before the response arrives, and the client has no idea whether the operation happened. Did the payment go through? Did the order get created twice? The client's only safe move is to retry — which means your server needs a story for what happens when the same "create this thing" request arrives more than once. That story is idempotency keys, and getting the details right is more subtle than it first looks. The core idea The client generates a unique token — typically a UUID — once per logical operation, and attaches it to every retry of that operation: POST /orders Idempotency-Key: 7c3fd9a2-df01-4b3e-9a55-1e5f9b6b6d55 {"sku": "WIDGET-1", "qty": 2} The server's job is to guarantee that no matter how many times a request with that key arrives, the side effect (charging a card, creating an order, sending an email) happens at most once, and every retry gets back the same response the original request would have produced. Note what this is not: it is not deduplicating by request body. Two requests with identical bodies but no key are legitimately two different orders for two widgets. The key is what marks them as "the same attempt," not the payload. The naive approach, and why it breaks A common first pass is a table like: CREATE TABLE idempotency_keys ( key TEXT PRIMARY KEY , response_body JSONB , status_code INT ); On each request: check if the key exists, and if so return the cached response; otherwise do the work and insert the result. This looks right and is wrong in a specific way: it has a race condition. Two retries can arrive concurrently (a client that timed out and fired a second attempt while the first was still in flight), both miss the cache check, and both execute the underlying operation. You've now charged the card twice. Making the check-and-do atomic The fix is to claim the key before doing the work, using the database's ow

Le 1er septembre 2026, le tarif de lancement de Claude Sonnet 5 s'arrête. L'input passe de 2 $ à 3 $ le million de tokens, l'output de 10 $ à 15 $ : +50 % sur les deux lignes, pour tout le monde qui appelle l'API en paiement à l'usage. La panique par défaut, c'est de couper des fonctionnalités ou de rétrograder vers un modèle plus faible. Il y a mieux, et c'est déjà dans l'API. Deux mécanismes — le prompt caching et le batch — encaissent la hausse à ta place, souvent avec de la marge. Voici le code, les chiffres, et les pièges que j'ai payés pour que tu ne les paies pas. Ce qui bouge exactement le 1er septembre Trois lignes suffisent à raisonner. Le reste du barème (Opus, Haiku, contexte 1M) ne change pas. Poste Sonnet 5 (par M de tokens) Jusqu'au 31 août Dès le 1er sept. Input standard 2 $ 3 $ Output 10 $ 15 $ Lecture cache (hit) 0,20 $ 0,30 $ Retiens la troisième ligne, parce que c'est elle qui gagne la partie. Un cache hit coûte 10 % du prix d'input . Même après la hausse, lire depuis le cache à 0,30 $ reste moins cher que l'ancien input plein à 2 $. Autrement dit, le contexte que tu répètes à chaque appel — un system prompt costaud, une doc, des exemples few-shot — peut être payé une fois puis relu pour trois fois rien. Le prompt caching, concrètement Le principe est simple : tu marques un bloc stable avec cache_control , et tout ce qui précède ce marqueur est mis en cache. Le premier appel paie une écriture ; les suivants, dans la fenêtre TTL, lisent à 10 %. import anthropic client = anthropic . Anthropic () DOCS = load_docs () # ~20 000 tokens, identiques à chaque requête def ask ( question : str ): return client . messages . create ( model = " claude-sonnet-5 " , max_tokens = 1024 , system = [ { " type " : " text " , " text " : " Assistant support de l ' app Lumière. " }, { " type " : " text " , " text " : DOCS , " cache_control " : { " type " : " ephemeral " }, # TTL 5 min }, ], messages = [{ " role " : " user " , " content " : question }], ) La question de

Authentication is often presented as a short sequence: Accept a username and password. Return a JWT. Protect a few endpoints. That is enough for a tutorial, but it is not an authentication lifecycle. Real applications must also answer harder questions: How is an email address verified without storing a reusable secret? What happens to existing sessions after a password reset? Can a user see and revoke a lost device? How do we prevent a rotated refresh token from being replayed? How should TOTP secrets and recovery codes be stored? How can an OIDC identity be linked without trusting email matching? I explored those questions while building FastAPI Production API v1.2.0 , a backward-compatible authentication lifecycle release for an open-source FastAPI backend foundation. This article explains the design decisions behind it—not just the endpoints that were added. 1. Model lifecycle tokens as scoped, single-use credentials Email verification and password recovery look similar from the outside: send a link, receive a token, and update an account. Treating them as interchangeable, however, creates unnecessary risk. The release uses account-action tokens with four important properties: Random: the token is generated as an opaque secret rather than derived from user data. Scoped: a verification token cannot be used as a password-reset token. Expiring: every token has a short, configurable lifetime. Single use: confirmation atomically marks the token as consumed. Only a hash of the token is persisted. The original value exists only long enough to be delivered to the user. This gives email verification and password reset a shared security primitive without making their policies identical. The main endpoints are: POST /auth/email-verification/request POST /auth/email-verification/confirm POST /auth/password-reset/request POST /auth/password-reset/confirm Both request operations return uniform responses. A caller should not be able to determine whether an email belongs to an a

The problem Steam's "Overwhelmingly Positive" badge is an all-time average. It can stay green for weeks after a patch, a pricing change, or a broken launch actually tanks a game's rating. Most devs find out from an angry tweet or a Reddit thread, not from Steam itself. I'd already built a similar review-mining tool for the App Store (a "copy+10%" market-research Actor — different post, different audience). Same week, I wondered: does Steam expose anything as clean as Apple's public RSS/Lookup endpoints? Turns out yes — better, actually. What Steam gives you for free Two public, zero-auth endpoints: https://store.steampowered.com/appreviews/<appid>?json=1&filter=recent https://store.steampowered.com/appreviewhistogram/<appid>?l=english The first gives you individual reviews with voted_up (boolean, no star-rating math needed), playtime_at_review , refunded , written_during_early_access — much richer than I expected. The second gives you a rolling histogram of recommendations_up / recommendations_down per period (weekly for active games, monthly for older ones), which is the actual key to detecting a real decline instead of noise. The bug that mattered I first tried Steam's documented day_range parameter to window the query_summary to "last N days." It doesn't do anything — I tested it against a game with 800K+ reviews spanning two years, day_range=30 and no day_range at all returned byte-identical totals. Not documented as broken anywhere I could find, so noting it here in case it saves someone else the debugging time. The appreviewhistogram endpoint is the actual fix: compare the most recent period's positive % against a baseline of prior periods, with a minimum-volume gate (I use 20 reviews/period) so a slow week on a small indie title doesn't get mistaken for a crisis. Real result Ran it against a game that had a rough launch week. Flagged an active decline immediately, and the negative-review sample broke down as 43% bugs/performance + 18% server issues — i.e., a

When a user logs out in one tab, the other tabs should follow. When they update their cart, every...

Klikk her: LLM Price Watch started as a simple problem: comparing per-token pricing across Claude, GPT, Gemini, DeepSeek, and Grok meant opening five pricing pages and doing the math by hand every time a new model dropped. So I built a calculator. Then I built an API behind it. Then I noticed something about who was actually going to call that API. The obvious version The first version of the API was exactly what you'd expect: GET /v1/models — every tracked model with current pricing GET /v1/models/:id — a single model GET /v1/calculate?model=X&input_tokens=N&output_tokens=N — cost for a specific call Straightforward. A human developer hits /calculate , gets a number, builds their cost estimate into a dashboard somewhere. Done. The part that changed the design The actual differentiator turned out to be a fourth endpoint: GET /v1/recommend?use_case=X . Instead of just returning prices, it returns a recommendation — which model fits a given use case (long-document summarization, high-volume classification, coding assistance, customer support) based on both price and the editorial analysis already written for the comparison pages on the site. Once that endpoint existed, the actual audience for this API stopped being "a developer building a cost dashboard" and started including something else: AI agents doing their own tool selection at runtime. An agent framework deciding which model to route a task to doesn't want to read a blog post — it wants a structured answer to "given this use case, what should I use, and what will it cost me." That's a tool call, not a page view. That reframing changed a few concrete decisions: CORS is wide open on purpose. This isn't an API with a dashboard in front of it — it's meant to be called directly from wherever the calling code lives, including client-side agent code. No API key required (for now). Every bit of friction between "an agent wants this data" and "an agent gets this data" is friction against the actual use case. A paid tie

If you are building anything that touches European business data — onboarding, invoicing, KYB, fraud checks — you will eventually ask the same question I did: which countries can I actually get company data from, for free, without an account? I could not find this written down anywhere, so I worked it out the hard way while building a supplier checker. Here it is. The baseline: VIES The European Commission runs VIES , which validates VAT numbers across all 27 member states plus Northern Ireland ( XI ). It is free, it needs no key, and it is the obvious starting point. Two things about it are worth knowing before you build on it. It answers one question: is this VAT number currently registered. It does not tell you the company is solvent, trading, or that it has not been struck off. A company in liquidation keeps a cleanly resolving VAT number for months, because deregistration and insolvency are run by different authorities on different timetables. Name and address are returned for 25 of the 28 jurisdictions, not all of them. Germany and Spain confirm registration but publish no company name through VIES. I tested three valid numbers for each before accepting that. For those two, a yes/no is genuinely all you can honestly show. Where you can go further, free Ten countries publish enough through a national register to add something meaningful on top of VIES: Country Free register Reports company state Reports VAT-active Romania yes yes yes Poland yes — yes Slovenia yes — yes Estonia yes yes — France yes yes — Greece yes yes — Bulgaria yes yes — Latvia yes yes — Czechia yes — — Finland yes — — Company state means the register tells you whether a business is inactive, in liquidation, bankrupt, insolvent, terminated or struck off. This is the valuable column, and only six countries have it. VAT-active matters more than it sounds. VIES cannot distinguish "this is a real company that is not VAT-registered" from "this number belongs to nobody". Three registers can. Note th

If you are integrating ZATCA Phase 2 (Saudi Arabia's Fatoora e-invoicing) and you have seen this: { "type" : "ERROR" , "code" : "signed-properties-hashing" , "category" : "CERTIFICATE_ERRORS" , "message" : "Invalid signed properties hashing, SignedProperties with id='xadesSignedProperties'" } ...after your invoice sailed through /compliance/invoices , this post is for you. It is the single most confusing failure mode in the whole integration, and the fix is not what the error suggests. The trap: SignedProperties exists in two byte-shapes The XAdES SignedProperties block is referenced twice in your signed document: ds:Reference URI="#xadesSignedProperties" carries a digest of the block. The block itself is embedded inside ds:Object > xades:QualifyingProperties . The natural assumption is that both refer to the same bytes. They do not. The hashed shape carries namespace declarations and starts at column 0: <xades:SignedProperties xmlns:xades= "http://uri.etsi.org/01903/v1.3.2#" Id= "xadesSignedProperties" > <xades:SignedSignatureProperties> <xades:SigningTime> 2026-08-07T02:14:33 </xades:SigningTime> <xades:SigningCertificate> <xades:Cert> <xades:CertDigest> <ds:DigestMethod xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" Algorithm= "http://www.w3.org/2001/04/xmlenc#sha256" /> The embedded shape carries no namespace declarations (they are inherited from ancestors) and its root element is indented to column 32 : <xades:SignedProperties Id= "xadesSignedProperties" > <xades:SignedSignatureProperties> Embed the hashed shape verbatim - the intuitive thing to do - and the gateway rejects with signed-properties-hashing , even though your indentation "looks right". The second half of the trap: the digest encoding The digest is not the raw SHA-256 bytes in base64. It is base64 of the hex string : const crypto = require ( ' crypto ' ); // hashedShape = the namespaced, column-0 variant above const propsDigest = Buffer . from ( crypto . createHash ( ' sha256 ' ). update ( Buffer .

Detection produces a number. Something has to turn that number into a response, and the response has two hard constraints that pull against each other: It must be proportionate . A score of 55 is not a score of 95, and treating them the same means either blocking clients you shouldn't or serving attackers you shouldn't. It must be invisible . An attacker who learns they were detected changes tactics, and you've converted a detection into a training signal for them. The second constraint rules out most of the obvious implementations of the first. The ladder Six tiers, evaluated in Rego, driven by the pushed risk score plus the gateway's own fast-path signals: allow → log → throttle → step_up → deny → revoke The policy is small enough to read in full, and mirrors the scorer's thresholds exactly: score_tier := "deny" if { score_fresh ; score_entry . score >= 85 } score_tier := "step_up" if { score_fresh ; score_entry . score >= 70 ; score_entry . score < 85 } score_tier := "throttle" if { score_fresh ; score_entry . score >= 50 ; score_entry . score < 70 } score_tier := "log" if { score_fresh ; score_entry . score >= 30 ; score_entry . score < 50 } final_tier := fast_tier if { tier_rank [ fast_tier ] >= tier_rank [ score_tier ] } final_tier := score_tier if { tier_rank [ score_tier ] > tier_rank [ fast_tier ] } The final decision is the more severe of two independent signals: the scorer's composite, and the gateway's own sub-second guardrails. The second exists because windowed scoring cannot react faster than one window, and a flood needs stopping before then. Fail open, deliberately # FAIL-OPEN: when the risk-score data is missing or stale we allow (with a # logged reason) rather than deny. This is the choice most likely to get an argument, so here's the reasoning. This is a detection layer bolted onto a production API. If the scorer, the pipeline, or the data path between them breaks, failing closed takes the real API down for every legitimate integration — a self-i

Every signal in the previous articles is statistical. They weigh evidence, they have thresholds, they can be argued with. Honeytokens are different in kind. A honeytoken is a record that does not exist and was never given to anyone . Nothing legitimate can ask for it, because nothing legitimate has ever held a reference to it. A request for one isn't suspicious — it's proof that someone is guessing or working from a stolen list. That makes it the highest-confidence signal available, and worth building carefully. Derivation: make the decoy recognise itself The obvious implementation is a table. Generate decoy IDs, store them, and check every miss against the table. That has two problems. It puts a database lookup in the request path on every miss — and misses are exactly what a flood produces. And it doesn't tell you whose decoy was tripped without another join. Instead, derive them: export function honeytokenFor ( clientId : string , n : number , generation = 0 ): string { const mac = createHmac ( ' sha256 ' , config . honeytokenSecret ) . update ( ` ${ clientId } : ${ generation } : ${ n } ` ) . digest (); return uuidFromBytes ( mac . subarray ( 0 , 16 )); } Three properties fall out of this, and they're the whole design: Recognition is stateless. Given any ID and any client, recompute the client's decoy set and check membership. No lookup, no cache, no round trip. The gateway precomputes each known client's set at startup into a Set and membership is O(1). Attribution is automatic. The client ID is inside the derivation. There is no "which client did this decoy belong to?" question — a decoy for integration-acme is not a decoy for anyone else, and cannot be. If a decoy seeded into acme's scope is requested by a different credential, that's information too. They're format-identical to real IDs. The output is shaped as a v4 UUID — correct version and variant nibbles — so it is indistinguishable from a real documents identifier: export function uuidFromBytes ( bytes

Microsoft released a dedicated AI Gateway tier of Azure API Management in public preview, with a control plane built around models, MCP servers and tools rather than APIs. It fronts Foundry, Bedrock, Vertex AI and OpenAI behind one endpoint, with policy cards instead of XML. Architects welcomed the consolidation while questioning where the governance boundary sits. By Steef-Jan Wiggers

I remember the exact moment the excitement turned to dread. I had just integrated GPT-4 into a side project—a small document summarization tool. The pricing page said $0.03 per 1K input tokens and $0.06 per 1K output tokens. Clean, simple, two numbers. I calculated roughly $0.01 per summary and smiled. Two weeks later the bill arrived: $87.43 for what I thought would be maybe $15. I wasn't being careless. I had read the docs. I knew about tokens. But the silent costs—the ones nobody puts in a neat table—had quietly multiplied my burn rate by six. That experience taught me that AI API pricing is a lot like buying a printer. The upfront cost is seductive; the real expense hides in the ink cartridges, the proprietary drivers, and the forced upgrades you never planned for. Let's talk about those hidden costs, because I'll bet you've either already hit them or you're about to. The Token Trap That Isn't What You Think Everyone knows tokens are the unit of billing, but the gap between "understanding tokens" and "feeling tokens" is enormous. First, there's the input/output asymmetry . GPT-4 charges double for output tokens. That's fine for short answers, but what about chain-of-thought? If you ask the model to reason step-by-step, those intermediate steps count as output tokens—and they add up fast. I had a single query balloon from 500 output tokens to 2,400 because the model decided to work through a logic puzzle aloud. My cost quadrupled without me changing a thing in my prompt. Then there's the system prompt tax . Many developers stuff context into system messages: instructions, examples, formatting rules. Those are input tokens paid every single time, even when the user's query is tiny. If your system prompt is 1,500 tokens and you handle 10,000 requests, that's 15 million input tokens you're paying for—whether the model uses them or not. And don't get me started on retry costs . You hit a rate limit or your request times out? The token count for that failed request? S

What started as a vision for mapping urban gardens has evolved into something much bigger. Over the past weeks, we've built a complete decentralized ecosystem that connects IoT sensors, robots, and communities using Monero (XMR) and MYZ tokens. The Journey: From Gardens to Streets It all began with a simple idea: create a map for urban gardens. But we quickly realized that a map alone wasn't enough. We needed a full system that could: Monitor soil health in real-time Automate irrigation and analysis Enable private, decentralized payments Connect communities and institutions Here's what we built. 🗺️ The Urban Garden Map Using Leaflet.js and a REST API, we created an interactive map where anyone can register their urban garden. The map supports: Geolocation with /nearby endpoint Full CRUD operations for gardens Search by name and city Check it out: Live Demo 📡 Arduino Sensors for Smart Agriculture We integrated Arduino sensors to monitor soil conditions in real-time: pH (0-14 scale) EC (Electrical Conductivity) Temperature and Humidity The data flows through Node.js APIs and is stored in MongoDB, making it accessible for analysis and reporting. 🦾 The Robot Ecosystem We built a family of software robots that can receive payments automatically in MYZ and XMR: 1. AgricoloBot - The Garden Assistant Monitors soil health Generates automatic reports Provides recommendations for farmers 2. Robot Arm - The Physical Gardener 4 DOF (Degrees of Freedom) Controlled via WebSocket Can water, plant, analyze, and harvest 3. CleanStreetBot - Street Cleaning Robot Reports waste with geolocation Automates zone cleaning Generates reports for municipalities 4. RecicloBot, PuliziaBot, CompostBot - Recycling and Waste Management Monitor containers and optimize collection routes Track composting and organic waste management 💰 Decentralized Payments with Monero and MYZ All robots receive automatic payments through an escrow system: 85% → Robot owner 2% → MyZubster platform 8% → Bosco Community

Google's Custom Search JSON API is closed to new customers, and existing customers have until 2027-01-01 to move off it. That deadline takes searchType=image with it. I maintain cse-bridge , a small self-hosted service that speaks Google's customsearch/v1 wire format on top of your own SearXNG instance, so migrating is a base-URL change rather than a rewrite. Web search shipped first. This week I added image search — and it turned out to be much less mechanical than "map some more fields", because two of the assumptions that hold for web results are actively wrong for image results. Both are worth knowing whether or not you ever use my code. If you are writing anything that normalises image search results, you will hit them. Trap 1: link is not the page For a web result, Google's link is the URL of the page. Easy. For an image result, link is the image file itself , and the page it was found on lives in image.contextLink : { "link" : "https://facts.net/wp-content/uploads/2020/08/AdobeStock_209028852.jpeg" , "displayLink" : "facts.net" , "image" : { "contextLink" : "https://facts.net/nature/animals/red-panda-facts" , "thumbnailLink" : "https://ts1.mm.bing.net/th?id=OIP.I_aIcVvl98DbktQmP297ugHaE7&pid=15.1" , "width" : 4000 , "height" : 2666 } } SearXNG has it the other way round: the result's url is the page, and the image is in a separate img_src field ( documented here ). So the naive mapping — reuse the web mapper, add an image object — produces items whose link points at an HTML document. That fails silently , which is what makes it nasty. Your JSON still validates. Your item count is right. Every field is a well-formed URL. But every client that does <img src={item.link}> — which is the entire point of image search — renders nothing, and it looks like the images are broken rather than like your mapper is wrong. The fix is a rule, not a patch: if a result has no image URL, drop the whole result . Never fall back to the page URL to keep the count up. export functio