Skip to Content
MuoCeon Docs

FAQ overview

The four categories of the FAQ, how to search by symptom and error code, and how it differs from the error code page.

The FAQ collects questions that have already been asked: confusion from end users facing a consent page, and blockers developers hit during integration. It is not systematic by design — it aims at "follow this and it is fixed".

This page explains how to use the section and how it relates to the error code page.

Four categories

ReaderWhat they care aboutCategory
End usersPasswords, verification methods, sessions, someone else using my accountAccount and security
End usersWhy sign in again, why verify once moreSign-in and verification
End users and developersWhat the consent page asks, what revoking does, scopes and audiencesAuthorization and permissions
DevelopersWhy this error, why a scope is missing, whether a secret can live in the frontendIntegration and debugging

User-side answers assume no terminology at all; developer-side answers assume you know what a client_id is. Start from the FAQ overview if you are unsure which category fits.

Try in this order, each step narrower than the last:

  1. By symptom: the thing you see (no consent page, a 404 on the callback, a 401 on a token) maps directly to an entry;
  2. By error code: Error codes gives the troubleshooting order; the FAQ gives the conclusion;
  3. By field: API reference gives parameters and constraints.

How it differs from the error code page

PageQuestion it answers
Error codesWhat is the basis for this error code, and in what order do I investigate
FAQIn this scenario, what is it usually, and how do I fix it

The error code page is complete and organised by protocol; the FAQ is empirical and organised by scenario. When they disagree, the error code page wins.

Categories at a glance

Each category has its own overview page listing the questions it answers and stating what deliberately does not belong there:

When nothing matches

Report it as "the docs are wrong" rather than working around it: a workaround leaves a long-term hazard, a wrong doc gets fixed. Change notes and feedback conventions are in the documentation outline.

On this page