When changes don't save
An uncommon case with a thirty-second answer — something on your own computer, nearly always a browser extension, can block the requests that save
Everything in the Console reads normally — your applications, your webhooks, your numbers — but pressing Save does nothing, or answers with an error. It happens on one computer and not on another.
It is uncommon, and it is not something you have done wrong. Almost always, the request never leaves the machine.
Telling in thirty seconds
Open a private window (Ctrl+Shift+N, or ⌘+Shift+N) — it starts with no extensions and on the same network — sign in and make the same change.
If it saves there, an extension is answering for us, and turning it off for the Console is the whole fix. Nobody else needs to be involved. If it still fails, read on: something outside the browser is doing it, and that is the rarer half of this page.
The one case we have seen was the first kind, and the person settled it in under a minute. It is not your account, not your permissions and not something you did.
What is happening
The Console saves a change by sending an HTTP PATCH request, and deletes with DELETE. Those are the standard methods for updating and removing, and an API that did not use them would be the unusual one.
Something on the computer can answer for a short list of methods — typically GET, HEAD, POST and OPTIONS — and refuse the rest. Reading passes. Creating passes, because creating is a POST. Updating and deleting do not.
Two things do this, and they are not equally likely. A browser extension — an ad or privacy blocker, a security add-on — is by far the common one, and the reader can settle it alone. A security agent or a local proxy on a company-managed device is the rare one, and it is the only case that needs somebody else.
Before a request like that, your browser asks permission — a small OPTIONS call whose answer lists the methods allowed. When something on the device answers that question itself, with its own short list, the browser obeys it and never sends the real request. That is why the failed row in the Network tab has no status code: not because we refused, but because nothing was ever sent to us.
That is why the symptom is so oddly specific — you can add a webhook endpoint but not edit the one you just added.
Your browser’s developer console names it exactly. On the Console tab (not Network), saving again prints something close to this:
Read literally, that line says something was asked whether PATCH is allowed and answered no. It was not us: our API answers that question with DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT. Whatever replied is between your browser and us, and it is on the device — which is why the same account works from a phone.
Nothing is saved halfway. If the request does not leave your computer, nothing arrives here and nothing changes on your application.
Two things that often confuse this, and the first one wastes the most time: it is not the VPN — turning a VPN off leaves the extensions, the agent and the proxy exactly where they were, so a test without the VPN proves nothing — and it is not the office network, which is why the same wi-fi works from a phone.
What to do
Keep working meanwhile
Any other device will do. Nothing about your account or your application needs changing.
If the private window saved it: find the extension
Turn them off and on again one at a time with the Console open — ad and privacy blockers, security add-ons and anything that inspects traffic are the usual ones. Disabling the one that does it, for this site alone, is the whole fix.
If it still fails in the private window: something on the machine
Then the answer is coming from outside the browser — a security agent or a local proxy, which usually means a company-managed device. If yours is, the people who can change it are your IT team, and the text below is written to be forwarded as it is: the symptom, the evidence and the exact request.
Tell us how it went
Write to support@infonite.tech. We keep a record of which setups do this, so the next person spends five minutes on it instead of a week.
Text to forward to your IT team (only after the private-window check)
Subject: HTTP methods blocked towards infonite.tech from managed devices
From a company laptop, the Infonite Console cannot save changes. The behaviour is:
- Reads (
GET) work normally. - Writes using
PATCHare blocked before leaving the device: the browser reports a CORS error, and the request itself is never sent — the Network tab records no status code for it. - It happens with and without the VPN connected, and in a private browser window with no extensions.
- It does not happen from a mobile phone on the same office wi-fi.
That places the block on the device — a TLS inspection agent, or a local proxy or PAC file — rather than on the network or in the browser.
Failing, for example:
Working, against the same host and with the same headers:
The browser’s console names the mechanism:
The OPTIONS preflight is therefore being answered locally with a method allow-list that does not contain PATCH. The API’s own answer to that same preflight, verified from outside, is DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT.
Request: allow the PATCH, PUT and DELETE methods towards *.infonite.tech, or exclude that domain from traffic inspection and rewriting.
Preflight answers are cached by the browser for ten minutes. After anything changes — an extension disabled, a policy relaxed — give it that long, or reload the page with the cache disabled, before deciding it did not work.