Skip to main content

Acts guide

Acts represent financial evaluations tied to a client. Each act records the template used, the requested amount and currency, and a set of structured data points captured during the assessment. Use acts to track the latest evaluation status, display input values, or sync completed assessments into your own systems.

What an act includes​

Every act includes core metadata:

  • Identity - A uuid that uniquely identifies the act across the platform.
  • Client linkage - client_id connects the act back to the originating client.
  • Template context - template_id and template_name tell you which template defines the act structure.
  • Case type - case_type contains the classification saved for the act, or null for an unclassified act.
  • Financial values - amount and currency capture the requested or approved amount.
  • Locale - language indicates which language the template uses.
  • Timestamps - created_at and updated_at help with auditing and synchronization.

List, detail, and latest act workflows​

Use list workflows to page through recent acts, detail workflows to fetch a single act by UUID, and latest-act workflows to surface the most recent evaluation when you only need current context. If you want the full act history for a client, list acts and filter by client_id in your application or query results. For the exact parameters and responses, use the Acts section in the generated API reference.

Filter by case type​

Use case_type[] on GET /api/1.0/acts to filter by case-type UUID. Multiple values match with OR; none includes unclassified acts. Inactive case types remain valid filters for historical acts.

curl --fail-with-body --silent --show-error --get \
  "${KREBIT_API}/acts" \
  --header "Authorization: Bearer ${ACCESS_TOKEN}" \
  --header 'Accept: application/json' \
  --data-urlencode 'case_type[]=b761cba6-56f0-4a74-8979-cd4591c5acbf' \
  --data-urlencode 'case_type[]=none' \
  --data-urlencode 'limit=20'

Replace the example UUID with one from your act responses. Use KREBIT_API and ACCESS_TOKEN from the quickstart. Pagination links preserve the filters and limit.

In list, detail, and webhook act objects, case_type includes uuid, name, translations, and color. Match on uuid; the name and translated labels are saved when the act is created and do not change when the catalog is renamed. The display color reflects the current catalog; queued webhooks retain the color recorded in their payload. A null color uses a neutral style.

Duplicated acts​

When an act is duplicated in Krebit Finance, the new act starts as a draft with copied data and attachments. Duplication does not fetch fresh data or emit act.created. Subscribe to act.duplicated to receive the new act in data.act and the original act's UUID in data.source_act_uuid.

Use the new act's own case_type and data-point IDs when processing it. See the webhook event catalog.

Working with act data points​

Act data points represent the values entered for each template field. Fetch all data points when rendering a full act, update a single data point when a user edits one field, and use bulk updates when you need to persist multiple changes at once. The generated API reference documents the request bodies and validation rules for each data workflow.

Each data point includes:

  • id and template_field_id for mapping values back to the template.
  • name, type, and required to describe the field semantics.
  • section_id, tab_id, and order to preserve the template structure.

Validate values against the act field's type and effective options before sending updates. Template edits affect future acts; existing acts retain their copied definitions.

For an external source refresh requested through act.fetch_data, return fetch_request_id with each single update or at the top level of a bulk update. These responses refresh the stored source value as well as the current value. Regular updates without correlation keep the existing source behavior. Follow Return requested external data for request IDs, failure reporting, and conflict handling.

Best practices​

  • Use act definitions for updates - Validate against the fields copied into the act and their effective options. Use templates when preparing future acts.
  • Cache act detail - Act payloads are stable after completion; cache responses for short periods to reduce API calls.
  • Prefer latest endpoints - Use the latest act endpoints when you only need the most recent evaluation instead of scanning full histories.
  • Track timestamps - Use updated_at to trigger downstream sync jobs or refresh stale views.

Working with the API reference​

The generated API reference in the sidebar documents every request and response schema for acts and act data. Combine the conceptual guidance here with the reference details to build reliable act workflows.