The provisioning credentials of this organization
OWNER, and NOT VIEWER as the company credential listing is. That one is VIEWER because GET /console/v1/companies/{companyId}/activity already publishes every company credential's public prefix to every VIEWER, so hiding the list would be a rule with no content; nothing publishes an organization credential's prefix, because it issues nothing and so reaches no activity row. What is left is that this listing is the input to the revocation decision -- you revoke the row you are looking at -- and a list readable by somebody who cannot act on it splits an emergency across two people. It carries no secret: only a SHA-256 is stored. Revoked and expired credentials stay in it.
OWNER, and NOT VIEWER as the company credential listing is. That one is VIEWER because GET /console/v1/companies/{companyId}/activity already publishes every company credential's public prefix to every VIEWER, so hiding the list would be a rule with no content; nothing publishes an organization credential's prefix, because it issues nothing and so reaches no activity row. What is left is that this listing is the input to the revocation decision -- you revoke the row you are looking at -- and a list readable by somebody who cannot act on it splits an emergency across two people. It carries no secret: only a SHA-256 is stored. Revoked and expired credentials stay in it.
Authorization
consoleSession Set by POST /console/v1/sessions. HttpOnly, Secure, SameSite=Strict, Path=/, __Host- prefixed. It is never readable by JavaScript and there is no header alternative: accepting both carriers would let an attacker choose the weaker one.
In: cookie
Path Parameters
uuidResponse Body
application/json
application/json
application/json
application/json
application/json
application/json
application/json
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/console/v1/organizations/497f6eca-6276-4993-bfeb-53cbbbba6f08/credentials" \ -H "Authorization: Bearer apf_v2_tu_credencial"{ "schemaVersion": "console.1", "requestId": "d385ab22-0f51-4b97-9ecd-b8ff3fd4fcb6", "organizationId": "7bc05553-4b68-44e8-b7bc-37be63c6d9e9", "credentials": [ { "credentialId": "f568fec0-10b6-4b94-9daf-e62c50c9bf3e", "name": "string", "tokenPrefix": "string", "scopes": [ "string" ], "status": "ACTIVE", "expiresAt": "2019-08-24T14:15:22Z", "revokedAt": "2019-08-24T14:15:22Z", "lastUsedAt": "2019-08-24T14:15:22Z", "createdAt": "2019-08-24T14:15:22Z" } ]}Register a company under this organization POST POST
ADMIN and above, which is ADR 0016 point 7's assignment of companies rather than this route's opinion. Nothing here proves the caller controls the RUC and nothing needs to: the claim confers nothing until a certificate this platform signed with has been accepted by SUNAT, which is proof of control checked by the party that can perform it. What the alta does guarantee is attribution -- it writes an ops.audit_events row naming the person, in the same transaction as the company -- so a squatted RUC is an operator action with evidence rather than an argument between two customers. Every refusal about WHO the caller is answers 409 MEMBERSHIP_CHANGE_REFUSED indistinguishably; only a RUC already registered answers something specific, and it says nothing about whose it is.
Mint an organization credential POST POST
OWNER, and an enrolled second factor. This is the credential a SaaS puts in a server to register its own client companies by API. THE FLOOR IS NOT ADMIN, and not by symmetry with anything: every other act an ADMIN performs lands inside their own organization, whereas companies:manage can register a company under ANY RUC in Peru, and core.companies.ruc is unique platform-wide, so claiming one DENIES it to whoever controls it -- a third party with no account here. SUNAT publishes no ownership oracle, so migration 000053's answer is attribution rather than prevention: every act writes an ops.audit_events row in the same transaction. A control whose whole mechanism is 'we can say who did it' belongs to the rank that can be held answerable. THE SECOND FACTOR IS CHECKED IN SQL, on auth.users.mfa_enrolled_at, because the failure this act invites is a stolen session -- which is by construction a caller of the correct rank, and would make the audit row name somebody who did nothing. Enrolment is self-service, so this strands nobody. THE TOKEN IS IN THE 201 AND NOWHERE ELSE.