All requests to Removit API require API key authentication. This section explains the supported headers and the safest backend integration pattern for a production image processing API.
Authentication should live in your backend or proxy layer so the public client never exposes secrets while calling the asynchronous API.
This example uses the recommended X-API-Key header for a server-side JSON upload request.
curl -X POST "https://api.removit.eu/api/v1/upload" \
-H "Content-Type: application/json" \
-H "X-API-Key: <YOUR_API_KEY>" \
-d '{
"file_url": "https://example.com/image.jpg",
"mode": "background"
}'If the API key is missing or invalid, the API returns a 401 Unauthorized response and the request must be retried with valid credentials.
Handle 401 responses explicitly in your backend so your clients receive a controlled integration error instead of a silent failure.
{
"error": "unauthorized",
"message": "API key missing"
}The API accepts two header formats. The recommended one for server-to-server integrations is X-API-Key.
Use X-API-Key: <YOUR_API_KEY> for the clearest server-side integration pattern.
Authorization: Bearer <YOUR_API_KEY> is also accepted when you prefer a bearer-style scheme.
Keep the API key in environment variables and forward the request through your own backend.
These are the practical header forms accepted by Removit API and commonly used in examples.
X-API-Key: <YOUR_API_KEY>More explicit for backend integrations and internal proxies.
Authorization: Bearer <YOUR_API_KEY>Accepted if your platform standardizes on bearer tokens.
Content-Type: application/jsonRequired when you send a file_url payload in JSON.
Authentication is not optional on the core workflow endpoints.
POST /api/v1/uploadRequired for remote URL uploads and multipart uploads.
GET /api/v1/statusRequired for every job status polling request.
These backend integration rules reduce accidental key leakage and make troubleshooting safer in production.
In a frontend + backend architecture, the backend should own the Removit API request lifecycle.
The frontend submits either a file or a remote URL to your own backend.
The backend injects the API key, creates the upload job, and stores the job_id.
Your backend polls /status or relays the job state to the frontend without exposing secrets.