Krebit Finance Documentation

website·Indexed 32 days ago

https://docs.krebit.se

SaaS platform for managing client financial data, screening workflows, and credit insights. Documentation includes the API 1.0 reference for managing clients, acts, templates, and webhooks, as well as OAuth 2.0 authentication guides.

Tokens: 10.7K
Snippets: 46
Records: 81
Agent score: 56%

What's inside Krebit Finance

Implement user context for auditing and personalization in Krebit Finance
Krebit Finance tracks which human or service account acts on behalf of a tenant. Integrating this user context allows developers to build personalized dashboards (displaying operator name/email), implement role-aware feature gating, and maintain traceability by storing user identifiers in audit logs to track who triggered specific workflow steps.
https://docs.krebit.se/docs/users/
Understand the Krebit template hierarchical structure
Templates define the structure of financial acts and are used to render data-entry forms, validate inputs, or map act data points. A template consists of the following hierarchy:
- Template metadata: Includes id, name, country, language, and auditing timestamps.
- Tabs: Ordered groupings of sections that correspond to the Krebit Finance UI layout.
- Sections: Ordered clusters of fields located within each tab.
- Fields: Individual data points containing id, name, type, required, options, and order.
https://docs.krebit.se/docs/templates/
Understand Krebit Finance platform architecture
Krebit Finance is a SaaS platform for managing client financial data, screening workflows, and credit insights. The platform uses a multi-tenant architecture where each organization is isolated on its own subdomain. This subdomain serves as the base URL for all API requests.
```
https://{organization}.krebit.se
```
https://docs.krebit.se/docs/
Understand the structure of a Krebit Act
Acts represent financial evaluations tied to a client. They record the template used, the requested amount/currency, and structured data points captured during assessment. Every act contains the following core metadata:
- uuid: Unique identifier for the act.
- client_id: Link to the originating client.
- template_id and template_name: The template defining the act's structure.
- amount and currency: The requested or approved financial values.
- language: The language used by the template.
- created_at and updated_at: Timestamps for auditing and synchronization.
https://docs.krebit.se/docs/acts/
Understand the Client data model
Clients represent organizations being evaluated and monitored. A client record aggregates the following data categories:
- Identity: company_name, org_number, country, and core identifiers.
- Credit context: Credit limits, currency fields, and rating values.
- Contact details: Primary contact name, email, and phone number.
- Operational metadata: created_at and updated_at timestamps for auditing and synchronization.
https://docs.krebit.se/docs/clients/
Capture and store user identity metadata
To identify the acting user in Krebit Finance, follow this typical usage pattern: first, obtain an OAuth token; second, call the current user endpoint to retrieve identity metadata; third, store the user ID in your persistence layer to reference it in future events and webhooks.
```
{
  "name": "Alex Integrator",
  "email": "alex@example.com"
}
```
https://docs.krebit.se/docs/users/
Retrieve the latest financial act for a client
Client records link directly to the latest 'act', providing the fastest way to retrieve current financial context. For full act history or specific field-level data points, refer to the Acts guide and the API reference.
https://docs.krebit.se/docs/clients/

Generate Client Directory Sync using AI prompts

Use these prompts to guide an LLM in building a sync job that ingests client records from the Krebit Finance API. Replace the 'Project context' with your specific language, HTTP libraries, and storage system.

Implementation Prompt

You are building a sync job that ingests client records from the Krebit Finance API.

Project context:
- (Replace this bullet with the language, HTTP client libraries, job scheduler, and storage system you are using.)

Tasks to implement:
1. Authenticate with Krebit Finance using the OAuth flow supported by your service and store the resulting bearer token in a reusable client.
2. Fetch clients using `GET /clients` with `limit` and `page`, iterating until all pages are processed.
3. Normalize the response into your internal schema (for example, `id`, `company_name`, `org_number`, `country`, `credit_limit`).
4. Upsert client records to your database with clear logging for created vs. updated rows.
5. Handle transient errors with retries and include backoff logic on 429 responses.

Return modular code that aligns with the project context, showing how to compose these steps into a reliable workflow.

Hardening Prompt

Take the client sync implementation you produced and enhance it by:

- Extracting reusable pagination helpers.
- Adding retry logic with exponential backoff for transient 5xx or 429 responses, while keeping validation failures immediately visible.
- Writing automated tests using the project's testing framework that mock HTTP interactions and pagination.
- Documenting (in comments or README-style notes) how to persist last-sync checkpoints for incremental updates.

Return the refactored code together with the corresponding tests or fixtures.

Map financial act data to template fields
Act data points provide specific identifiers that allow you to relate values back to the template structure. Use the following properties found in act data to reconcile values:
- template_field_id: Matches the act value to a specific template field.
- tab_id and section_id: Used to render forms that mirror the original tab and section order.
- type and options: Used to validate or transform values based on the field's definition.
Recommendation: When persisting act data in an external database, store the template ID with each record to handle future template evolutions.
https://docs.krebit.se/docs/templates/
Ensure webhook reliability and security
Follow these best practices to maintain a stable webhook integration:
- Asynchronous Processing: Respond with a 200 status immediately upon enqueuing the work to avoid timeouts.
- Idempotency: Store the id field from each payload to detect and ignore duplicate deliveries during retries.
- Security: Use HTTPS, restrict IP ranges if possible, and rotate webhook secrets regularly.
- Testing: Use tunneling tools with test data to validate handlers before production.
https://docs.krebit.se/docs/webhooks/
Implement best practices for working with templates
Follow these guidelines when integrating templates into your application:
- Caching: Since templates change infrequently, cache the responses and refresh them on a schedule to reduce API overhead.
- Validation: Use template metadata (such as required flags and type definitions) to enforce data integrity before updating act data.
- Localization: Use the language and country fields provided in the template metadata to ensure forms and labels are rendered correctly for the target region.
https://docs.krebit.se/docs/templates/
Implement pagination for list endpoints
List endpoints support page-based pagination using query parameters. The response contains a meta object to help drive pagination controls or batch jobs.
```
GET /api/1.0/clients?page=1&limit=20
```
Response Meta Object Fields:
- current_page: The current page number.
- per_page: Number of items per page.
- total: Total number of available records.
https://docs.krebit.se/docs/clients/api-reference/