Skip to content

CORS (Cross-Origin Resource Sharing)

The Invoicetronic API supports CORS, the standard browser mechanism that allows web pages to make HTTP requests to domains other than their own origin. This means you can call the API directly from JavaScript running in the browser, for example from a single-page application (SPA), a web portal, or any other frontend application.

How it works

When a browser makes a cross-origin request to the API, it first sends a preflight request (OPTIONS method) to verify that the server allows the call. The API responds with the appropriate CORS headers and the browser proceeds with the actual request.

This process is completely transparent: you don't need to do anything special in your code. The browser handles the preflight automatically and the API authorizes it.

API key exposure

Important

When you call the API from JavaScript in the browser, your API key is inevitably exposed. Anyone can see it by inspecting the page source code or network requests through the browser's DevTools. There is no way to hide an API key in a frontend application.

This is a real risk: an exposed key can be copied and used outside your application to access your account data or perform unauthorized operations.

Best practice

Whenever possible, call the API from your backend, not from the browser. This is by far the most secure approach: the key stays on the server and is never exposed to the client.

Any API key exposed in the browser — even a read-only restricted key — remains an attack vector until you notice it has been exfiltrated and revoke it. In the meantime, an attacker can access the data allowed by that key. A backend eliminates this risk entirely.

The recommended architecture is a two-tier setup:

  1. Frontend (browser) — communicates with your backend, not directly with the Invoicetronic API
  2. Backend (server) — calls the API with the primary key, safely hidden from the client

If you cannot use a backend

If your application doesn't have a backend (e.g. a static SPA or a generated site), you can call the API directly from the browser. In this case, it is essential to use a dedicated restricted key, configured with the minimum permissions required:

  • Read only if the application only needs to query data (invoices, logs, status)
  • Send if it also needs to send invoices
  • Company restrictions to limit access to relevant documents only

Restricted keys reduce the damage in case of compromise, but do not eliminate it: as long as the key is active, anyone who has it can access the permitted data. Monitor your key usage and revoke keys promptly if you suspect a compromise.

Never use the primary key in the browser

The primary key has full access to all resources on your account. Exposing it in a frontend application is a serious risk. Always create a dedicated restricted key and reserve the primary key for the backend.