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

By default, CORS requests are blocked. To enable them, you must explicitly configure the allowed origins for each API key that will be used from the browser.

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 checks whether the request's origin is in the list of allowed origins for the key being used. If the origin is authorized, the browser proceeds with the actual request; otherwise, the request is denied.

Configuring origins

Allowed origins are configured from the Dashboard, in the Keys section. You can set origins for both the primary key and each restricted key.

Two formats are supported:

Format Example Matches
Exact origin https://app.example.com Only https://app.example.com
Wildcard subdomains *.example.com sub.example.com, a.b.example.com, but not example.com

Best practice

Only configure the origins that are strictly necessary. Leave the list empty to completely block browser access (default setting, recommended for keys that don't need to be used from the frontend).

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. CORS origin configuration is not a sufficient security measure on its own, because it only restricts requests coming from browsers — an attacker can still use the key from a non-browser client (e.g. curl, Postman, server-side scripts).

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.

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

With this approach, you don't need to configure CORS origins, since requests originate from the server.

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:

  1. Create a dedicated restricted key 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

  2. Configure the CORS origins for that key from the Dashboard, specifying only the domains from which your application will make calls

Restricted keys and CORS origins together reduce the damage in case of compromise, but do not eliminate it: the key remains usable from non-browser clients. 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.