Happ error “Unknown content type”

This one means the request succeeded. The app opened the address, got an answer back, and could not recognise the answer as a subscription or a supported configuration. The address works — it just does not lead to what the app needs.

Test with a working subscription
Step by step

Finding out what the address really points at

Separating a dashboard address from a subscription address.

  1. Go back to where you got the link

    Look for a control labelled specifically as the subscription or import link, not the address bar of the page you are on.

  2. Copy that one with its button

    The address in your browser's bar is the dashboard, and it will produce this same error every time.

  3. Import it into the app

    A correct subscription address fills the server list within a second or two.

  4. If it still fails, ask the service

    If the dedicated subscription address returns something unusable, only the service can fix what its server sends.

What happened technically

The app made the request and received a response. Then it tried to work out what the response was — a subscription list, a single configuration, JSON, an encrypted happ://crypto payload — and none of the formats matched. Rather than guess, it stops and says so.

So the failure is about content, not connectivity. Something is at that address; it is the wrong something.

The usual culprit

Providers give you two addresses that live in the same place and look alike:

  • the dashboard — a page you open in a browser to see your account;
  • the subscription — an address meant for the app to fetch.

Copying the dashboard address out of the browser’s address bar is easy to do and produces this error every time, because what comes back is a web page.

The fix is to find the control that explicitly offers the subscription or import link and use its copy button.

The browser test, done properly

The widespread advice — open the link in a browser, and if you see a normal page you copied the wrong thing — is not reliable, and following it will send some people looking for an address that does not exist.

Subscription servers commonly serve different things to different callers: a readable page to a browser, configuration data to the app. A normal-looking page is therefore the expected result for a correct link.

What the browser actually distinguishes is narrower:

  • a login form — you have the dashboard address, this is the real signal;
  • a page from your service showing your subscription — normal, keep the link;
  • a file download or a wall of text — normal;
  • an error code — inconclusive; retry before concluding anything.

When the address is right and it still fails

Services change things. Authentication can be switched on, a subscription path can move, a server can start returning an error page. All of these produce this message with an address that was correct yesterday.

Open your provider’s dashboard, copy the current subscription address and replace the old entry in the app rather than adding a second one. If the current address still returns something the app cannot read, the fix has to happen on their side.

If the wording you are looking at is not exactly this one, compare it against the full list of messages — the eight are worded similarly and each points at a different stage.

Quick answers

Frequently asked questions

What is the single most likely cause?

The address of your provider's web dashboard was copied instead of the subscription address. They sit next to each other and look similar.

The link opens a normal page in my browser. Is that the problem?

Not by itself. Subscription servers routinely answer browsers with a page and apps with configuration data, so a normal page proves nothing either way.

Can this be the service's fault?

Yes. A server that temporarily returns an error page, a redirect or an empty body produces exactly this message with a perfectly correct address.

Quick actions Test with a working subscription

Trial access: in Telegram or in the web cabinet.