Credit and decision engines are analysis automations that run through Taktile, an external decision-engine platform. Each engine is configured on a flow to score or classify clients and cards based on a policy — the set of rules, calculations and criteria defined in Taktile.The decision engine classifies a client into thematic modules (for example, registration, compliance, credit restrictions), returning an illustrative result per field (such as 🟢/🟡/🔴).
The credit engine computes a score, a risk rating, and optionally a suggested/approved value, plus a breakdown by criteria under output[].
policyId), and then run against specific cards and clients.Endpoints in this domain#
Execution against a card#
| Method | Path | Description |
|---|
GET | /v1/cards/{cardId}/actions/decision-engine/clients/{clientId} | Gets the decision engine result for the client |
POST | /v1/cards/{cardId}/actions/decision-engine/clients/{clientId} | Runs the decision engine for the client |
GET | /v1/cards/{cardId}/actions/credit-engine/policies/{policyId}/clients/{clientId}/inputs | Gets the inputs that would be sent to the credit engine, without running it |
GET | /v1/cards/{cardId}/actions/credit-engine/policies/{policyId}/clients/{clientId} | Gets the credit engine result for the client |
POST | /v1/cards/{cardId}/actions/credit-engine/policies/{policyId}/clients/{clientId} | Runs the credit engine for the client |
Decision engine configuration#
| Method | Path | Description |
|---|
GET | /v1/flows/{flowId}/decision-engine-config | Gets the flow's decision engine configuration |
POST | /v1/flows/{flowId}/decision-engine-config | Creates the decision engine configuration |
PUT | /v1/flows/{flowId}/decision-engine-config/{id} | Updates the decision engine configuration |
DELETE | /v1/flows/{flowId}/decision-engine-config/{id} | Removes the decision engine configuration |
Credit engine configuration and policies#
| Method | Path | Description |
|---|
GET | /v1/flows/credit-engine-config/{id} | Gets the full detail of a credit engine configuration |
POST | /v1/flows/{flowId}/credit-engine-config | Creates the credit engine configuration |
PUT | /v1/flows/{flowId}/credit-engine-config/{id} | Updates the credit engine configuration |
DELETE | /v1/flows/{flowId}/credit-engine-config/{id} | Removes the credit engine configuration |
GET | /v1/flows/{flowId}/credit-engine/policies | Lists the credit engine configurations registered on the flow |
GET | /v1/flows/{flowId}/credit-engine/policies/cards/{cardId}/clients/{clientId} | Lists the credit policies applicable to a specific card and client |
Watch out: two different identifiers both called "policyId"#
This is the most confusing behavior in this domain, and is worth reading carefully before making any credit engine execution or lookup call against a card.The path of the three credit engine execution/lookup endpoints against a card uses a {policyId} segment:/v1/cards/{cardId}/actions/credit-engine/policies/{policyId}/clients/{clientId}[/inputs]
policyId field of the saved engine configuration body (credit-engine-config). It is actually the identifier of the credit engine configuration itself on the flow: a MongoDB-style ObjectId, 24 hexadecimal characters.Sending the wrong identifier (for example, the Taktile policy UUID) on this path returns a 400 validation error.Before calling any of these three endpoints, obtain the correct identifier from GET /v1/flows/{flowId}/credit-engine/policies — use the id field of each returned item. The decision engine does not have this problem: its card execution path (/v1/cards/{cardId}/actions/decision-engine/clients/{clientId}) does not include a policy identifier at all.Sandbox and production publishing#
Every policy registered in Taktile — credit or decision — starts out in a test environment (sandbox). Before it can process real cards in production, the corresponding policy needs to be published. Without that publishing step, the engine may still respond to calls, but it does not reflect real decisions based on the card's data.Important behaviors#
Opposite root-level payload rules between the credit and decision engines. The credit engine configuration (credit-engine-config) REQUIRES the title, description and hasValue fields at the root level, both on create and on update. The decision engine configuration (decision-engine-config) REJECTS those same title and description fields — sending them returns a 400 error.
companyId is required on create and forbidden on update, for both engines (credit and decision). Sending it on PUT returns a 400 error.
The path field in the decision engine's output[].fields[] behaves oppositely between create and update: required on create (use the literal value generate for fields computed automatically), and must be omitted on update.
The credit engine's output fields (output[].segments[].fields[]) never have a path — only aggregates[] items, when present, have a path, pointing to the source of each aggregated value.
The credit engine's native score, rating and value fields are computed automatically by the engine at runtime — they must not be included in output[].segments[].fields[].
The keys (key) used in input[] and output[] for both engines must match exactly the keys declared by the Taktile policy at registration time — the engine rejects, at execution time, configuration keys the policy did not declare.
GET /v1/flows/{flowId}/decision-engine-config returns 200 with an empty body ({}) when the flow does not yet have a decision engine configured, rather than an error status.
GET /v1/flows/credit-engine-config/{id} has a different path shape from the other endpoints in this domain: it does not include the flow identifier — it is /v1/flows/credit-engine-config/{id}, not /v1/flows/{flowId}/credit-engine-config/{id}.
Removing an engine's configuration does not automatically remove the phase action (credit-engine or decision-engine) that enables it on a phase — we recommend reviewing and removing that phase action before or shortly after removing the configuration.
Modificado em 2026-07-28 20:38:32
