Skip to main content

Enrichments

Use the catalog to choose an enrichment and see which fields to send. You can read it without authentication. It lists IDs, input and settings schemas, output fields, limits, and available pricing.

Enrichments​

Listing returns the documented public enrichment IDs in reference order, with one entry per enrichment. Previously authorized IDs remain usable for direct schema reads and task creation.

List available enrichments:

bash
curl 'https://api.datablist.com/v1/enrichments'

Read one complete definition:

bash
curl 'https://api.datablist.com/v1/enrichments/ENRICHMENT_ID'

Each definition contains:

  • @id: the ID to send as enrichmentId.
  • inputSchema: the JSON Schema for each input's data object.
  • settingsSchema: the JSON Schema for the task's settings object.
  • outputSchema: known fields returned in outputs.
  • limits: enrichment-specific batching and execution limits.
  • cost: human-readable pricing, such as 25 credits per email found. It is null when unavailable. Use it to understand the billing unit and pricing rules.
  • creditsPerInput: a fixed cost when it can be stated in advance, otherwise null. A null value does not mean the enrichment is free; actual usage is returned with task results.

cost describes pricing; it is not a numeric amount or a spending guarantee. Use task and result credit fields for actual usage.

The output schema is a guide to the fields you may receive. Results can include extra fields before they appear in the catalog, especially when settings change field names. Keep those fields when reading outputs.

Conditional fields​

Some fields apply only when you choose a particular setting. The schema keeps those fields listed and uses enableOnSetting to describe when they apply.

For example, the following input is required when you set useFullName to true:

json
{
  "type": "object",
  "properties": {
    "fullName": {
      "type": "string",
      "enableOnSetting": "useFullName==true",
      "requiredWhenEnabled": true
    }
  },
  "additionalProperties": true
}

Here, requiredWhenEnabled: true makes fullName required only when settings.useFullName is true. Fields that are always required appear in the usual JSON Schema required array.

If you send a known input field, its type and format are checked even when its condition is inactive. Extra input and settings fields are accepted.

If you build your own settings form, read these rules as follows:

  • == means equal; != means different.
  • Commas separate alternatives. mode==full,preview accepts either mode.
  • & requires both conditions. mode==full,preview&includePictures==true also requires pictures to be enabled.

Values are case-sensitive and whitespace is preserved. Missing values, null, false, 0, and "" compare as the text false; other single values compare as strings. A rule inside a settings section reads values from that section. These rules are not JavaScript.

For settings, a condition controls when to show a field; it does not change validation. For outputs, it explains when a field is expected, but never removes data from results. Settings can also produce custom output names not yet listed in the catalog.

Documented enrichments​

To generate objects from settings instead of enriching existing rows, use the Sources API catalog.

Check the current schema when integrating an enrichment, and allow extra response fields as it evolves.