One header is required. Everything else is negotiation — format in, format out.
The required header
x-api-key: your_api_key_hereThat is the whole auth story. No token exchange, no signature, no per-endpoint scope. See authentication for where to get a key and how to rotate one.
Header names are case-insensitive, so x-api-key, X-API-Key and X-Api-Key are the same
header. Prefer lowercase: HTTP/2 requires it, and every example here uses it.
Send no x-api-key at all and the request is stopped at the edge before it reaches the API —
you get a 403 with an HTML body, not a JSON error. Send a wrong key and you get the real
401 with a JSON body. If you are debugging a 403 that returns HTML, the header is missing
or misspelled, not invalid.
Choosing a response format
Accept picks the encoding. JSON is the default and is what every example in these docs assumes.
Accept | You get |
|---|---|
application/json | JSON (default) |
application/xml | XML |
application/yaml | YAML |
curl https://api.apiverve.com/v1/currencyconverter \
-G --data-urlencode "from=USD" --data-urlencode "to=EUR" --data-urlencode "amount=100" \
-H "x-api-key: $APIVERVE_KEY" \
-H "Accept: application/xml"The envelope is identical in all three — only the encoding changes. See response format.
Sending a body
Content-Type describes what you are sending, and only matters on POST.
Content-Type | Use it for |
|---|---|
application/json | Ordinary POST endpoints |
multipart/form-data | File uploads |
application/x-www-form-urlencoded | Form-encoded bodies |
curl -X POST https://api.apiverve.com/v1/emailvalidator \
-H "x-api-key: $APIVERVE_KEY" \
-H "Content-Type: application/json" \
-d '{"email": "hi@example.com"}'A file upload sends the file as a part rather than a JSON value:
curl -X POST https://api.apiverve.com/v1/imageconverter \
-H "x-api-key: $APIVERVE_KEY" \
-F "file=@photo.png" \
-F "format=jpg"Let curl set the multipart/form-data boundary itself — setting the header by hand without a
boundary is the most common reason a working upload starts returning 400.
Headers you get back
Every response carries your current credit position, so you can track spend without a second call to the dashboard.
| Header | What it reports |
|---|---|
x-api-remaining-credits | Credits left in the current cycle |
x-api-credits-used | Credits spent so far this cycle |
x-api-max-credits | The cycle's ceiling for your plan |
x-api-current-plan | Plan the key resolves to |
x-api-renewal | When the cycle resets |
x-api-trialing | Whether the account is inside a trial |
x-api-version | Version of the endpoint that served the response |
x-rate-limit-limit | Requests per minute in force for this key |
x-rate-limit-remaining | Requests left in the current minute |
cf-ray | Edge request identifier — quote it in support requests |
x-cloud-trace-context | Origin request identifier, once the call reached the API |
The edge exposes x-api-remaining-credits, x-api-credits-used, x-api-max-credits and
x-api-version to cross-origin JavaScript. Everything else in the table is on the wire but
invisible to fetch — including both request identifiers and all three rate-limit headers.
From a server they all read normally. See CORS.
Headers the API accepts
The full accept list, as advertised on preflight:
Accept, Accept-Encoding, Content-Type, Content-Length, Origin, Referrer,
Priority, User-Agent, Authorization, X-Requested-With,
X-HTTP-Method-Override, x-api-key, x-jwt, x-av-clientAnything outside that list is dropped rather than rejected, which matters in the browser: a custom header you added for tracing will make the preflight fail and the call will never leave the page.
Next
Formats are covered in response format; calling from a browser has its own rules in CORS; status codes and what to retry are in errors.
The credit and rate-limit headers above are explained in rate limits, and making requests covers the client-side shape — timeouts, retries and caching — that reads them.