Prerequisites
The sending system calls the ContentFlow API with a token from your environment’s identity provider. Give each integration its own identity, for example a dedicated API client, so you can rotate or disable it without affecting other integrations. The submission endpoints accept any identity your environment authenticates; they do not check ContentFlow permissions. ContentFlow permissions govern the ContentFlow application and its administration, not who may submit.What an item carries
Properties and property groups
Each property has a Name and a Value. Send the same name more than once to deliver several values. A mapping row then writes one keyword value per value, unless the row keeps only the first. To deliver repeating structured data, such as several policies on one letter, give the properties that belong together the same GroupName and GroupIdentifier. All properties of one policy share a group identifier; the next policy uses another. A mapping turns each group instance into a keyword record of the type you choose. Keep property names stable. A mapping reads properties by name (letter case is ignored), so a renamed property can silently stop reaching its keyword. Try it in the mapping editor lists properties that no row reads, which shows a rename quickly.Metadata-only items
An item can arrive without a file when the file is fetched later by the workflow, for example from a storage export during a migration. Mark the submission as metadata-only, include at least one property, and optionally the file name and MIME type the document should get. The workflow then starts with a step such as Fetch file from Azure Blob; see the step reference.Submit an item
The ContentFlow API accepts an item in two forms:
The API publishes its OpenAPI description and an interactive reference at
/swagger on its address. Use that reference for your environment’s version rather than inferring fields from an example.
A JSON submission of a one-page policy schedule with two properties looks like this:
Confirm the outcome
The sending system can ask for an item’s state withGET /api/items/state/{traceId}. The response contains the state (Pending, Started, Completed, Failed or ScheduledRetry), the error message of a failed run, the batch name, and any result properties the workflow recorded. A workflow records result properties with its Add state result property step, for example the document ID Nobly Insight assigned.
The same runs appear in the ContentFlow application under States, where you can read each run’s logs and the document that was sent. A sending system that needs a push notification instead of polling can be called back by a Webhook callback step after the upload; see the step reference.
Verify a new integration
Before you switch a sending system on in production, submit a handful of representative items in a test environment:Where to read next
Document mappings
Define in one place what Nobly Insight receives for each incoming item: its document type, its document date, and one row per keyword.
API clients and service accounts
Create a dedicated machine identity for a sending system, and rotate or disable it independently.