Krebit Sign Documentation

website·Indexed 32 days ago

https://docs.krebitsign.se

API documentation for Krebit Sign, featuring tools for creating signing drafts, managing documents and recipients, and automating workflows via webhooks. Includes guides on OAuth 2.0 authentication and the /api/1.0 endpoint reference for sending and tracking digital signatures.

Tokens
11.3K
Snippets
53
Records
82
Agent score
57%

What's inside Krebit Sign

  1. Overview of Krebit Sign OAuth 2.0 Authentication

    Krebit Sign secures all REST endpoints under the /api/1.0 prefix using OAuth 2.0 bearer tokens. Requests without a valid token return a 401 Unauthorized response. Tokens are issued from the tenant-specific domain: https://{organization}.krebit.se.
  2. Overview of Krebit Sign platform

    Krebit Sign is a SaaS digital signing platform used to automate document reviews, approvals, and legally binding signatures. It manages the full draft-to-completion lifecycle, allowing users to assemble signing packages, manage recipients with ordering and identification rules, and download sealed copies upon completion.
  3. Understand the Krebit Sign signing structure

    A signing in Krebit Sign is a coordinated package that groups one or more documents with the people required to review or approve them. Each signing package consists of:

    • Identity: A human-friendly name, language preference (English or Swedish), and an optional purpose message.
    • Routing Rules: Determines the order of invitations using either parallel or sequential signing orders, with optional approver-only steps.
    • Audit State: Timestamps for Draft, In-progress, Completed, and Cancelled states.
    • Relationships: Links between recipients and documents, defining the participation order and document access permissions.
  4. Handle documents in signing packages

    Documents are the core of a signing package and are subject to the following rules:

    • Upload Constraints: Only PDF files under 10 MB are accepted. Files must not be password protected or previously signed.
    • Upload Method: Use multipart form data with the selected_file field.
    • Version Safety: Documents can be added, reordered, or removed during the Draft phase. Once the signing is Sent, documents are locked to preserve the audit trail.
    • Downloads: Original documents are always available. Sealed PDFs are only available after every required decision is captured; otherwise, requests for signed versions return a 404 error.
  5. Map user context in webhooks

    Webhook payloads include references to the user who triggered the event. To provide meaningful context in downstream systems (such as Slack or CRM notifications), maintain a mapping between the stored user IDs and their friendly names.
  6. Implement pagination for list endpoints

    List endpoints support page-based pagination using page and limit query parameters. The API returns a meta object containing current_page, per_page, and total fields to facilitate UI controls or batch processing.
  7. Implement the OAuth 2.0 Authorization Code flow

    Use the Authorization Code flow for user-facing applications where an operator grants consent. This flow provides both access and refresh tokens.

    1. Authorization Request: Redirect the user to the authorization endpoint. Use a cryptographically strong state value to prevent CSRF attacks.
    2. Token Exchange: After the user consents and is redirected back to your URI, exchange the authorization code for tokens via a POST request to the token endpoint.
    # 1. Authorization URL
    # https://{organization}.krebit.se/oauth/authorize?client_id={client_id}&redirect_uri={redirect_uri}&response_type=code&state={state}
    
    # 2. Exchange code for tokens
    curl --request POST \
      --url https://{organization}.krebit.se/api/oauth/token \
      --header 'Content-Type: application/json' \
      --data '{
        "grant_type": "authorization_code",
        "client_id": "YOUR_CLIENT_ID",
        "client_secret": "YOUR_CLIENT_SECRET",
        "redirect_uri": "https://yourapp.example.com/oauth/callback",
        "code": "AUTH_CODE_FROM_CALLBACK"
      }'
  8. Retrieve and store current user identity metadata

    To capture the identity of the acting user, follow this typical usage pattern:

    1. Request an OAuth token.
    2. Call the current user endpoint to confirm credentials and capture identity metadata.
    3. Store the returned user ID in your persistence layer to reference it in future events and webhooks.
    {
      "data": {
        "id": "8b1c2f33-5a4d-4a3e-8e2f-93d1a5cdb081",
        "name": "Alex Integrator",
        "email": "alex@example.com",
        "organization": {
          "id": "4e5b18f9-90e8-4be9-8b01-09f1f0fdb9a5",
          "name": "YourCo"
        }
      }
    }
  9. Prerequisites for Krebit Sign integration

    To integrate with Krebit Sign, you need the following:

    • An active Krebit Sign tenant.
    • An OAuth application with client_id, client_secret, and a redirect URI.
    • A PDF file (document.pdf) under 10 MB that is not password-protected and contains no existing signatures.
    • A recipient to receive signing notifications.
  10. Implement the Krebit Sign webhook workflow

    Webhooks provide near real-time updates for signing events, eliminating the need to poll the API. The standard implementation workflow is:

    1. Register a webhook: Define the target URL and the specific event types to monitor.
    2. Store the shared secret: Securely save the signing secret provided in the creation response; this is required for payload verification.
    3. Handle events: Create an HTTPS endpoint that accepts POST requests, validates the signature header, and queues the work.
    4. Monitor delivery: Ensure the endpoint responds quickly with 2xx status codes. Krebit Sign retries transient failures but may disable webhooks that repeatedly error.
  11. Implement user context for auditing and personalization in Krebit Sign

    Krebit Sign tracks whether a human or service account is acting on behalf of a tenant. This context should be used in applications to:

    • Create personalized dashboards (displaying operator name, email, and organization).
    • Implement role-aware feature gating (e.g., restricting the ability to cancel signings).
    • Ensure traceability by storing user identifiers in audit logs to track who triggered specific workflow steps.
  12. PDF upload requirements for Krebit Sign

    Documents uploaded to Krebit Sign must meet the following constraints:

    • Format: PDF
    • Maximum size: 10 MB
    • Restrictions: Must not have passwords, annotations, or existing signatures.