CorebanqCorebanq Developer Docs
Usersv1Registration

Upload User Avatar

POST
/v1/users/avatar

Authorization

bearerAuth
AuthorizationBearer <token>

In: header

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

application/json

curl -X POST "https://example.com/v1/users/avatar"
{
  "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",
  "owner_id": "8826ee2e-7933-4665-aef2-2393f84a0d05",
  "avatar_type": "string",
  "upload_id": "f2ef591b-135b-46fa-a604-3d4fda5bfbfb",
  "content": "string",
  "metadata": {},
  "active": true
}
{
  "status": 400,
  "message": "Invalid user input",
  "code": "users_m.invalid_user_input",
  "class": "validation"
}
{
  "status": 401,
  "message": "Unauthorized",
  "code": "common.unauthorized",
  "class": "business"
}
{
  "status": 403,
  "message": "No access to the record",
  "code": "common.rbac_no_rec_access",
  "class": "business"
}

{
  "status": 429,
  "message": "Rate limit for 203.0.113.10 to 456e1234-e89b-12d3-a456-426614174111 exceeded.",
  "code": "rate_limits_m.exceeded",
  "class": "temporary",
  "retryable": true
}

{
  "status": 500,
  "message": "Internal server error",
  "code": "common.server_error",
  "class": "business"
}

{
  "overall_status": "unhealthy",
  "message": "Service is shutting down",
  "timestamp": "2026-08-27T15:04:05Z"
}

POSTActivate internal user account

AUTHENTICATED BY X-API-Key, not by a bearer token. auth.APIKeyMiddleware REPLACES the usual chain on this route, so there is no user context, no RBAC check and no licence check — and the refusals are common.api_key_required / common.invalid_api_key rather than common.unauthorized / common.rbac_no_rec_access. An OPTIONS request skips the key check entirely. Activate invited internal user account and set password (public endpoint, API key only). Same transactional semantics and compliance fields as /v1/users/activate. Returns 422 with users_m.email_credential_not_found when the expected email credential row is missing after token validation.

POSTInitiate registration

AUTHENTICATED BY X-API-Key, not by a bearer token. auth.APIKeyMiddleware REPLACES the usual chain on this route, so there is no user context, no RBAC check and no licence check — and the refusals are common.api_key_required / common.invalid_api_key rather than common.unauthorized / common.rbac_no_rec_access. An OPTIONS request skips the key check entirely. Begin registration. The answer is deliberately uniform: the same `200` and the same message whether the credential is free, belongs to a registration nobody finished, or is already confirmed on another account. No code is sent for a credential somebody else holds, and no account is created for it; its owner is notified that an attempt was made. Send pacing applies either way, so a burst answers `429 otp_m.resend_too_soon` or `otp_m.resend_limit_exceeded` on any of those paths. `400` covers the request itself — a malformed or undeliverable credential, a password that fails policy, terms or privacy not accepted.