Skip to main content

Users guide

Krebit Sign records which human or service account is acting on behalf of a tenant. Surface this context in your applications to show who initiated signings, manage access controls, and audit important actions.

Why user context matters​

  • Personalized dashboards – Display the operator’s name, email, and organization so internal teams know which account is connected.
  • Role-aware features – Gate advanced functionality (such as cancelling signings) based on the roles returned from the API.
  • Traceability – Store user identifiers alongside activities to build an audit log that explains who triggered each workflow step.

Typical usage pattern​

  1. Request an OAuth token using the authentication guide.
  2. Call the user detail endpoint to confirm credentials and capture identity metadata.
  3. Store the user ID in your persistence layer so future events and webhooks can reference it.

Example response snippet:

{
  "data": {
    "id": "8b1c2f33-5a4d-4a3e-8e2f-93d1a5cdb081",
    "name": "Alex Integrator",
    "email": "alex@example.com",
    "organization": {
      "id": "4e5b18f9-90e8-4be9-8b01-09f1f0fdb9a5",
      "name": "YourCo"
    }
  }
}

Use this information to greet the operator, prefill forms, or automatically tag records with the acting account.

Handling authorization issues​

  • 401 Unauthorized indicates the bearer token is missing, malformed, or expired. Acquire a new token and retry.
  • 403 Forbidden means the authenticated identity cannot access the requested resource. Confirm the account has the necessary role assignments inside Krebit Sign.

Integrating with webhooks​

Webhook payloads reference the user who triggered the event when applicable. Maintain a map between stored user IDs and friendly names so downstream systems (for example, Slack notifications or CRM updates) can present meaningful context to stakeholders.

Refer to API reference → Users in the sidebar for complete schema details and additional examples.