Developers · Documentation

ENRIVAQ Documentation

Use the documentation to understand how product data enters the platform, how enrichment is structured, how results are validated and how completed records move back into the customer workflow.

This hub is task-oriented. Start with a concrete job — import data, define a schema, run enrichment, review results or integrate an API — and reach the relevant technical reference without reading marketing pages first.

Getting started Schemas API Errors

TASK ATLAS / DOCUMENTATION INDEX11 TOPIC PATHS

DOCUMENTATION HUBStart with the jobConcepts here. Endpoint detail in the API reference.

IMPORTBring product data in

SCHEMASDefine the target structure

ENRICHMENTUnderstand the workflow

VALIDATIONReview the result

API / INTEGRATIONSConnect systems

ERRORS / SECURITYOperate safely

Verification pending on marked items. Endpoint-level details stay in the API reference.

Getting started

Start here if you are implementing for the first time

Bring a representative catalog slice, define the target schema, run enrichment and review flagged records before production rollout.

ONBOARDING RUNBOOK4 STEPS

Get accessWorkspace, roles and API credentials for the people who will run the pilot.IMPLEMENTATION

Bring a sample catalogA representative slice — not only the cleanest records — with identifiers included.DATA IMPORT

Define the target schemaCategories, required fields and units the enriched record must satisfy.SCHEMA

Run and reviewEnrich the slice, review flagged records and compare against your expectation.VALIDATION

Account / accessPROJECT SETUP

Minimum product dataIDENTIFIER + AVAILABLE CONTEXT

Expected workflowDOCUMENTED

Pilot structureREPRESENTATIVE SAMPLE + TARGET SCHEMA + REVIEW

Data import

Supported ways to provide product data

ENRIVAQ can receive product data from a website, API or file-based input. Exact file shape, API schema and project constraints are defined during implementation.

Public capability: Website · API · File. Native PIM/ERP/commerce connectors are not claimed by default.

INTAKE METHOD REGISTRYVERIFICATION STATUS

FILE INPUTPROJECT-SPECIFIC FORMATRequired fields and file shape are agreed for the project.PROJECT CONTRACT

API INPUTPROJECT-SPECIFIC CONTRACTExact endpoint, schema and operational behavior are supplied for the implementation.PROJECT CONTRACT

SYSTEM HANDOFFEXISTING CUSTOMER STACKExchange direction/method is configured; no native connector is implied.PROJECT-SPECIFIC

WEBSITE / SUPPLIER SOURCEPRODUCT RESEARCH INPUTPublic product/source context can be researched as part of enrichment.SUPPORTED

Schemas

Define the target product structure before enrichment writes into it

Categories, required fields, optional attributes, units, naming conventions and mapping rules stay separate from the values discovered during enrichment.

SCHEMA CONTRACT BLUEPRINTDEFINE ≠ DISCOVER

CUSTOMER SCHEMA

What you define

Categories and required field sets

Optional attributes and their types

Units, notation and naming conventions

Mapping rules to your system fields

SCHEMA
BOUNDARY

DISCOVERED DATA

What enrichment finds

Extracted attribute values

Source references per value

Candidate classifications

Unresolved fields stay empty

Enrichment never silently introduces a field the customer schema does not define.

Enrichment

From product identification to prepared content

The workflow runs through identification, research, extraction, normalization, validation and content preparation. Each stage may be automatic, configuration-dependent or review-capable.

WORKFLOW PLAYBOOK6 STAGES

IdentifyResolve the product.STAGE

ResearchLocate usable evidence.STAGE

ExtractStructure candidate values.STAGE

NormalizeMatch units and naming.STAGE

ValidateHold uncertainty.REVIEW-CAPABLE

Prepare contentUse approved facts.CONFIG-DEPENDENT

Configuration-dependent stages run only where the workspace enables them. Review-capable stages can hold a record for a person.

REVIEW STATE CONSOLEPUBLIC VALIDATION SEMANTICS

Source supportIs the candidate value supported by evidence?CHECK

Schema compatibilityDoes the value belong to the defined field and expected type?CHECK

Conflict stateDo multiple sources disagree or require human resolution?REVIEW-CAPABLE

Stable downstream stateNo single public numeric threshold is presented as the decision rule.STRUCTURAL ROUTING

Unresolved fields remain empty rather than being filled with a guess.

Validation

Use evidence state without exposing internal scoring thresholds

Supported values can continue; ambiguity, incomplete evidence/binding or conflicts are held for review; invalid or irrelevant evidence is rejected. Internal numeric thresholds are not a public product contract.

PUBLIC SEMANTICS: CONTINUE · REVIEW / HOLD · REJECT. Exact internal technical labels remain implementation detail.

Exports

The structure of a completed record

A completed record carries the original input, enriched fields, validation state and source references that support each value.

COMPLETED RECORD ENVELOPEPRODUCTION FORMATS ONLY

LAYER 01Original input

LAYER 02Enriched fields

LAYER 03Validation state

LAYER 04Source references

COMPLETED RECORD

One structured return object

inputPRESERVED

enriched_fieldsSTRUCTURED

validationSTATE

sourcesATTACHED

Retrieval and transfer options are documented per verified production format. Examples are updated when the output structure changes.

API

Use this hub for concepts and the API reference for endpoint-level detail

Documentation explains what a job, product schema, validation state or result means. Exact routes, payloads and error contracts belong in the API reference.

REFERENCE BOUNDARY MAPCONCEPTS ↔ ENDPOINTS

DOCUMENTATION HUB

Concepts and workflows

How data enters
How schemas are defined
How enrichment and validation behave
How records move downstream

BOUNDARY

API REFERENCE

Exact technical contract

Authentication
Endpoint paths
Request / response schema
Status and error behavior

Integrations

Document the actual exchange pattern, not a presumed native connector

Where no connector exists, the documented workflow is file-based or API-based. Nothing is labelled native by default.

INTEGRATION PATTERN MATRIXCURRENT PUBLIC BOUNDARY

SystemPatternDocumented behaviorStatus

AkeneoPROJECT-SPECIFICUse API/file exchange only where implemented; no native ENRIVAQ connector is claimed.NO NATIVE CLAIM

PimcorePROJECT-SPECIFICReturn/write-back depends on the implemented customer workflow.NO NATIVE CLAIM

inriverPROJECT-SPECIFICExchange method must be implemented for the customer architecture.NO NATIVE CLAIM

ERP systemsAPI / FILE INPUTInput is supported through the project intake method; downstream handoff is configured.PROJECT-SPECIFIC

Shopify / Magento / ShopwarePROJECT-SPECIFICNo generic native storefront connector or automatic write-back is claimed.PROJECT-SPECIFIC

Other systemsASSESS PER PROJECTInput/output method is confirmed during implementation.NO UNIVERSAL CLAIM

Errors

Separate product-data problems from API and processing failures

The operational response depends on what failed. Product-data exceptions are documented separately from transport/integration failures. Exact external API error codes are supplied only by the implemented project contract.

PUBLIC PRODUCT-DATA REASONS: missing supported value · unit/schema mismatch · source conflict · identity/variant ambiguity. TRANSPORT CODES: PROJECT CONTRACT.

FAILURE TRIAGE TREEILLUSTRATIVE TAXONOMY

PRODUCT DATA PROBLEMS

MISSING_REQUIRED_FIELDRequired field has no supported valueCorrect the data or accept the field as unresolved.

UNIT_MISMATCHValue does not match the target unitDefine the conversion or correct the source value.

SOURCE_CONFLICTSources disagreeResolve in review or define a source-priority rule.

INTEGRATION FAILURES

ACCESSAuthentication / permission failureCredentials missing, expired or lacking required access.

REQUESTContract/schema failurePayload does not match the documented contract.

PROCESSLimit / processing failureBackoff or retry behavior must follow the verified reference.

Exact transport/error codes and retry semantics are not claimed universally; use the project API reference.

Security

Use dedicated source-of-truth pages for security and data handling

Documentation points to the pages that own security, privacy, AI-data handling and GDPR statements instead of duplicating claims.

TRUST SOURCE INDEXAUTHORITATIVE REFERENCES

/security/SecurityVerified public controls for the platform.SOURCE OF TRUTH/data-privacy/Data PrivacyWhat customer data is held and for how long.SOURCE OF TRUTH/ai-data-policy/AI & Data PolicyWhich tasks use a model and what payload leaves.SOURCE OF TRUTH/gdpr/GDPRRoles, purposes, subprocessors and rights.SOURCE OF TRUTH

CHANGE IMPACT TIMELINENO PUBLIC VERSIONED CHANGELOG CONTRACT YET

NOT PUBLISHEDAPIIntegration change — publish here when a versioned public API contract existsNOT PUBLISHED

NOT PUBLISHEDSchemasSchema change — publish here when a public schema version changesNOT PUBLISHED

NOT PUBLISHEDFormatsFormat change — publish here when a public format contract changesNOT PUBLISHED

NOT PUBLISHEDWorkflowWorkflow semantics change — publish here when a public contract changesNOT PUBLISHED

No universal public release/change-notification SLA is currently claimed. Integration-affecting changes are coordinated within active project contracts.

Changelog

What changed, when, and whether you must act

The changelog records changes that affect integrations, schemas, API behavior, supported formats or workflow semantics.

CURRENT STATUS: no public versioned changelog contract. Add dated entries here only after a public API/schema versioning policy is established.