Free Slugify API Endpoint

Slugify a title

Post your text to the free slugify API endpoint and read the single field that comes back. No account, no key, and no header beyond the content type.

curl -X POST https://aisenseapi.com/services/v1/slugify \
  -H "Content-Type: application/json" \
  -d '{"data": "Blåbærsyltetøy på Ås!"}'

{"slug":"blabaersyltetoy-pa-as"}

Three Norwegian vowels went in and only a-z came out. The exclamation mark disappeared, and the spaces became hyphens.

German follows the same table. Große Übung becomes grosse-ubung, because the sharp s expands to two letters while the umlaut simply falls away.

What the free slugify API endpoint returns

One field, nothing else. There is no echo of the input, no length and no flag telling you which characters were replaced, so the response body stays the same shape whatever you send.

Runs of separators collapse rather than stack up. Posting " Hello --- World!! 2026 " returns hello-world-2026, with the leading and trailing whitespace gone and every run of punctuation reduced to a single hyphen. You will never get a double hyphen back.

A fixed transliteration table

The mapping lives in the source, not in the locale of whatever machine happens to answer the request. That is the whole point. A locale-driven slugifier gives you one answer on a developer laptop and a different answer on a production box, and the mismatch usually surfaces months later as a broken link.

Every row below came from this endpoint:

Two patterns are worth noticing. Case never survives, so the uppercase and lowercase forms of a letter land on the same output. And accented Latin letters lose the accent rather than the letter, which keeps words readable: café becomes cafe rather than caf.

Only æ and ß expand into two characters. Everything else maps one to one or collapses into a hyphen, so a slug is close to the length of the title it came from.

HTTP 400 when nothing sluggable remains

An empty slug is worse than an error. A caller that receives one will happily build a URL out of it and end up with a path that points at the wrong place, so the endpoint refuses instead.

curl -X POST https://aisenseapi.com/services/v1/slugify \
  -H "Content-Type: application/json" \
  -d '{"data": "!!!"}'

{"error":"No sluggable characters in the input."}

That is HTTP 400. Punctuation, emoji and scripts outside the transliteration table all filter out, and when nothing is left the free slugify API endpoint fails the request rather than returning a blank string.

Leaving the field out entirely is also a 400, with a different message:

{"error":"No data to slugify."}

Two messages, one status code. Check the status rather than parsing the text, and treat both as a signal that the title needs a fallback - a record id, or a timestamp - before it becomes a path.

Where a deterministic slug earns its keep

The last one is the strongest argument for calling the free slugify API endpoint over rolling your own. When a Python service, a Node worker and a database migration all need the same key for the same name, one fixed table beats three regular expressions that drifted apart.

Privacy and limits

The service-wide limit is 5000 requests per IP per 24 hours, with no key and no account behind it. Slugs are cheap to cache: the output is deterministic, so a title you have already slugified never needs a second call.

Every endpoint on the service is listed in the free public REST APIs reference. Slugify sits alongside the encode and decode pairs on the Encoding APIs hub, which is the place to compare it with the reversible formats. That distinction matters: slugifying throws information away on purpose, so unlike the Base64 encode API endpoint there is no route back to the original title. Keep the title in your own store and treat the slug as a derived key.

Related APIs