3. Objects and mappings

After the first read, a system waits for your review. You check its objects and fields, correct what is wrong, and approve. Then you map it to another system.

Review a system's objects and fields

In the app, open the system. Its tabs are Review, Objects and fields, Flows, Sign-in, Sync timing, Settings and History.

From the API, read what was found:

curl https://api.inferrex.com/v1/connections/CONNECTION_ID/manifest \
  -H "X-API-Key: $INFERREX_API_KEY"

The part you review is manifest.entities. Each entity is one object. Shape, trimmed to the fields you will use most:

{
  id: string;
  version: number;
  manifest: {
    displayName: string;
    baseUrl: string;
    entities: {
      id: string;
      apiName: string;
      displayName: string;
      description: string;
      fields: {
        id: string;
        apiName: string;
        displayName: string;
        type: string;
        required: boolean;
        nullable: boolean;
        role?: string;                 // what the field represents, such as an identifier
        sensitivity?: string;          // pii, financial, health or credential
        typeConfidence: number;
        requiresCustomerReview: boolean;
        included?: boolean;
        group?: string;
      }[];
      relationships: { type: string; targetEntityId: string; throughField: string; confidence: number }[];
    }[];
  };
}

Start with the fields where requiresCustomerReview is true.

Accept or correct one field

curl -X POST https://api.inferrex.com/v1/connections/CONNECTION_ID/approve-field \
  -H "X-API-Key: $INFERREX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "fieldPath": "ENTITY_ID.FIELD_ID",
    "approved": true,
    "correctedSensitivity": "pii",
    "reason": "Holds the customer email address"
  }'

fieldPath is <entityId>.<fieldId>. You can correct the type (correctedType), name (correctedDisplayName), description (correctedDescription), which system is trusted for it (correctedAuthority), what it represents (correctedRole) and its sensitivity (correctedSensitivity: none, pii, financial, health or credential). Your corrections take priority.

Leave fields out

A field you leave out is never suggested for mapping, never synced, never archived and never shown in your sensitive-data map.

curl -X PATCH https://api.inferrex.com/v1/connections/CONNECTION_ID/field-inclusion \
  -H "X-API-Key: $INFERREX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"fields": [{"entityId": "ENTITY_ID", "fieldId": "FIELD_ID", "included": false}]}'

Each change is saved as a new version, so you can see it in the history and undo it.

Group fields

Put fields into groups, such as financial or contact details, so you can make one decision for the whole group later. GET /v1/connections/:id/field-group-recommendations suggests groups with a reason for each. PATCH /v1/connections/:id/field-groups saves them.

Approve the system

curl -X POST https://api.inferrex.com/v1/connections/CONNECTION_ID/approve \
  -H "X-API-Key: $INFERREX_API_KEY"

Approval makes the system usable in flows. It works only while the system is waiting for review, and only once a test of its sign-in has read data from it. Until then the answer is 409 connection_not_proven. Prove it with POST /v1/connections/:id/test, then approve again.

Check the size before loading

POST /v1/connections/:id/assess-scope asks the system how many records each object holds and estimates the storage, time and API calls a first full load would take. Run it before you turn on a flow against a large system.

Map two systems

A mapping says how the data in one system lines up with another: which objects correspond and which fields feed which.

Step 1: match

curl -X POST https://api.inferrex.com/v1/connections/SOURCE_CONNECTION_ID/match \
  -H "X-API-Key: $INFERREX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"targetConnectionId": "TARGET_CONNECTION_ID"}'

Response shape: { mappingId, jobId, runId, status, sourceConnectionId, targetConnectionId }.

By default the call waits and returns mappingId. If it takes longer, or you send "respondAsync": true (or the header Prefer: respond-async), it returns a jobId at once. Follow the job with GET /v1/jobs/:id and read the mapping id from its result when it has succeeded.

Step 2: review

A mapping holds entityMappings, and each holds fieldMappings. The fields of a link that matter in review:

{
  id: string;
  sourceEntityId: string; sourceFieldId: string;
  targetEntityId: string; targetFieldId: string;
  transform: string;
  authority: string;
  direction?: string;
  confidence: number;
  matchRationale: string;
  customerApproved: boolean;
  customerRejected?: boolean;
  omitted?: boolean;
}

Step 3: decide each link

Change one link:

curl -X PATCH https://api.inferrex.com/v1/mappings/MAPPING_ID/field-mapping \
  -H "X-API-Key: $INFERREX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"fieldMappingId": "FIELD_MAPPING_ID", "approved": true}'

Two decisions are easy to confuse:

• Reject ("approved": false) means the link is wrong.
• Leave out ("omitted": true) means do not sync this field. It does not change whether the link is approved.

Decide many links at once:

curl -X PATCH https://api.inferrex.com/v1/mappings/MAPPING_ID/field-mappings \
  -H "X-API-Key: $INFERREX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"fieldMappingIds": ["FIELD_MAPPING_ID_1", "FIELD_MAPPING_ID_2"], "action": "approve"}'

action is approve, reject, omit, restore or amend. The whole batch is saved as one new version, so it can be undone in one step.

Other edits:

Set the entity match before you sync. The sync looks for a target record with the same values in those fields and updates it, so it does not create a duplicate.

Step 4: approve the mapping

curl -X POST https://api.inferrex.com/v1/mappings/MAPPING_ID/approve \
  -H "X-API-Key: $INFERREX_API_KEY"

Flows that use an approved mapping can be turned on.

Versions

Every edit to a mapping saves a new version.

A flow keeps the mapping version it was turned on with. Editing a mapping does not change a running flow. The edit's answer lists the flows still on an older version in flowsBehind. Move a flow to the new version with POST /v1/pipelines/:id/apply-mapping (chapter 4).

Next: flows.