DeviAI
API & Microservices

Small services.Really running.

The kind of endpoint you actually reach for: focused, documented, and live. No API key, no database, no worker — these run entirely on the edge. Try them here, or curl them yourself.

01Try it live
runs on vercel · no key · always live

Generate a branded 1200×630 social-share card from query params — rendered on the edge with the framework’s built-in image runtime. It updates as you type.

Or call it yourself

curl "https://deviaisolutions.vercel.app/api/og?title=Proof+over+promises.&tag=Engineering&theme=ink" --output og.png
Live generated OG image

GET /api/og?title=Proof+over+promises.&tag=Engineering&theme=ink

02How this actually works

01 — Zero moving parts

No key, no database

Each endpoint is a single serverless function. No secrets to leak, no data store to run — which is exactly why they’re always up, and why this page runs every request live rather than replaying a recording.

02 — Built to be trusted

Guarded on purpose

The preview endpoint fetches URLs on your behalf, so it’s SSRF-guarded — https only, internal and private hosts refused, response size and time capped. The boring safety work is the point.

03 — We dogfood it

Used, not just shipped

The OG image service renders the same social cards our own pages share. If it breaks, our previews break — so it’s held to a real standard, not a demo one.

03Endpoints
GET/api/ogQuery params → branded 1200×630 social-share PNG (edge)
GET/api/previewAny URL → normalized OpenGraph / meta JSON, SSRF-guarded

Two today, and the pattern is the point: a focused endpoint, documented, guarded, and genuinely live. Need one shaped to your own data or workflow — extraction, conversion, validation, webhooks? That’s the build.

04When the endpoint has to remember

A queue is a different shape.

Both endpoints above hold nothing. A request arrives, an answer goes back, and if the function dies mid-flight the caller simply retries — which is why they need no key, no database and no worker.

That stops being true the moment the event is a customer’s message and losing it is a customer who never got a reply. Then you need a queue, acknowledgements, and something that behaves correctly when a process is killed halfway through. We built one and recorded it being killed mid-delivery — it lost nothing, and took 22 seconds to recover on its own.

Stateless vs. stateful

On this page
Edge function · no state · retry is the caller’s job
whatsapp-normalizer
Redis Streams · at-least-once · reclaims after a crash