Match every output to its receiving role.
ENG-024_0007.tifEstablish the product, environment, and object rules
OpenText’s Content Metadata Service documentation illustrates an API-oriented pattern that combines authenticated access, content upload, and a content-management file object with fields such as name, description, rendition, and destination folder. The customer team determines whether that pattern, another import route, or a customer-run process is appropriate for its product and deployment.
Discovery records the environment and endpoint owner, authentication and authorization process, target folder or container, object type, required properties or categories, rendition expectations, versioning policy, and the person responsible for error handling. Credentials stay under customer control; National Microfilm works from the approved access and delivery procedure.
Package content and properties for the selected path
The package connects every file to a stable record ID, relative path, MIME declaration, descriptive properties, OCR status, and checksum. The data dictionary records the source field, target property, data type, allowed values, and whether a value is required. A neutral CSV, XML, or JSON sidecar can be transformed into the customer’s actual import index or payload only after its contract is reviewed.
Image masters, access PDFs, PDF/A derivatives, and text output are named and grouped according to the specified rendition and retention needs. Where the target expects a particular content type or file format, it controls the production derivative; OCR is delivered according to the agreed search and review requirements.
- Destination container and object type identified by the customer
- Property/category map includes controlled lists and date formats
- MIME type, rendition role, and versioning expectation recorded
Use a controlled test before production delivery
The customer’s authorized OpenText team validates a representative batch for destination placement, property values, content rendering, permissions, and any version or rendition behavior in the selected workflow. National Microfilm reconciles record IDs, file counts, and checksums and updates the package to the test decision. Error, retry, and final-release responsibilities are documented before the full handoff.
Illustrative OpenText content map
The labels below are a planning crosswalk; the final properties are those approved for the target OpenText environment.
| Prepared field | Example value | Target mapping review |
|---|---|---|
| file_name | NM-000241.pdf | Content object name |
| destination_path | /Records/Purchasing/1958 | Approved folder or container |
| title | Purchasing correspondence | Description or property |
| mime_type | application/pdf | Content/rendition declaration |
| record_date | 1958-06-14 | Approved date property |
Common questions
Do you use the OpenText API for every project?
No. The delivery method follows the customer-approved product, deployment, access, and test process. We can prepare files and structured metadata for the approved import or API workflow.
What does the customer administrator need to confirm?
The target environment and container, object/property requirements, authentication owner, format and rendition rules, versioning expectations, test dataset, and acceptance responsibilities.
Sources & further reading
These references explain technical formats, standards or destination requirements. They do not imply endorsement of National Microfilm.