Featured image of post Why I Built Small Public APIs for Automation Workflows
Case Studies

Why I Built Small Public APIs for Automation Workflows

A practical case for turning repeat automation logic into small public APIs, with examples from n8n, document generation, scraping, server work, and AppSheet.

In automation work, the same “small” functions keep showing up again and again.

Not every one of them deserves a separate service. But some of them deserve more than another copied code block inside one workflow.

That is how this set of public APIs appeared in my stack. I did not start with the idea of building an API collection for its own sake. I kept running into the same narrow operations across n8n flows, scraping jobs, document generation, and internal tools, so I pulled those operations into small reusable endpoints instead.

For this kind of task, a thin Cloudflare Worker is often the cleanest unit: simple input, simple output, minimal moving parts, and easy reuse from different environments.

The short answer

I usually turn a utility into a small public API when:

  • I need the same logic in several workflows;
  • the input and output contract is narrow and stateless;
  • the function is useful from no-code, low-code, and code-based tools;
  • there are no secrets or customer-specific rules inside it;
  • browser or curl access is useful for testing and debugging.

That matters most in the kind of automation stack I described in n8n vs Make vs Zapier: Which Automation Stack Fits Real Business Workflows and in the hybrid internal-tool pattern from AppSheet vs Custom Build vs Hybrid: How to Choose for Internal Business Tools.

Why not keep everything inside n8n or app code

Some of this logic could stay inside n8n code nodes, helper functions, or application code. In some cases, it should.

But once the same transformation appears in multiple places, duplication becomes the real cost:

  • the logic gets copied into several workflows;
  • one flow gets updated while another keeps older behavior;
  • testing becomes fragmented;
  • low-code tools need separate workarounds instead of one shared contract.

n8n already includes plenty of useful building blocks, and UUID generation is built into many languages and platforms. That does not remove the value of a small external endpoint. It just raises the bar for extraction. I only break out the pieces that I want to reuse from different tools without re-implementing them every time.

The APIs I actually use

Transliteration for workflow-safe text

I use translit.api.airat.top when I need Russian Cyrillic text converted to Latin in automation flows. In practice, that usually means filenames, slugs, folder keys, or text that should be normalized before it moves further through a pipeline.

This is especially useful in n8n, where a simple HTTP request can keep transliteration behavior consistent across different flows instead of relying on ad hoc string handling in each one.

Number to words for invoices, acts, and payment documents

num2words.api.airat.top exists because document workflows often need more than a numeric amount. In generated acts, invoices, or payment-related documents, I may need both the amount itself and the amount written out in words.

That is not a hard problem, but it is exactly the kind of boring repeated logic that should stay correct and reusable. Instead of embedding currency wording rules into every document flow, I can call one endpoint and keep the result consistent.

Metadata and domain lookup for scraping and enrichment

For scraping, lead enrichment, or general website analysis, I often need metadata before I need anything more complicated.

meta.api.airat.top gives me a fast way to fetch title, description, canonical URL, and social metadata from a page. That is useful when a workflow needs to preview a page, validate a target URL, or enrich records before storing them.

whois.api.airat.top helps when the workflow needs domain information, registration context, or a basic lookup step before deeper processing. If a flow touches websites and domains often enough, having a stable lookup endpoint is cleaner than rebuilding that logic inside each automation.

DNS and IP utility for server and infrastructure work

Some APIs are less about business documents and more about operational convenience.

dns.api.airat.top is useful when I want to check records from a script, a browser, or a quick automation step without switching context. It is a small thing, but infrastructure work is full of small things.

ip.api.airat.top is even more direct. Sometimes I simply need to know which public IP a request is leaving with, or I need clean request/network metadata while checking behavior around servers, proxies, or external services.

UUID generation for automation glue

uuid.api.airat.top exists because “generate a new ID” shows up in more places than it should.

Yes, UUID generators are already built into many languages, platforms, and libraries. But a dedicated endpoint is still useful when ID generation needs to happen from a plain HTTP request, from a low-code flow, from a shell script, or from a tool that is easier to integrate by URL than by custom code.

I also keep uuid.airat.top as a browser tool. I use it when I need quick manual generation, and it is also handy for bulk ID work in AppSheet-related scenarios where having a simple browser UI is more convenient than opening a local script.

Why these APIs are public

There is a practical reason these ended up as public endpoints instead of hidden internal microservices.

Public access reduces friction. A utility becomes immediately usable from:

  • a browser tab;
  • curl;
  • an n8n HTTP Request node;
  • a server script;
  • a low-code or no-code environment that can call URLs but does not want extra runtime logic.

For small stateless helpers, that matters a lot. The README becomes both documentation and a ready-to-test usage surface. Each repo stays tiny, the deployment model stays simple, and the endpoint can be reused anywhere it makes sense.

Cloudflare Workers are a pragmatic fit for this pattern because these APIs are intentionally narrow. They do not need a big backend platform. They need a stable edge endpoint and low operational overhead.

What should not become a public API

This pattern works well only when the boundaries are strict.

I would not expose logic this way if it includes:

  • secrets, tokens, or internal credentials;
  • customer-specific business rules;
  • sensitive state or write operations;
  • permission-heavy internal logic;
  • workflows where an extra network hop creates more complexity than value.

That is the part many teams miss. A small public API is useful when it is boring infrastructure: one narrow operation, one clear contract, and no hidden operational risk.

Practical takeaway

If a function keeps reappearing in your automations, ask four questions:

  1. Is it stateless?
  2. Is the contract simple enough to explain in one README?
  3. Would an HTTP endpoint make it easier to reuse from different tools?
  4. Can it be public safely?

If the answer is yes, a tiny API may be cleaner than another copied script block.

That is how these projects appeared in my stack. Not from a plan to build an API portfolio, but from repeated operational friction inside real workflows.