curl for APIs: testing headers, JSON, timings, and certificates from the terminal
Published on 2026-10-26 by frfrand
Useful curl commands for investigating web and HTTP errors
When an API fails, the browser usually shows only «Network Error». curl lets you make the same request and see headers, body, certificate, and timings without depending on the frontend. It's a Swiss army knife to distinguish code errors from infrastructure errors.
The idea is to solve a data or deployment problem that appears in real applications. We'll cover the concept straight to the point, an implementation example, and what to check before taking it to production.
What curl does for APIs
curl is a protocol client that supports HTTP, HTTPS, and many debugging options. Headers show metadata, the status reflects the server's response, and verbose mode provides connection information. Important secret: don't paste real tokens in shared commands or tickets.
Simply repeating a recipe isn't enough if you don't understand who reads the data, from which process, and with what permissions. In an application with reservations, invoices, or users, a race condition or a poorly designed access policy can be more serious than a slow API.
A concrete example
curl -i https://api.ejemplo.com/health
curl -I https://api.ejemplo.com/
curl --fail-with-body -sS https://api.ejemplo.com/health
curl -sS -o /dev/null -w 'status=%{http_code} total=%{time_total}\n' https://api.ejemplo.com/health
# POST de prueba sin credenciales
curl -i -X POST -H 'Content-Type: application/json' -d '{"plazas":2}' https://api.ejemplo.com/demoThe names, tables, and keys in this example are illustrative. Try it first in a test or staging environment and adapt permissions, indexes, and versions. When there are write operations, do not run sample queries on customer data without reviewing what they modify.
Step by step
- Check GET on a health route and note the HTTP status.
- Use
-ito view response headers;-Irequests HEAD, which is not always supported. - Measure times to distinguish connection latency from processing latency.
- Test a POST only against a test endpoint that does not create charges or orders.
- If TLS fails, investigate the certificate and name instead of disabling validation with
-k.
In the end, do not settle for "the SQL did not return an error." Verify the actual effect from the API and with concurrency or permission tests as appropriate. In databases, there are errors that only appear when two users do something at the same time.
Example work project
A store sends JSON data but the API expects a different field name. With curl you get 422 or 400 and a body explaining the validation, without getting lost investigating the proxy.
That scenario helps distinguish performance from consistency. Speeding up a query is useless if it allows creating two reservations for a single seat, nor does a huge database fix the backend allowing querying another client's data.
The typical error
curl -I sends HEAD and may return a different error than GET; to verify an API that only offers GET, use GET. Do not publish commands with real bearer tokens.
It is also advisable to have a recovery plan. Before touching schema, users, or policies, save a verifiable copy or reversible migration and verify that the application can continue functioning during the change.
How would you solve it with ArduMaker?
If your backend is on ArduMaker, compare the curl response with the FastAPI, Django, and Nginx logs from the VPS. It's a more accurate diagnosis than restarting servers.
ArduMaker allows you to deploy services from Git and work with databases and processes within the VPS. The panel does not replace your application logic: transactions, permissions, and validations must be correctly designed in the code and the database.
Three checks before publishing
Integrity: if a request is repeated or fails halfway through, do the data end up in a valid state?
Security: can an authenticated user access only their own information, and does the API use a base identity with minimal permissions?
Recovery: do you know how to restore the data and revert the compatible code version if an update goes wrong?
If you can answer those three questions with tests, your backend is much better prepared than when you only checked if the endpoint returned 200.
Resources to learn more
To wrap up: choose the simplest solution that allows you to maintain correct, secure, and recoverable data. Performance comes after measuring.