API SOURCE (written to the data store) — store per-product values that YOU (the client's own model) computed, as a new 'API source' attribute — written straight into the project's data store (no CSV, no join handle) — so a feed rule can read the attribute directly instead of matching free text with `contains`/conditions. PREFER this whenever a rule would otherwise need a long or complex condition tree. Typical flow: call preview_products to read products, derive ONE value per product with your own reasoning (e.g. the color, gender, or material from the title/description), then call this with `values` as a JSON OBJECT (not an array) mapping each product's `id` (the `id` field from preview_products) to the computed value. Values keep their JSON type — send a NUMBER for a numeric attribute (so numeric rule operators work), a boolean, or a string; a null clears that product. `code` is the new attribute name (e.g. "ai_color"); once applied it becomes the source attribute api_source.<code> (visible in list_source_attributes). Send large catalogs in BATCHES: first batch mode:"replace", following batches mode:"append"; set apply:true on the LAST batch only, to materialize (this re-imports so the values land on products — an ASYNCHRONOUS import). VERIFY before using it: poll get_import_status until the newest api_source run in recentRuns has running:false and status 'ok', and the code appears in list_source_attributes; only THEN attach the attribute to a feed with map_feed_attribute or reference api_source.<code> in a rule (create_rule / update_rule). If that run errors, run_import retries without re-sending the values. `code` must not collide with an existing source attribute of another class. project_id is OPTIONAL (inferred for a single-project customer). Requires the additional-sources addon: without it the call is refused with error 'addon_required' (HTTP 403) with addonCode. Explain the unavailable entitlement and do not retry or offer a purchase. Returns {status:'written'|'applied', code, valueCount, applied}.