Well-known documents

OpenID Provider metadata: the authorization, token, userinfo and end-session endpoints, supported scopes, and the JWKS location.

OAuth 2.0 Authorization Server metadata. The same issuer described in OAuth’s own vocabulary, for clients that look here rather than at the OpenID document.

The public keys that verify tokens this issuer signed. Rotating keys appear here before they are used, so a verifier that refetches keeps working across a rotation.

The public product directory: apps an organisation can discover and request. Display fields only — never platform apps, grant-only products, client fields or metrics.

The accounts capabilities manifest: every served RPC action with its input and output schema, the sign-in and sign-up pages, the events it publishes, and the app, feature and permission-code catalogue shapes. No user, session, credential, token or client table is catalogued. The same document answers on system.accounts.wellknown.capabilities.v1.

Public facts about the organisation that owns a custom domain. Rate limited, and it answers for public organisations only.

?domain=required

The custom domain to look up. Without it the endpoint answers 400; for a domain no public organisation owns, 404.

The orgs capabilities manifest: every served RPC action with its input and output schema, the public join-link page, the events it publishes, and the organisation, branch, node, group, team and role shapes with owner, creator, metadata and external-reference fields excluded. Membership rows are not catalogued. The same document answers on system.orgs.wellknown.capabilities.v1.

The storage capabilities manifest: every served RPC action with its input and output schema, the public share-link route, and the file and folder shapes it exposes with object keys and uploader ids excluded. The same document answers on system.storage.wellknown.capabilities.v1.

The people capabilities manifest: every served RPC action with its input and output schema, the events it publishes, and the person, tag and list shapes. Names, birthdays, contact points, addresses, notes, attachments and guardian invites are never catalogued. The same document answers on system.people.wellknown.capabilities.v1.

The forms capabilities manifest: every served RPC action with its input and output schema, the public routes, and the row shapes it exposes with sensitive columns excluded. The same document answers on system.forms.wellknown.capabilities.v1.

The calendar capabilities manifest: every served RPC action with its input and output schema, the public calendar and feed routes, and the calendar, event and working-week shapes it exposes with share tokens and owner ids excluded. The same document answers on system.calendar.wellknown.capabilities.v1.

The notifier capabilities manifest: every served RPC action with its input and output schema, the public routes and inbound webhooks, the events it publishes, and the campaign, message and workflow shapes it exposes with tenant, recipient and provider columns excluded. The same document answers on system.notifier.wellknown.capabilities.v1.

The machine-readable index of the well-known documents this estate advertises, grouped by the app that serves it. Start here to find the rest. A product the registry hides, such as a superadmin-only app, still serves its documents at its own address but is not listed.

Where to report a vulnerability in any cmykcloud app, and the contact that answers.

The audit capabilities manifest: every served RPC action with its input and output schema and the audit-event shape it exposes with actor, network and chain columns excluded. The same document answers on system.audit.wellknown.capabilities.v1.

The adms capabilities manifest: every served RPC action with its input and output schema, the device protocols it accepts, the events it publishes, and the device and punch shapes it exposes with credentials, addresses and raw device lines excluded. The same document answers on system.adms.wellknown.capabilities.v1.

The attendance capabilities manifest: its own RPC action with its input and output schema (the reserved marks contract has no caller and is not advertised), the day-judged event, and the policy, group, leave-type and day-result shapes with policy bodies, raw evidence, reasons and acting user ids excluded. The same document answers on system.attendance.wellknown.capabilities.v1.

The school capabilities manifest: every served RPC action with its input and output schema, the events it publishes, and the academic-year, class, group, subject, classroom, section, subject-offering, period and exam shapes. Student, staff, guardian, marks and fee records are never catalogued. The same document answers on system.school.wellknown.capabilities.v1.

The teacher capabilities manifest: its own RPC action with its input and output schema. The portal owns no table and publishes no event — what a teacher sees is school’s answer, asked afresh on every request. The same document answers on system.teacher.wellknown.capabilities.v1.

The student capabilities manifest: its own RPC action with its input and output schema. The portal owns no table and publishes no event — what a student sees is school’s answer, asked afresh on every request. The same document answers on system.student.wellknown.capabilities.v1.

The guardian capabilities manifest: its own RPC action with its input and output schema, and the public invite route a school hands a guardian. The portal owns no table and publishes no event. The same document answers on system.guardian.wellknown.capabilities.v1.

The billing capabilities manifest: its own RPC action with its input and output schema (the reserved wallet contracts have no caller and are not advertised), the product and meter model shapes, and its events, billing.invoice.finalized among them. No price, contract, wallet, hold, invoice, payment or ledger table is catalogued as a model. The same document answers on system.billing.wellknown.capabilities.v1.

The rules capabilities manifest: every served RPC action with its input and output schema, and the decision and decision-version shapes it exposes with the owning organisation, the authoring user and the decision content excluded. The same document answers on system.rules.wellknown.capabilities.v1.

The mail capabilities manifest: every served RPC action with its input and output schema, the public routes, and the row shapes it exposes with sensitive columns excluded. The same document answers on system.mail.wellknown.capabilities.v1.

The support capabilities manifest: every served RPC action with its input and output schema, the public routes, and the row shapes it exposes with sensitive columns excluded. The same document answers on system.support.wellknown.capabilities.v1.

The my capabilities manifest: its own RPC action with its input and output schema. The portal owns no table yet and publishes no event — what you see is accounts, people and school answers, asked afresh on every request. The same document answers on system.my.wellknown.capabilities.v1.

The website-builder capabilities manifest: its own RPC action with its input and output schema. The builder owns no table and publishes no event — what it renders is managed per site, asked afresh on every request. The same document answers on system.website-builder.wellknown.capabilities.v1.