Work with Client Data

This guide shows how to send field values from your own system onto a Kalepa report — for example a policy number, an effective date, or a revenue figure. One endpoint does this: POST /external/reports/{report_id}/client-data.

All examples use the production base URL https://api.kalepa.com and a token in $TOKEN. See Getting started for the token and Work with reports for the report identifier rules.

The values ACME-2026-000123, COMMERCIAL, and EAST are examples. Replace them with your own submission number, org group, and sub-org group.

The request

Send a JSON array of name / value pairs. The rules:

• 1 to 200 entries per request. Split larger pushes into more requests.
• Each name appears at most once per request. Names are free text.
• Each value is any JSON value: a string, a number, a boolean, an object, or an array.
• Kalepa routes each name to the matching field configured for your organization. Names without a configured field are stored with the report as custom fields.

Target the report by its Kalepa report ID or by your own external_id; the id_type, org_group, and sub_org_group query parameters work exactly as on Work with reports.

Push values by Kalepa report ID

curl -X POST "https://api.kalepa.com/external/reports/f116fa5c-e5d9-43c2-8dc3-ac3fa60ff3b3/client-data" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '[
    {"name": "policy_number", "value": "POL-2026-004711"},
    {"name": "annual_revenue", "value": 4200000},
    {"name": "policy_effective_date", "value": "2026-10-01"}
  ]'

Push values by your external_id

curl -X POST "https://api.kalepa.com/external/reports/ACME-2026-000123/client-data" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '[{"name": "policy_number", "value": "POL-2026-004711"}]'

To scope the lookup when the same external_id exists in several org groups:

curl -X POST "https://api.kalepa.com/external/reports/ACME-2026-000123/client-data?org_group=COMMERCIAL&sub_org_group=EAST" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '[{"name": "policy_number", "value": "POL-2026-004711"}]'

Read the response

The call is synchronous. A 200 reports one outcome per entry:

{
  "report_id": "f116fa5c-e5d9-43c2-8dc3-ac3fa60ff3b3",
  "results": [
    {"name": "policy_number", "status": "APPLIED", "detail": null},
    {"name": "annual_revenue", "status": "APPLIED", "detail": null},
    {"name": "policy_effective_date", "status": "FAILED", "detail": "…"}
  ]
}

• report_id is the Kalepa report ID the values were applied to. When you pushed by external_id, use it to confirm the target.
• status is APPLIED when the value landed and FAILED otherwise; detail explains a failure.
• A 200 can contain a mix of APPLIED and FAILED. Check every entry; retry only the failed ones.

Pushing the same name again overwrites the earlier value. The push is idempotent: sending the same payload twice gives the same end state.

Errors

The AMBIGUOUS_IDENTIFIER body has the same shape as on the other report endpoints:

{
  "detail": {
    "code": "AMBIGUOUS_IDENTIFIER",
    "message": "…"
  }
}

Recommendations

• Push right after you create the report, so the report carries your reference data from the start.
• Check results on every 200; do not treat the status code alone as success.
• Agree the field names with Kalepa once, then keep them stable. A renamed field becomes a new custom field.