Skip to content

GLOBUS.studio API

Small APIs that solve real problems.

Checks, validation, content generation and finance. One request, a predictable answer, no integration week.

  • 24 APIs
  • 5 categories

The collection

API collection

Pick an endpoint and read the parameters on its page. Response time is measured on the production server.

DNSBL Check

The DNSBL API checks an IP against a fixed set of DNS blacklists with direct queries. Returns the zones where the address is listed, without third-party HTTP.

Email checker

The email validation API checks syntax, resolves the mail server and tests whether the mailbox exists. Returns exists, invalid or unknown with clear reasons.

Bot detector (UA)

The User-Agent detection API matches a string against a maintained bot signature list. Returns a flag and the matched signature, using the request header by.

TOR detector

The Tor detection API checks an IP against the current exit-node list. Returns a tor flag and a short message without exposing the list or blocking privacy.

How it works

Three steps from URL to answer

  1. 01

    Pick an endpoint

    Copy the URL from the API page. The parameter table lists every accepted value and its type.

  2. 02

    Send a request

    Use curl, fetch or any HTTP client. No SDK and no build step: the API speaks plain HTTP.

  3. 03

    Read the answer

    JSON for structured data, plain text for single values, PNG for generated images and QR codes.

APIs for developers

APIs for developers who need one answer

GLOBUS.App is a catalog of focused APIs for developers. Each endpoint does one job: it takes a small set of parameters and returns a small, predictable response. You send a request from a script, a service or a prototype, read the value and move on.

For APIs for developers, the catalog is small on purpose. A page for every endpoint lists the parameters, the response shape, the limits and a working curl example. That keeps the first request short and the second one boring, which is what an integration should be.

What you can check

The catalog covers identification and data lookup, validation and security, bot and threat detection, content generation and finance.

Look up an IP address or a domain, check an email or a card number, separate a crawler from a browser, generate a QR code or read exchange rates. If a check needs more context, the page links to a guide that explains the data and the cases where the answer is not enough.

How a request works

Every endpoint is a plain HTTP URL. Send the parameters as a query string or a form body. Ask for JSON when you need structure, or plain text when a shell script only needs one value. You do not need an SDK, a client library or a build step.

The documentation has a page for every endpoint with a request example and a response shape. The API collection groups the endpoints by category, so the list stays readable as it grows.

Built for production

The APIs for developers in this catalog return a stable shape and set a clear content type. A check that fails because of bad input returns a message you can show to a user or write to a log. Rate limits are per endpoint, so a slow WHOIS query cannot exhaust the budget for QR codes.

The service does not set tracking cookies and does not keep the caller address after the response. A generated password or a card number is not written to a log. Read the note on response formats before you parse the output in a strict way.

APIs for developers in a small team

The catalog fits small teams that need one answer inside a larger product: a support tool that checks an email, a signup form that validates a card, a scraper filter that separates a crawler from a browser. You can test an endpoint from the browser or from a terminal before you add it to the codebase.

You do not need an account to read the documentation, and the examples use plain curl. A prototype can call the endpoint directly; a production service should add a timeout, a retry rule for temporary failures and a fallback for the case where the answer is missing.

What an endpoint page contains

Every API for developers page follows the same order: a short description, the endpoint URL, a parameter table, an example request and a list of related endpoints. The parameters show the type and whether the value is required. The example uses curl so it works in a terminal without a client library.

The page also names the response shape. A JSON object, a plain string and an image need different handling, and a client should know which one to expect before the first call. That structure keeps the catalog predictable as the number of APIs for developers grows.

Errors, limits and support

A failed request returns a message that a client can log or show to a user. Bad input is different from a temporary failure: bad input needs a fix in the request, while a timeout needs a retry. The API pages describe both cases so the client does not treat every error as a reason to stop.

Rate limits are per endpoint. If a call returns a limit error, wait and retry with a small delay. For an endpoint that fails repeatedly, send the request URL, the time and the response through the contact page. Do not send a card number or a password in a support message.

From a check to a decision

A single check rarely decides anything on its own. An email validator says the mailbox exists, and the signup form still decides whether the address is allowed. A Tor exit node belongs to a network, and the login flow still decides whether to ask for a second factor. A geolocation result names a country, and the store still decides which currency to show.

That is why the API pages describe the response and the limits, and the guides describe the policy around them. The endpoint gives you a fact; the product gives it a consequence. APIs for developers work best when that line stays clear.

Why the collection stays small

A short list of APIs for developers is easier to trust than a long one. Every endpoint earns its page: it solves a problem that appears in a script, a form or a support tool, and it has a response that a client can check. If a new field would turn one endpoint into three products, it gets a new page instead.

The catalog also stays small because a failed check has to be explainable. A developer should be able to read the page, understand the answer and decide what to do with it. That is the standard for every API for developers that joins the collection, and it is why some ideas stay out.

One API at a time

The catalog is built for APIs for developers who need one answer, not a platform. A team can start with one API for developers and add another when the product needs it. That path keeps the first release short, and it keeps every API for developers in the catalog independent of the rest.

An API for developers that solves one problem is easy to test and easy to replace. For APIs for developers who ship on a schedule, that is the main benefit. A team can try a second API for developers without a migration, and the APIs for developers that do not fit can stay out of the codebase.

Start with the catalog

The APIs for developers here are grouped by task. Open the API collection, pick the category that matches the task and copy the URL. If the answer needs a policy, read why we keep the endpoints small and the API blog for longer notes.

Further reading: RFC 9110, HTTP Semantics.

Custom work

Need an API that does not exist yet?

Describe the task and the response format. We will estimate the endpoint, the integration and the maintenance.

Start a conversation