Documentation
Everything you need to turn a sentence into a running API and use it.
How it works
apinido turns a plain-language description into a deployed backend. You describe what the API should do; we generate the code, security-validate it, and deploy it as an isolated container. You get a live URL and API key — usually within two minutes.
- Describe the API in a sentence (e.g. “a booking API with services, availability slots and conflict checks”).
- apinido proposes endpoints + a data model — you can iterate in chat.
- Click Deploy → build → it runs. You get a URL and API key.
You pay in cents, only for real runtime — while an API sleeps, compute is €0. You start with €2 free credit.
Writing a good prompt
The more specific the description, the better the result. Name the entities, their fields and the operations (endpoints). You don't write code — you write what the API should do.
- List entities and fields: “products (name, price in cents), orders (items, status)”.
- State operations: “POST /orders creates an order, GET /orders?status= filters”.
- Mention rules: “check the slot is free, otherwise return 409”.
- If you need end-user login, say so — registration + login gets added.
Editing an existing API: open it and describe the change in chat (e.g. “add a priority field”). It deploys as a new version — with rollback.
Your API — URL, key, requests
After deploy you get a public URL and an API key. Send the key in the x-api-key header on every request.
curl https://api.apinido.com/t/<your-api-id>/todos \ -H "x-api-key: ak_..."
A write (POST/PUT/PATCH) with a JSON body:
curl -X POST https://api.apinido.com/t/<id>/todos \
-H "x-api-key: ak_..." -H "content-type: application/json" \
-d '{"title":"Buy milk"}'Save your API key after deploy — you can also reveal it again in the API detail. No key returns 401, a wrong key 403.
End-user authentication
If your API needs its own user accounts, apinido can generate registration and login (JWT). Just mention it in the description (“with user login”).
- POST /auth/register and POST /auth/login create and authenticate a user.
- Protected endpoints require a token in the Authorization: Bearer <token> header.
- This is separate from the API key (which protects the whole API) — this is login for your end users.
Data, logs and versions
The API detail gives you several tools:
- Data — a browser for the database contents (tables and rows), with search.
- Logs — the running app's real logs with timestamps and a level filter.
- Versions — every deploy is a version; you can roll back to a previous one.
- Console — quick endpoint testing straight from the browser.
Secrets and integrations (e.g. Resend)
Want your API to call an external service with an API key (sending email, Stripe, OpenAI…)? Store your own secrets in the API settings — they're injected as environment variables and the code reads them via process.env.
- API settings → Environment variables → add e.g. RESEND_API_KEY.
- Saving restarts the API (a few seconds) to pick up the new secret.
- Values are encrypted and never shown back.
Example: describing “send a welcome email via Resend” makes the generated code use process.env.RESEND_API_KEY and call Resend. You just add the key in settings.
Reserved names (AUTH_SECRET, DATABASE_URL, PORT, NODE_*…) are platform-owned and can't be overridden.
Scheduled jobs (cron)
An API can have recurring jobs (e.g. a daily summary, hourly cleanup). Mention it in the description and apinido adds scheduled jobs.
- The platform calls the job on schedule — it wakes the app first, then it sleeps again.
- Minimum interval is 5 minutes (no sub-5-minute crons).
- Cron runs only briefly → the €0-idle economics stay intact.
Webhooks
In the API detail you can set up webhooks — apinido sends an HTTP notification to your URL on events (e.g. a record is created). Deliveries are listed with a test option.
Database: SQLite or Postgres
When creating an API you choose the data engine:
- SQLite (Standard) — ready automatically, no setup, fits most apps.
- PostgreSQL — a dedicated DB per API; also allows external access (connection string + IP allowlist) to connect with your own tools over TLS.
The schema is additively migrated when you edit an API — adding a field keeps existing data (destructive changes are intentionally not migrated).
Pricing and billing
You pay upfront, in euros (prepaid credit). Prices are ex-VAT.
- Compute = a monthly package while the API is awake: Small €10 (1 vCPU/2 GB), Standard €16 (1 vCPU/4 GB), Performance €28 (2 vCPU/8 GB). While asleep = €0.
- AI generation: roughly €2 / 1M input + €10 / 1M output tokens (input cheaper than output).
- Requests 2.5c / 10k · Storage 8c/GB/mo · Egress 2c/GB · Postgres DB +0.3c/h while running.
- €2 welcome credit on sign-up. Minimum balance to generate: €0.50.
Failed AI generations are not charged. Your real spend is shown in Balance (total + per API).
Security and limits
Every generated app passes an automated security check before deploy and runs in an isolated container.
- Blocked: spawning processes (child_process), disk access outside /data, eval, raw sockets.
- Allowed: outbound HTTPS (fetch) — for integrations; internal/private addresses are network-blocked (SSRF protection).
- Containers: non-root, limited CPU/RAM, no network between APIs.
- Before deploy a functional smoke test runs on a throwaway copy (never on your data).
FAQ
Do I need to code? No — just describe what the API should do. apinido writes and deploys the code.
Do I need a card? Not to try — sign-up gives you €2 credit. You add a card only when you want to top up.
Where is my data? In your API's isolated database (SQLite or a dedicated Postgres), separate from everyone else.
Can I edit an API later? Yes — describe the change in chat, it deploys as a new version with rollback.
What if generation fails? We don't charge for it. Try rephrasing the description.