Reusable compliance template API reference

A compliance template is a reusable policy pattern that an integration prepares before operators create assets. Each template stores its modules, jurisdictions, required controls, draft or published status, and module-set version.

Use these endpoints when your integration prepares policy templates before operators create assets in the Asset Designer. For the system-level module registry that templates rely on, see Compliance modules API. For the operator workflow, see Policy templates.

Template state model

Compliance templates can be DALP library templates or organisation templates. List responses include both by default. DALP library templates sort before organisation templates and are immutable through the organisation API. Your integration can read and filter them, but cannot update, publish, or delete them.

Organisation templates start as drafts and remain editable until published. Publishing changes isDraft to false. A repeat publish request returns a conflict response instead of creating a new version.

Jurisdictions are stored on the template. A template with no jurisdictions is a global template. When you filter for a specific jurisdiction, the API returns templates tagged with that jurisdiction and also includes global templates, so your integration can present jurisdiction-specific options alongside unrestricted defaults in a single list.

Endpoints

The compliance template API exposes these endpoints:

Responses use the DALP single-resource or collection envelope with data and links.self. List responses also include pagination metadata. Facets are returned for isSystem, isDraft, and moduleSetVersion.

Create a draft template

Create requests start a template in draft state. If you omit moduleSetVersion, DALP uses the current module set version. Older clients may still send the deprecated legacy boolean; new code should send moduleSetVersion instead.

Current-generation control IDs

Use moduleSetVersion: 2 for new templates. DALP validates every modules[].typeId and every requiredControls[] entry against that version before it saves or publishes the template. On create requests, incompatible values produce schema errors on the offending field paths, such as modules.0.typeId or requiredControls.0. The same rules apply whether the control is already configured in modules or only required for the later asset creation workflow.

Legacy templates with moduleSetVersion: 1 can still use the older control IDs when your code reads or maintains an existing policy set. Do not mix legacy IDs such as country-allow-list, investor-count, or transfer-approval into a current-generation template. On create, the API rejects the incompatible field during request validation. On update or publish, the API can return the module-set compatibility error with the incompatible type IDs.

curl --request POST \
  "$DALP_API_URL/api/v2/settings/compliance-templates" \
  --header "X-Api-Key: $DALP_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "Global capital raise policy",
    "description": "Reusable capital raise controls for regulated assets",
    "jurisdictions": [],
    "moduleSetVersion": 2,
    "modules": [],
    "requiredControls": ["capital-raise-limit"]
  }'

The response includes the created template and a links.self path for the new resource.

Update template configuration

Update requests can change the name, description, jurisdictions, modules, and required controls. They cannot change the template's module set version. To use a different version, create a new template with the target moduleSetVersion and move the required modules or controls there.

DALP validates modules and required controls against the template's module set version on create, update, and publish. On create, an incompatible control triggers a request validation error on the field that supplied it. On update or publish, a current-generation template rejects controls that only belong to a legacy module set. If the API returns a module-set compatibility error, remove the incompatible controls or create a template with the matching version.

Publish a template

Publish the template when it is ready to appear in asset creation workflows:

curl --request PUT \
  "$DALP_API_URL/api/v2/settings/compliance-templates/$TEMPLATE_ID/publish" \
  --header "X-Api-Key: $DALP_API_TOKEN"

Publishing changes isDraft to false. Published templates can be selected during asset creation. Draft templates stay editable until you publish them.

List and filter templates

Use the list endpoint to find templates by search, draft status, source, jurisdiction, or module generation. By default, the list includes DALP library templates and templates owned by the active organisation, with DALP library templates sorted first.

The list endpoint uses the standard collection query pattern:

Supported filter and sort fields:

For example, request recently updated current-generation draft templates when you are preparing a new policy set for your organisation:

curl --globoff \
  "$DALP_API_URL/api/v2/settings/compliance-templates?filter[moduleSetVersion]=2&filter[isDraft]=true&filter[isSystem]=false&sort=-updatedAt&page[limit]=25" \
  --header "X-Api-Key: $DALP_API_TOKEN"

The response contains a data array of compliance templates. Each template includes id, name, description, jurisdictions, isSystem, isDraft, moduleSetVersion, organizationId, version, modules, requiredControls, createdBy, createdAt, and updatedAt. Response metadata lets clients render paginated tables. Facets for isSystem, isDraft, and moduleSetVersion let clients build source, status, and module-version filters without hard-coding the available values.

Read the template before you update it. Another operator or your other code may have changed the template version or draft status since your last read.

Related

• Compliance modules API
• Policy templates user guide
• Asset creation with instrument templates
• Request headers
• Platform API error reference