DEV Community: Nikolas Dimitroulakis

Your API's newest users are agents...

Nikolas Dimitroulakis — Fri, 25 Sep 2026 08:14:55 +0000

Who called your API last?

For us, the honest answer is more and more often an agent. Claude Code debugging a flow. An assistant looking up an order. Someone's custom GPT.

Our tools still assume a human pressing Send.

This post is about that gap. How we ran into it ourselves, how most teams handle it today, and what we changed.

How we ran into it

We run ApyHub, a catalog of utility APIs. This year we wanted assistants like Claude, ChatGPT, and Le Chat to call those APIs directly. So we built an MCP server and published it to the official MCP registry.

It worked. People used it.

Then we noticed something uncomfortable. We now had two descriptions of the same API.

One was the requests and tests we already trusted. The other was the MCP server, written by hand, sitting next to them.

Change an endpoint? Update both. Forget one? Find out when an agent breaks.

Testing the MCP side was its own chore. Connect an inspector, click a tool, read the JSON, close the tab. Next release, repeat from memory.

None of this is dramatic. It's just the kind of friction that adds up quietly until you notice you've built a second, worse copy of something you already had.

The three situations we kept hitting

When we looked closer, it was really three different problems. They all involve MCP, which is why they're easy to blur together. The difference is who is calling whom.

1. Your own coding agent, debugging blind

Checkout returns a 400. You ask Claude Code for help.

Today, you paste the error. Maybe a curl command. The agent reasons about what might be wrong. When it wants to test something, it writes its own curl, guesses the headers, and asks where the token lives.

You end up being the agent's hands.

What we wanted was simpler. The requests already exist in the project. Let the agent run them.

So that's what we built. We use Voiden for this, the open-source API tool we work on, where requests live as plain Markdown files in the repo. One button (or voiden agent in the terminal) and your coding agent can list, run, and inspect those requests. It calls the real endpoint and reads the real response. In our checkout example, it spots the missing header on its own.

This is on for the whole project by default. Our reasoning: it's you, your editor, and your own agent. Small trust boundary.

I'm fairly confident about that. But I know some teams will disagree, especially with production credentials in the environment. If that's you, I'd like to hear where you'd draw the line.

2. Someone else's agent, calling one endpoint

Your support assistant needs to issue refunds. Only refunds.

Today, someone writes an MCP server. Picks an SDK. Redefines the inputs as a schema. Wires up auth. Figures out secrets. Hosts it.

Now there's a new codebase describing an API you already had. It drifts. Nobody notices until an agent sends a field that was renamed two sprints ago.

This was exactly our ApyHub story.

What we do now: take the refund request that's already written and tested. Mark it as a tool. Choose which values the agent can set, in this case just the order ID. Secrets stay in your environment. That's the whole server.

Nothing is exposed until you mark it. Once other people's agents are involved, opt-in felt like the only honest default.

One rule is more opinionated. A tool is only available while its tests pass. Test goes red, tool goes offline.

That's strict. With a flaky test, it will annoy you. We chose it anyway, because an agent losing access felt better than an agent calling something nobody has verified lately.

Is that the right trade? I genuinely go back and forth. Curious what others think.

3. Testing an MCP server, yours or a vendor's

Two versions of this. You run your own MCP server and want to know it still works before a release. Or you're about to build on a vendor's server and want to see what it really returns.

Today: an inspector tab. Click, read, close. Gone. Or a one-off script that lives in someone's home folder.

What we wanted was the same thing we already had for REST. Save the call. Add assertions. Run it in CI.

So now an MCP call is just another block in the file. Point it at a server, pick a tool, check the response with the same auth and assertions you'd use anywhere else. Before a release, it confirms search_orders still returns the shape you expect. For a vendor's server, like Notion's, the file becomes a working reference the team can rerun.

The part I care about most

All three live in one file.

The request you test with is the one your agent runs. It's the one you publish as a tool. And it sits right next to your MCP tests.

One description of the API, instead of three that slowly disagree.

Because it's a plain file in the repo, changes go through a pull request. If someone widens what the refund tool accepts, a reviewer sees it in the diff.

That's the real point for me. Giving an agent access to an API is a permission decision. Permission decisions deserve a review trail.

Why we keep building this

Voiden isn't our core business. ApyHub pays for it. We build it because we use it every day, and when something bugs us enough, it ends up in the next release.

This one bugged us for months.

It shipped in 2.3, along with a few other things. The changelog has the full list if you're curious.

An open question, since I don't think anyone has this fully figured out yet:

how are you deciding what agents can touch in your APIs today? Config file? Gateway? Hand-written MCP server? Gut feeling?

I'd like to hear what's working, and what isn't.

If you want to poke at it: voiden.md · GitHub

Create calendar invites in Node.js that update and cancel cleanly

Nikolas Dimitroulakis — Tue, 22 Sep 2026 16:50:19 +0000

Create calendar invites in Node.js that update and cancel cleanly

Send .ics calendar invites from Node.js with Nodemailer, then move and cancel them without leaving duplicate events in anyone's calendar.

Sending one calendar invite is easy. The bugs show up on the second email.

You move the meeting by an hour and every attendee now has two events. You cancel it and the event stays on everyone's calendar. You send it from Gmail and the Accept and Decline buttons never appear.

All three come from the same place: the rules for how calendar clients match an update to the original event. Those rules live in RFC 5546 (iTIP), which sits on top of the file format in RFC 5545. This post builds a small Node.js module that creates, updates and cancels an invite and gets those rules right.

The three rules that prevent duplicate events

Keep the UID. Every event has a UID. An update or a cancellation must reuse it. A new UID means a new event.
Increment SEQUENCE. RFC 5546 says the organizer MUST increment SEQUENCE when the start, end, recurrence or status changes. Clients ignore an update whose sequence is not higher than what they already have.
Match METHOD. METHOD:REQUEST is an invitation, METHOD:CANCEL is a cancellation. The email's calendar part must carry the same method as the file, or clients treat it as a plain attachment.

create  ─► UID=abc  SEQUENCE=0  METHOD:REQUEST
update  ─► UID=abc  SEQUENCE=1  METHOD:REQUEST   (replaces, no duplicate)
cancel  ─► UID=abc  SEQUENCE=2  METHOD:CANCEL    (removes the event)

Three ways to generate the .ics

You need the .ics text before you can send it. There are three common routes.

Approach	Pros	Trade-offs
Hand-written string	No dependencies, full control	You own line folding, escaping, `DTSTAMP` and time zone blocks
`ics` npm package	Open source (ISC), runs locally, supports `uid`, `sequence`, `method`, attendees, alarms and recurrence	Times go in as local or UTC (`startInputType`), so converting from a named zone is your job
ICS generator API	JSON in, `.ics` out; accepts IANA zones like `Europe/Athens`; recurrence, reminders and attendees as fields; cancellation with one query parameter	Good to know: it is a network call and needs an ApyHub API key

Hand-written strings are fine for a single static event. The format has sharp edges, though. RFC 5545 requires lines to be folded at 75 octets and specific characters to be escaped, and a missing detail often fails silently in one client only.

The ics package is a solid choice when you want everything local and your times are already in UTC.

The API route fits when events come from users in many time zones, or when an AI agent is the one creating them. It is what the code below uses.

Pros: you send the meeting date, start time and a zone name, and it returns the finished file. The same request body with ?event_type=cancel produces the cancellation. There are two endpoints: one returns the .ics file for email attachments, and one returns a signed download link for "Add to calendar" buttons.
Best for: apps that send invites on behalf of users, booking flows, and agents.

Setup

mkdir invites && cd invites
npm init -y
npm i nodemailer
export APY_TOKEN=your_token_here
# optional, to send real email:
export SMTP_URL="smtps://user:pass@smtp.example.com"

Without SMTP_URL, the script uses Nodemailer's JSON transport and prints each message instead of sending it. That is useful for a dry run. You need Node 18 or later for the built-in fetch.

The code

Save this as invite.mjs:

// invite.mjs
// Create, update and cancel a calendar invite from Node.js.
// Usage: APY_TOKEN=your_token node invite.mjs
// Set SMTP_URL (for example smtps://user:pass@smtp.example.com) to send real email.
// Without it, Nodemailer prints the message as JSON instead of sending it.
import nodemailer from "nodemailer";

const API = "https://api.eu.apyhub.com/apyhub/generate-ical-event/download";
const TOKEN = process.env.APY_TOKEN;

const transport = process.env.SMTP_URL
  ? nodemailer.createTransport(process.env.SMTP_URL)
  : nodemailer.createTransport({ jsonTransport: true });

// Turn event details into .ics text
async function buildIcs(event, { cancel = false } = {}) {
  const params = new URLSearchParams({ output: "invite" });
  if (cancel) params.set("event_type", "cancel");

  const res = await fetch(`${API}?${params}`, {
    method: "POST",
    headers: { "apy-token": TOKEN, "Content-Type": "application/json" },
    body: JSON.stringify(event),
  });
  if (!res.ok) throw new Error(`ICS generation failed: ${res.status}`);
  return res.text();
}

// Nodemailer's method must match the METHOD line inside the file,
// so read it from the file instead of hardcoding it
const methodOf = (ics) => ics.match(/^METHOD:(\w+)/m)?.[1] ?? "PUBLISH";

async function send(event, ics, subject) {
  const method = methodOf(ics);
  const info = await transport.sendMail({
    from: event.organizer_email,
    to: event.attendees_emails,
    subject,
    text: `${event.summary} on ${event.meeting_date} at ${event.start_time} (${event.time_zone})`,
    icalEvent: { method, filename: "invite.ics", content: ics },
  });
  return { method, messageId: info.messageId };
}

export async function createInvite(event) {
  const ics = await buildIcs(event);
  return send(event, ics, `Invitation: ${event.summary}`);
}

// Same id, higher sequence: calendars replace the event instead of adding a copy
export async function updateInvite(event, changes) {
  const next = { ...event, ...changes, sequence: event.sequence + 1 };
  const ics = await buildIcs(next);
  return { event: next, ...(await send(next, ics, `Updated: ${next.summary}`)) };
}

export async function cancelInvite(event) {
  const next = { ...event, sequence: event.sequence + 1 };
  const ics = await buildIcs(next, { cancel: true });
  return { event: next, ...(await send(next, ics, `Canceled: ${next.summary}`)) };
}

// Demo: create, move by an hour, then cancel
if (process.argv[1].endsWith("invite.mjs")) {
  let event = {
    id: "team-sync-2026@example.com", // store this with your meeting record
    sequence: 0,
    summary: "Weekly team sync",
    meeting_date: "2026-10-06",
    start_time: "09:00",
    end_time: "09:30",
    time_zone: "Europe/Athens",
    location: "https://meet.example.com/team-sync",
    organizer_email: "organizer@example.com",
    attendees_emails: ["dev1@example.com", "dev2@example.com"],
    recurring: true,
    recurrence: { frequency: "WEEKLY", interval: 1, count: 10 },
    reminders: [{ action: "display", minutes_before: 10 }],
  };

  console.log("create", await createInvite(event));

  const updated = await updateInvite(event, { start_time: "10:00", end_time: "10:30" });
  event = updated.event;
  console.log("update", { sequence: event.sequence, method: updated.method });

  const canceled = await cancelInvite(event);
  console.log("cancel", { sequence: canceled.event.sequence, method: canceled.method });
}

Run it:

node invite.mjs

create { method: 'REQUEST', messageId: '<fc8efa38-...@example.com>' }
update { sequence: 1, method: 'REQUEST' }
cancel { sequence: 2, method: 'CANCEL' }

One UID, three emails, sequence 0 to 2. Each attendee ends up with one event that moves and then disappears.

Design decisions worth copying

Store id and sequence with your meeting record. They are the only link between the email you sent last week and the one you send today. Put them in the same table as the meeting, and increment sequence in the same transaction as the change.

Read METHOD from the file. Nodemailer's calendar docs say the method option should match the METHOD inside the .ics. Parsing it from the generated file means the two stay in sync. If the file has no METHOD line, the code falls back to PUBLISH, and clients will show a plain "add to calendar" file with no RSVP buttons. Log that case.

Keep the email simple. The same Nodemailer page recommends only text, html and a single icalEvent for the best client compatibility. Extra attachments are a common reason RSVP buttons disappear.

Use a zone name, never an offset. Europe/Athens handles daylight saving on its own. +03:00 is wrong for half the year, and a weekly recurring meeting will cross that line.

Common problems and fixes

Symptom	Cause	Fix
Update creates a second event	New UID on the update	Reuse the stored `id`
Update is ignored	`SEQUENCE` not incremented	`sequence + 1` on every change
Cancel does nothing	Missing `METHOD:CANCEL`, or old sequence	`?event_type=cancel` with the same `id` and a higher `sequence`
No Accept/Decline buttons	Method mismatch, or extra attachments	Match `icalEvent.method` to the file; send only text, html and the invite
Meeting one hour off after a DST change	Fixed UTC offset	Send an IANA zone name

Letting an AI agent send invites

Scheduling is one of the first jobs people hand to agents: "book 30 minutes with the team next Tuesday." The agent needs a reliable way to turn that into a real invite.

The calendar invite generator is available through ApyHub MCP, like every endpoint in the catalog. An agent can discover it, read its parameters, and call it directly without a hand-written wrapper or tool definition. Pair it with your own tool that stores id and sequence, and the agent can reschedule and cancel without creating duplicates.

Going further

Validate attendee addresses before sending with an email validation and deliverability check, so invites to typos do not bounce.
For an "Add to calendar" button on a web page, use the signed .ics download link endpoint with the same request body and point the button at the returned URL.
Browse the rest of the API catalog.

FAQ

How do I create a calendar invite in Node.js?
Generate an .ics file with a stable UID, then send it with Nodemailer's icalEvent option and method: "REQUEST". The code above does both, using an ICS file generator API for the file.

How do I update a calendar invite without creating a duplicate?
Send a new .ics with the same UID and a higher SEQUENCE. Clients replace the existing event.

How do I cancel a calendar invite?
Send METHOD:CANCEL with the same UID and an incremented SEQUENCE. With the API, add ?event_type=cancel to the same request.

How can I test these APIs before writing code?
Run the request from the API's page in the catalog, send the curl command from your terminal, or open it in Voiden, the open-source API client, add your API key and run it. The free plan covers testing: 5 calls a day and 3,000 atoms a month, with no credit card. The demo above uses 3 calls.

Does this work with Google Calendar, Outlook and Apple Calendar?
They all read RFC 5545 files and follow the UID and SEQUENCE rules. Send one test invite to each before launch, since each client renders the email a little differently.

About ApyHub

ApyHub is a curated API catalog and trusted operational layer for developers and AI agents, with over 1,500 endpoints and capabilities, and it keeps growing. Every API is verified before listing and carries machine-readable certification for GDPR, SOC 2 and ISO 27001. One subscription covers the catalog, every endpoint is MCP-ready by default, and the free plan needs no credit card.

Build a phishing link checker in Node.js with three API calls

Nikolas Dimitroulakis — Tue, 22 Sep 2026 16:35:18 +0000

Every app that lets users paste a link has the same problem. Someone will eventually paste a phishing link, and your app will render it as a clickable, trustworthy-looking element inside your UI.

The volume is high. The Anti-Phishing Working Group counted 971,181 phishing attacks in the first quarter of 2026, up 13.8% from the quarter before (APWG Phishing Activity Trends Report, Q1 2026, May 2026). Most of those attacks end in a URL.

This post builds a small link checker you can drop into a chat app, a comment system, a CRM or an AI agent. It takes any URL and returns allow, warn or block, plus the reasons. It uses three API calls and a few checks that cost nothing.

What the checker does

A phishing link usually has three traits you can test for:

It hides where it goes. Short links and redirect chains mask the real destination.
It is already known. Many phishing URLs get reported to threat databases within hours.
It is new. Attackers register a lookalike domain, run a campaign for a few days and move on.

So the pipeline is:

input URL
   │
   ▼
1. Expand redirects ──► final URL
   │
   ├──► 2. Threat lookup (known malicious?)   ─┐
   │                                            ├──► score ──► allow / warn / block
   └──► 3. Domain age (registered last month?) ─┘
        + local checks (https, raw IP, punycode)

Steps 2 and 3 are independent, so they run in parallel.

The order matters. If you check the short link itself, you are checking bit.ly, which is always clean. Every check has to run on the final destination.

The APIs

All three calls go through ApyHub with one API key:

Step	API	What it returns
Expand	Resolve Short URL API	Final URL, full redirect chain, a `truncated` flag
Threat lookup	Generate Link Preview API	Threat type if the URL is in a malicious-URL database, page metadata if it is clean
Domain age	Domain Age API	WHOIS creation date and age in days

The Link Preview API is doing double duty. With secure_mode: true it checks the URL against a malicious-URL database before it fetches anything. A flagged URL comes back like this:

{
  "data": {
    "url": "http://example-malicious-site.com",
    "threat": "malware",
    "reported_malicious": true
  }
}

A clean URL comes back with the page title, description and images, so the same call gives you a safe preview card to show your users.

Setup

mkdir link-checker && cd link-checker
npm init -y
npm i tldts
export APY_TOKEN=your_token_here

tldts extracts the registrable domain from a hostname. You want the age of acme.co.uk, and a naive split on dots would give you co.uk.

You need Node 18 or later for the built-in fetch.

The code

Save this as check-link.mjs:

// check-link.mjs
// Usage: APY_TOKEN=your_token node check-link.mjs "https://bit.ly/example"
import { getDomain } from "tldts";

const API = "https://api.eu.apyhub.com";
const TOKEN = process.env.APY_TOKEN;

async function call(path, { method = "GET", body } = {}) {
  const res = await fetch(`${API}${path}`, {
    method,
    headers: {
      "apy-token": TOKEN,
      ...(body && { "Content-Type": "application/json" }),
    },
    body: body && JSON.stringify(body),
  });
  if (!res.ok) throw new Error(`${path} returned ${res.status}`);
  return res.json();
}

// Step 1: follow every redirect to the real destination
const unshorten = (url) =>
  call("/dosvak/unshorten-url", {
    method: "POST",
    body: { url, max_hops: 15, timeout_s: 8 },
  });

// Step 2: check the destination against a malicious-URL database
const scan = async (url) => {
  const { data } = await call("/apyhub/generate-link-preview", {
    method: "POST",
    body: { url, secure_mode: true },
  });
  return data;
};

// Step 3: how old is the registrable domain?
// WHOIS data is patchy, so a failed lookup counts as "unknown", not as a crash
const domainAge = (domain) =>
  domain
    ? call(`/dosvak/domain-age?domain=${encodeURIComponent(domain)}`).catch(
        () => ({ age_days: null })
      )
    : Promise.resolve({ age_days: null });

// Free checks that need no API call
function localSignals(finalUrl) {
  const { protocol, hostname } = new URL(finalUrl);
  const signals = [];
  if (protocol !== "https:") signals.push(["no_https", 1]);
  if (/^\d{1,3}(\.\d{1,3}){3}$/.test(hostname)) signals.push(["ip_host", 2]);
  if (hostname.split(".").some((part) => part.startsWith("xn--")))
    signals.push(["punycode_host", 2]);
  return signals;
}

export async function checkLink(input) {
  const chain = await unshorten(input);
  const finalUrl = chain.resolved;
  const domain = getDomain(finalUrl); // "login.acme.co.uk" -> "acme.co.uk"

  // Steps 2 and 3 are independent, so run them in parallel
  const [preview, age] = await Promise.all([scan(finalUrl), domainAge(domain)]);

  if (preview.reported_malicious) {
    return { verdict: "block", finalUrl, reasons: [`threat:${preview.threat}`] };
  }

  const signals = localSignals(finalUrl);
  if (chain.truncated) signals.push(["redirect_chain_truncated", 2]);
  if (chain.hops.length > 4) signals.push(["long_redirect_chain", 1]);

  if (age.age_days == null) signals.push(["domain_age_unknown", 1]);
  else if (age.age_days < 30) signals.push(["domain_under_30_days", 3]);
  else if (age.age_days < 180) signals.push(["domain_under_6_months", 1]);

  const score = signals.reduce((sum, [, weight]) => sum + weight, 0);

  return {
    verdict: score >= 3 ? "warn" : "allow",
    score,
    finalUrl,
    domain,
    domainAgeDays: age.age_days,
    title: preview.title ?? null,
    reasons: signals.map(([name]) => name),
  };
}

if (process.argv[2]) {
  console.log(JSON.stringify(await checkLink(process.argv[2]), null, 2));
}

Run it:

node check-link.mjs "https://bit.ly/example"

What the output looks like

A short link that lands on a nine-day-old domain over plain HTTP:

{
  "verdict": "warn",
  "score": 4,
  "finalUrl": "http://secure-acme-login.co.uk/verify",
  "domain": "secure-acme-login.co.uk",
  "domainAgeDays": 9,
  "title": "Sign in",
  "reasons": ["no_https", "domain_under_30_days"]
}

A link that is already in the threat database:

{
  "verdict": "block",
  "finalUrl": "https://evil.example/",
  "reasons": ["threat:malware"]
}

A normal link:

{
  "verdict": "allow",
  "score": 0,
  "finalUrl": "https://github.com/",
  "domain": "github.com",
  "domainAgeDays": 6500,
  "title": "GitHub",
  "reasons": []
}

The reasons array is the useful part. Show it to your moderators, log it, or turn it into the warning text users see ("This link goes to a site registered 9 days ago").

Why the scoring works this way

The weights are a starting point. Tune them against your own traffic. A few decisions are worth explaining.

A threat-database hit blocks outright. This is the one signal with very few false positives, so it skips the score.

Domain age warns and never blocks. New domains are the strongest signal for campaigns that no database has seen yet. They are also every startup that launched last month. A warning label ("new site, check before you log in") handles both cases.

Unknown age is a mild signal. Some country-code TLDs do not publish WHOIS creation dates. Treating null as "suspicious" would flag half of some regions. Treating it as "safe" would give attackers an easy gap. A weight of 1 splits the difference.

Raw IPs and punycode add weight. Legitimate sites rarely send users to http://185.x.x.x/login. Punycode (xn--) hostnames are how lookalike characters like a Cyrillic "а" get into a domain. Both are free to check.

Making it cheaper

Each check costs three API calls. Three changes cut that a lot in production:

Skip the expand step for direct links. Only call the unshortener when the hostname is a known shortener or when the link came from an untrusted source.

const SHORTENERS = new Set(["bit.ly", "t.co", "tinyurl.com", "ow.ly", "is.gd", "buff.ly"]);

const needsExpand = (url) => SHORTENERS.has(new URL(url).hostname);

Cache domain age by domain. A domain's creation date does not change. Cache it for a day and your hundredth link to github.com costs nothing.

Check on submit, then store the verdict. Run the check once when a user posts the link, save the result with the message, and render from the stored verdict. Re-checking on every page view multiplies your costs by your read traffic.

What this does not catch

Be clear with yourself about the gaps:

Lookalikes on old domains. A compromised WordPress site from 2014 passes the age check. The threat database is your only defense there, and it lags new campaigns.
Clean first hops. Some kits show a harmless page to scanners and a login form to real visitors. No URL-level check sees that.
Messages without links. Phone-number scams, fake invoices with bank details and voice phishing never touch this pipeline.

Treat the checker as one layer. It removes the obvious cases before a person has to judge them. It does not replace user reports, rate limits on new accounts or a way to pull a message after the fact.

Using it from an AI agent

AI agents now read inboxes, open links and fill in forms on a user's behalf. An agent that follows a phishing link does it faster and with less hesitation than a person.

The same three checks work as a gate before an agent acts on any URL. Every endpoint used here is available through ApyHub MCP, so an agent can discover, evaluate and call the Resolve Short URL API, the Generate Link Preview API and the Domain Age API directly, without a hand-written wrapper or tool definition. A system prompt line such as "check every URL with the link tools before opening it, and stop on any threat result" is enough to wire it in.

Going further

If links are only part of your abuse problem, a few related checks slot into the same pattern:

Domain WHOIS Lookup API for the registrar and full registration record when a domain gets a warning.
Temporary and Disposable Emails API to stop throwaway accounts that post phishing links in the first place.
Identity & Fraud Verification API for a single risk score across email, IP and phone at signup.

FAQ

How do I check if a link is safe before opening it?
Expand it to the final URL first, then check that URL against a threat database and look at how old its domain is. The Resolve Short URL API, Generate Link Preview API in secure mode and Domain Age API cover those three steps.

Is a new domain always a phishing domain?
No. New domains carry more risk, and most legitimate sites were new once. That is why the checker warns on domain age and blocks only on a threat-database match.

Does my server visit the phishing site when I expand the link?
The redirect-following happens on the API side, so your own servers never connect to the suspicious host.

How can I test these APIs before writing code?
Run each one from its page in the ApyHub catalog, send the curl request from your terminal, or open the request in Voiden, the open-source API client, add your API key and run it. The free plan works for testing: it allows 5 calls a day, which is enough for one full link check plus a couple of single calls.

Can I run this on every chat message?
Yes, if you check once on submit and cache domain age. See "Making it cheaper" above.

About ApyHub

ApyHub is a curated API catalog and trusted operational layer for developers and AI agents. The catalog offers over 1,500 endpoints and capabilities, and it keeps growing. Every API is verified before listing and carries machine-readable certification for GDPR, SOC 2 and ISO 27001. One subscription covers the whole catalog, with usage measured in atoms, a per-call unit that reflects the compute work each request does. Every endpoint is MCP-ready by default through ApyHub MCP. ApyHub is headquartered in Amsterdam, with offices in the Netherlands, Greece and India, and serves 65,000+ monthly developer workspaces. The free plan needs no credit card, and API providers can publish to the catalog through the provider program.

We built an MCP server for 1500+ Tools for devs and their agents

Nikolas Dimitroulakis — Fri, 04 Sep 2026 08:54:07 +0000

Hey everyone, I’m one of the co-founders of ApyHub.

We recently built an MCP server that lets your agent use 1500+ tools from one connector.

The idea is pretty simple.

Instead of wiring an MCP server to one API, then another, then another, the agent can search the catalog, find the API it needs, see what it does, and call it.

ApyHub has 400+ services and 1,500+ endpoints across things like file conversion, OCR, data extraction, validation, geolocation, SEO, image processing, and AI.

So you can give an agent a fairly small set of tools and still have access to a much larger set of capabilities.

Some examples:

convert a Word document to PDF
extract text from a PDF
OCR a scanned document
extract text from a webpage
compress a video
generate a QR code
validate an EU VAT number
validate email DNS
convert currencies
parse a resume
check SERP rankings
generate speech from text

The useful part is that these can also be chained.

For example:

Take a scanned invoice → OCR it → extract the data → validate the VAT number → convert the currency → generate a PDF.

Or:

Extract a webpage → check readability → summarize it → check its search ranking.

You don't have to build those workflows ahead of time. The agent can compose the calls based on the task.

There is also curation.

Giving an agent 1,500 tools creates tool bloat and overwhelms the model with context.

Instead, you can select which endpoints an agent may use: a document agent might have 15–20 endpoints, while an enrichment agent uses a different set.

One other thing we cared about was credentials.

Normally, connecting an agent to ten vendors requires ten API keys stored somewhere in the agent’s environment or context. Those traces eventually appear in logs, observability tools, bug reports, etc.

With ApyHub, the agent uses one scoped key.

The MCP server is at:

https://apyhub.com/mcp

And the catalog is here:

https://apyhub.com/catalog

The thing I’m most interested in is what people actually try to make their agents do with the catalog. There are a lot of boring utilities in there already, but there are always going to be things we haven't covered yet.

If you have any questions, I’m happy to assist :)

How Should an API Client Look in 2026? A Comparison of the Field

Nikolas Dimitroulakis — Tue, 23 Jun 2026 08:23:08 +0000

API tooling is having a rough year, and that's actually the interesting part.

Postman killed free teams in March. Insomnia forced cloud sync in v8 and is still rebuilding trust. Bruno is absorbing most of the migration wave. And a handful of smaller tools are betting the whole category has been building the wrong abstraction since day one.

I spent the last few weeks actually using seven of these tools on the same real workflow: REST and GraphQL requests, env vars across staging and prod, auth, and docs that are supposed to stay in sync with the requests they describe. Here's where each one actually stands.

The real architectural split

Most comparisons line up feature checkboxes: offline, yes/no; Git integration, yes/no. That misses the real fault line in the category, which isn't a feature. It's where your API definitions actually live.

Workspace-centric tools (Postman, Insomnia, Hoppscotch) store collections inside the app's own data model. You can export them, sync to Git, even self-host the sync layer. But the source of truth is the app's internal state. The export is a snapshot, not the real thing.

File-centric tools (Bruno, Voiden, Yaak, in different ways) store collections as actual files on disk, read directly by Git, your editor, and CI, with no export step. The file is the source of truth.

Open source matters here too, and not as a checkbox. A closed-source tool can disappear, get acquired, or change its pricing model overnight, and your only option is to migrate. Every open-source tool below can be forked, audited, or kept alive by the community if the maintainers walk away. That's a real, structural advantage worth weighing on its own, separate from whatever feature set a tool ships with this month.

The field at a glance

Tool	Open source	Architecture	Format	Best known for
Voiden	✅ Apache 2.0	File-centric, git-native	Markdown (`.void`)	Composable blocks, readable without the app
Postman	❌	Workspace-centric, cloud-first	Proprietary	Richest feature set, MCP integration
Insomnia	✅ Apache	Workspace-centric, cloud sync (v8+)	Proprietary	GraphQL heritage, Kong backing
Hoppscotch	✅ MIT	Web-first	Proprietary	Largest FOSS star count, browser workflow
Bruno	✅ MIT	File-centric, git-native	Bru Lang (proprietary)	Community momentum, fast release cadence
Yaak	✅ MIT	File-centric, git-friendly	Proprietary	Minimal, intuitive design, Tauri/Rust stack
curl	✅ MIT	No GUI, no collections	N/A	The universal baseline, scriptable, everywhere

Postman

Still the default for teams that haven't migrated, and still genuinely capable: the richest feature set here, an established MCP integration for agent workflows, tooling most developers already know. Open source: no. The free-team removal in March 2026 was a real breaking point, and the cloud-first model means your definitions live on Postman's infrastructure, not yours.

Insomnia

Real GraphQL-first heritage and Kong's backing. Open source under Apache, which is a genuine point in its favor. But forcing cloud sync in v8 cost it real community trust that hasn't fully come back, and Git sync is an add-on to a cloud-first design, not the actual architecture.

Hoppscotch

The largest open-source star count in the category, MIT licensed, and a genuinely good browser-based workflow. Also the clearest example of a different category: web-first, not file-centric, not really part of the offline/git-native model the rest of this list is about.

Bruno

The closest direct competitor to the file-centric model. Real community momentum, a fast release cadence, MIT licensed, genuinely offline-first and git-native: .bru files on disk, no export, no account. The real gap: .bru is a proprietary format. A .bru file means nothing without Bruno installed. No plugin SDK yet either, despite it being the single most-requested feature on its tracker.

Yaak

Built by the same person who built and sold Insomnia, and it shows: Yaak's whole pitch is design restraint, doing less, staying out of your way, instead of stacking on more features. MIT licensed, built on Tauri and Rust rather than Electron, which gives it a noticeably lighter footprint than most of this list. It mirrors workspaces to your filesystem for Git, so it's file-centric in practice, but its actual differentiator isn't the file format, it's the interface itself: minimal by default, with depth available only when you go looking for it. Worth watching, with one real caveat: community contributions are currently limited to bug fixes, not new features, so its roadmap is more centrally controlled than Bruno's or Voiden's.

curl

Not really in the same category, and worth including anyway, because it's the baseline everyone else is implicitly compared against. No GUI, no collections, no environments as a concept. Just a request, scriptable, in every CI pipeline and every dev's muscle memory. Nothing here replaces curl for a one-off request; the entire point of the other six tools is managing the complexity curl doesn't try to solve.

Voiden

Same file-centric premise as Bruno, with two real differences: the format is plain Markdown, not a proprietary DSL, and the request itself is built from composable blocks instead of a fixed form. A .void file is readable in any editor, on GitHub, in a PR, with zero dependency on Voiden being installed. Headers, auth, and params are reusable blocks, not duplicated fields. Apache 2.0 licensed. The honest gap: a much smaller community right now than Bruno or Hoppscotch, since the category itself is still young.

There's a short demo comparing Voiden and Postman side by side on the same request if you want to see the workflow difference instead of just reading about it. ⬇️

https://youtu.be/mpMarhwODY4

Try Voiden here: https://voiden.md/download

So which one should you actually use?

No clean winner, because the field is genuinely split on what people are optimizing for.

Need the deepest feature set and already have a working Postman flow? The migration cost might not be worth it yet.

Want file-centric and git-native with the largest existing community today? Bruno, with the tradeoff that your files are tied to its own format.

Want the same file-centric model with a lighter footprint and a deliberately minimal interface? Yaak, with the tradeoff that the roadmap is more centrally controlled right now.

Want files that are readable without the tool installed, real composability instead of fixed forms, and you're fine being on a younger, smaller project? Voiden.

And if you just need to fire off one request without installing anything? curl was already enough.

The actual story of 2026 isn't that one tool won. It's that "where do your API definitions live, and who can keep the tool alive if the maintainers disappear" became real questions instead of implementation details nobody thought about.

Star counts, license status, and contribution policies above reflect late May 2026 and move fast; check each project's repo before deciding based on community size alone.

Modern API Tooling: An 11-Principle Scorecard

Nikolas Dimitroulakis — Fri, 19 Jun 2026 23:59:48 +0000

A while ago I came across a really good article on the future of API tooling:

https://efp.asia/blog/2025/12/24/api-tooling-crisis/

It lays out a set of criteria for what modern API clients should look like:

Local-first, filesystem-centric: collections and requests live directly in the project repo
Support for OpenAPI specs and GraphQL schemas, plus straightforward testing
Zero login wall: works fully offline without accounts or mandatory cloud sync
Git-native collaboration: uses version control instead of proprietary cloud workspaces or seat licenses
Native performance: built with high-performance tech (e.g. Rust), not browser wrappers
Extensible design: modular plugin architecture that doesn’t bloat the core
Universal imports: OpenAPI, GraphQL, Postman collections, etc.
Proxy agnostic: works cleanly with interception tools like Charles or mitmproxy
Scripting and auth flows: pre-request and post-response hooks
Straightforward testing: built-in code-based testing of API responses

I agree with all of these. The only thing I’d add is pricing as another important dimension.

Recently I was experimenting with a pricing MCP and decided to run a quick test: evaluate all the API clients I know against these criteria using https://pulse.pricingsaas.com/.

Scoring was simple:

Each principle is rated 0 (missing), 1 (partial), or 2 (fully met). Final score is normalized to a 10-point scale.

Overall rankings (out of 10)

Bruno — 8/10
Voiden — 8/10
Yaak — 7/10
Insomnia — 6/10
cURL — 6/10
HTTPie — 5/10
Postman — 5/10
Requestly — 5/10
Hoppscotch — 4/10
Apidog — 4/10

Key takeaway: no perfect API client yet

Every tool fails on at least a few of the 11 principles, so none fully matches the “ideal” API tooling model. The ceiling right now seems to be around 8/10.

What separates the top tools (Bruno, Voiden, Yaak)

The strongest tools tend to share a few traits:

Local-first, filesystem-based storage
Git-native collaboration
No forced login (or minimal account gating)

Where they still fall short is usually native performance, since most GUI tools are built on Electron.

A few structural patterns across the space

Electron is the default weakness Most GUI tools (Bruno, Insomnia, Postman, Requestly, Hoppscotch, Apidog) rely on Electron. The only real exception is Yaak, which uses Tauri + Rust and is much closer to true native performance.
Zero-login is a clear dividing line Several major tools are effectively excluded because they require accounts: Postman, Insomnia, Hoppscotch, Apidog.
Pricing is becoming a core constraint Most tools are increasingly account-gated or paid-tier driven. Voiden stands out as fully free with no tiering, while Postman is heavily penalized due to its pricing model and limited free tier.

Tool-level notes (high level)

Bruno: strong balance of scripting, testing, and Git-native design, but held back by Electron
Voiden: most aligned overall, especially due to being fully free and extensible
Yaak: best native performance, but lacks scripting and testing
Insomnia: strong feature set, but weakened by login and pricing dependence
Postman: best-in-class scripting and testing, but cloud-first and heavy
cURL / HTTPie: great primitives, but not full API design environments

Final insight

The ideal API client would likely combine:

Yaak’s native Rust performance
Voiden or Bruno-level scripting, testing, and Git-native workflows
Right now, the space is split between:
Local-first developer tools (Bruno, Voiden, Yaak)
Cloud-first enterprise platforms (Postman, Apidog, Hoppscotch, Insomnia)

Full results here: https://share.pricingsaas.com/reports/ps_-1DO_vX/20260619_220350_52a40f15/api-client-scorecard-v5.html

Voiden : offline API client, Git-native, Markdown-based. Looking for contributors in TypeScript/Electron/plugin development.

Nikolas Dimitroulakis — Mon, 25 May 2026 11:17:47 +0000

Hey there,

Bit of context first: I am a member of a 30 people+ team and most API clients we used felt like they were built for a different job than what we actually did.

Our team lives in Git, our communication is happening on slack, our docs written and maintained on confluence and after some time they always drift away from the actual requests inside Postman.

So we built and open sourced Voiden a few months ago: an API tool where all that: specs, tests, context and docs are always together in the same executable plain text file (markdown). We also made this Git native so that every change is versioned and tracked just like code.

The last change we have made is to add a Runner so that one can run the files directly from the terminal and CI/CD pipelines.

here is the tool: https://voiden.md/download

repo: https://github.com/VoidenHQ/voiden

Looking for contributors in TypeScript/Electron/plugin development.

Good first issues:
https://github.com/VoidenHQ/voiden/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22

and a discussion:
https://github.com/VoidenHQ/voiden/discussions/386

Cross-Platform Desktop Wars: Electron vs Tauri: How do you explain the tradeoffs to users?

Nikolas Dimitroulakis — Wed, 25 Mar 2026 14:59:25 +0000

Hello,

I am writing cause I wanted to get some opinions from folks here that have actually built and shipped with Electron (or Tauri).

Background: Building an API IDE on Electron. Not really “just an API client”, and not a(nother) thin wrapper around a webapp either. It’s a pretty original desktop tool with a lot of editor/IDE-like behavior - not the typical form centric behavior that postman or others have: local workflows, richer interactions, and some things that honestly would have been much harder for us to build and iterate on this quickly in a more constrained setup. Thats why Electron.

this is the tool:

https://github.com/VoidenHQ/voiden

Now, as adoption is growing, we are starting to get the usual questions about memory footprint and app size.

The (slightly) frustrating part is this:

When the app is actually being used, the app-side memory is often pretty reasonable. In many normal cases we are seeing something like 50–60 MB for the actual usage we care about (even added it in the app itself for people to check it out).

But then people open Activity Monitor, see all the Chromium/Electron-related processes, and the conversation immediately becomes:

“yeah but Tauri would use way less”

And then, without realizing, I suddenly end up talking and philosophizing about Electron, instead of discussing the tool itself (which is what I am passionate about :)

And of course, I get it. The broader footprint is real. Chromium is not free. Electron has overhead. Pretending otherwise would be foolish. So we are constantly optimizing what we can, and we will keep doing so…

At the same time, I do feel that a lot of these comparisons feel weirdly flattened. For example people often compare:

full Electron process footprint VS the smallest possible Tauri/native mental model

…without always accounting for development speed, cross-platform consistency, ecosystem maturity, plugin/runtime complexity, UI flexibility, and the fact that some apps are doing much more than others. Which is by the way the reason that we went with Electron.

So all this context to get to my real question, which is:

How do you explain this tradeoff to users in a way that feels honest and understandable, without sounding like you are making excuses for Electron?
And also, for those of you who have had this conversation a hundred times already:

What do you say when people reduce the whole discussion to “Electron bad, Tauri good”?

Have you found a good way to explain footprint in practical terms?

Where do you think optimization actually matters, vs where people are mostly reacting to the idea of Electron?

Mostly trying to learn how others think about this , especially those who have built more serious desktop products and had to answer these questions in the wild.

Would love your thoughts and advice!

Burgers, APIs, and the State of Developer Marketing

Nikolas Dimitroulakis — Fri, 13 Mar 2026 13:43:13 +0000

Wanted to share some thoughts as a founder who has been building and shipping developer tools and applications (including open source, Voiden).

When I started, every discussion and engagement I had with dev-tool marketers and experts revolved around the idea that effective developer marketing should be a combination of genuinely helpful content, engaging tutorials, thoughtful blog posts, and insightful guides that actually help people get unblocked or see common problems from a new perspective.

I wanted to — and still want to — contribute to that kind of ecosystem.

And to be clear, I still believe this is what good developer marketing looks like.

But I also realized that a lot of what passes for “dev marketing” today (especially in the API tooling space that I’m in) is much more about SEO, keyword stuffing, backlinks, and thinly veiled sponsored content.

Case in point:

I came across a post on dev.to titled:

“12 open-source alternatives to popular dev tools.”

Great idea, right?

Except the first tool listed wasn’t open source at all — it’s a paid SaaS.

Some of the “alternatives” weren’t even truly comparable. It felt much more like keyword stuffing and backlinking than a genuine resource meant to help developers.

And some of the comments below were things like:

“Great list!”

So I made a joke in the comments calling out the issue. Something along the lines of:

“You could also add the tool to a list of ‘Top burger joints in Manhattan’, since people could also test APIs while eating a burger, right?” or something like that.

In hindsight, maybe not the best joke ever made.

The author of the post apparently thought the same and deleted my comment.

Twice.

But this isn’t really about that one tool or that one post.

I have seen many companies do similar things.

That said, I also don’t want to overgeneralize and in a weird way I can even sympathize a bit.

A lot of founders and makers fall into a strange trap: the idea that self-promotion is inherently bad.

So instead of honestly sharing what they’ve built or what they’ve learned, they look for clever tactics or “growth hacks” to appear neutral, helpful, or educational while still getting attention.

In a way, they’re staging the play they think developers want to see.

It’s understandable (maybe).

But it can easily cross the line into something misleading or manipulative.

I honestly don’t know whether this happens because people underestimate developers’ ability to see through it, or because the SEO benefits eventually pay off anyway.

Maybe both.

From my experience, developers are skeptical and notoriously allergic to being marketed to. And when marketing stretches the truth this far, it can slowly erode trust — not just in one tool, but in the ecosystem as a whole.

The lesson I’m taking away as a founder:

Authentic engagement wins.

Build tools that solve real problems.
Share honest insights.
Be simple and transparent about what you are doing.

A little vulnerability goes a long way.

Anyway, enough whining.

Let’s make it fun:

What’s the most absurd developer marketing you’ve seen lately that made you roll your eyes?

Voiden is now extensible via community plugins

Nikolas Dimitroulakis — Tue, 10 Mar 2026 21:07:09 +0000

A lot of developer tools follow the same pattern: They start simple and then new ideas come. Then these these new ideas become built-in features.

This is of course fine (and natural) but over time, the core can become huge, harder to maintain and evolve, and slower to experiment with.

When we started building Voiden we wanted to avoid this trap.

What we observed from our experience and also while talking to other developers is that different teams use API tools very differently, in different scenarios.

So we decided that forcing everyone into the same giant feature set doesn’t really make sense.

So, instead of putting everything in the core, we decided to have the tool grow through a plugin system. This way, it can be flexible and extensible since new functionality can live outside of the core tool.

The idea is simple:

Keep the core lean. Let the ecosystem grow around it. Developers can build extensions independently and users can just install the pieces they actually need.

Keeping Voiden flexible and extensible is one of the key design principles we had from day one and I am very happy with this milestone.

Curious what kinds of extensions people will build 🙂 (we already have a few community plugins in the works)...

Start contributing: https://docs.voiden.md/docs/plugins/build-a-plugin
Repo here: https://github.com/VoidenHQ/voiden

API security and compliance in 2026

Nikolas Dimitroulakis — Fri, 06 Mar 2026 10:22:05 +0000

Choosing an API based on functionality is one thing. Getting it approved for production is where things can get tricky.

The moment your product sends data to a third-party service, questions come up:

→ Where is the data stored?
→ How long is it retained?
→ Are third-party processors involved?
→ Is it compliant with GDPR, SOC 2, or other standards?

This is often the step that slows down adoption more than the integration itself.

At ApyHub, we tackle this head-on.

Every API in our catalog comes with clear, standardized info on data handling and compliance. That means teams can:

→ See certifications and disclosures upfront (GDPR, SOC 2, ISO 27001)
→ Understand exactly where and how data is stored and handled
→Track retention and third-party processing
→ Stay up-to-date as APIs evolve

The result? Teams can find, evaluate and approve APIs faster, with confidence, without digging through scattered docs or privacy policies.

We are happy as our catalog keeps growing with new APIs. But in the end, it’s not just about functionality.

It’s about trust, compliance, and true data sovereignty.

Explore certified APIs here: https://apyhub.com/catalog

Scripting in API tools?

Nikolas Dimitroulakis — Tue, 24 Feb 2026 17:43:38 +0000

Spent months thinking about scripting in API tools.

Honestly, most tools don’t go far enough. They stop at JavaScript, a limited sandbox and a system that is not really extensible.

That works for small tests, but it can also quickly break down when you want to start building real, multi-step workflows.

We wanted to go further. So we spent time observing how developers actually work with APIs, talking to them, and learning from the patterns and frustrations in real workflows. We saw token rotations handled manually, small helper scripts scattered across repos, and tools that forced engineers into JavaScript even when their stack was Python, Go etc.

So for Voiden Pre & Post Request Scripts adapt to how developers work.

JavaScript + Python (first-class): use the language you already know and trust
Real runtimes & package imports: run actual code, import libraries, reuse existing logic
Stateful workflows: share variables, store data, and chain requests dynamically
Orchestration-ready: automate multi-step flows, token rotations, and dependent API calls

Again, it's a basic principle we had from day 1: API tools should not dictate how devs think. It should adapt to how they work.

We believe this is one of the most powerful scripting systems available in any API client today.

And we are just getting started.

🌐 Beta: https://voiden.md/download#beta
📂 GitHub: https://github.com/VoidenHQ/voiden