Skip to content
English
Go to our website
  • There are no suggestions because the search field is empty.

Getting Your Cargosnap Workflow Data into a Logic App

This document explains how to receive and parse the Cargosnap data so you can extract every value the user submitted.

What This Document Covers

You executed a workflow in Cargosnap — a user scanned a barcode, took photos, and filled out a form. Now you want to use that data in an Azure Logic App, perhaps to send it to a database, trigger an EDI message, or notify someone by email.

⚠️ Integrating with our API requires technical knowledge and development experience.

1. Receiving the Webhook
When a workflow run completes, Cargosnap sends a webhook (HTTP POST) to your Logic App. The payload is a workflow_run object:
{
  "id": 17214283,
  "client_key": "rcba6",
  "workflow_id": 17692,
  "file_id": 17275302,
  "tenant_id": 3270,
  "submit_date_time": "2026-02-25T16:02:49+00:00",
  "completed_at": "2026-02-25T16:03:42+00:00",
  "workflow_run_steps": [ ... ]
}
 The two fields you need:
  • file_id — identifies the Cargosnap file (dossier). You'll use this to fetch all the data.
  • id — identifies this specific workflow run. A file can have multiple runs, so you need this to find the right one.
The workflow_run_steps array is also present in the webhook, but the full file response contains richer data, so you'll fetch that next.
 

2. Fetching the Full File

Use the file_id from the webhook to call the Cargosnap API:

Authentication: Per the Cargosnap developer documentation, each API call requires the API token passed as a header variable. In your Logic App HTTP action, add a header:
API-TOKEN: {your_cargosnap_api_token}

Refer to the developer documentation for obtaining your token. You need a "Super Manager" or "License Admin" role.

The response contains the complete file with four main arrays:

 What it contains    

  • form_submits[] All form submissions — dropdowns, checkboxes, text fields

  • uploads[] All photos and scans taken during the workflow 

  • fields[] Barcode / scan values (e.g. serial numbers, reference codes)

  • workflow_runs[] All runs on this file, including the workflow definition

3. Understanding the Workflow Structure

Inside each entry in workflow_runs[], there are two nested structures. This relationship is the key to extracting your data.

3a. workflow.steps[] — The Template

This is the workflow definition: which steps exist, in which order, and what type they are.

Example:

Step_id Order Type Data
119059 1 seal { field_id: 6941 }  
119061 2 serial_snapper []  
119062  3 serial_snapper []  
119063 4 serial_snapper []  
119064 5 form { form_id: 18584 }  
119065 6 distributionList []  
119066  7 form { form_id: 18401 }  

The step type tells you what kind of data to expect. The data object gives you the identifiers you need to find the actual values (e.g. which field_id or which form_id).

3b. workflow_run_steps[] — The Actual Execution

This records what the user actually did. Each run step links to a workflow step via workflow_step_id, and points to the created data via entity_ids:

workflow_step_id entity_type entity_ids status    
119059 uploads [154800075] done
119061 uploads [154800087] done 
119062 uploads [154800099] done 
119063 uploads [154800108] done 
119064 form_submits [19365868] done 
119065 distributionList [] skipped 
119066 form_submits [] skipped 

Important:

Always derive the step type from the workflow definition (workflow.steps[].type), not from entity_type on the run step. The entity_type can be misleading — for example, a seal step (barcode scan) shows entity_type: "uploads" in the run step, even though the actual scanned value lives in the fields[] array.

4. Extracting Values by Step Type

Now you know which steps were executed and what entity_ids they produced. Here's how to look up the actual data for each step type.

4a. seal steps → Look in fields[]

A seal step captures a barcode or scan. The workflow step definition tells you the expected field_id via data.field_id.

How to trace it:

The workflow step has type: "seal" and data.field_id: 6941The corresponding run step has entity_ids: [154800075] — this points to an upload (the scan image), not the scanned value itself
  1. To get the actual value, look in the top-level fields[] array and match on field_id: 6941
{
  "field_id": 6941,
  "snap_id": 154800075,
  "value": "ABC123456"
}
The snap_id in the field record matches the entity_ids from the run step, confirming which scan image produced this value.
4b. serial_snapper steps → Look in uploads[]
These are photo steps. The entity_ids point directly to records in the uploads[] array.
 
How to trace it:
The run step has entity_ids: [154800087]Find upload id 154800087 in uploads[]
  1. The upload record contains the image_url and image_thumb fields
{
  "id": 154800087,
  "upload_type": "snap",
  "image_url": "https://cargosnapstorage.blob.core.windows.net/...",
  "image_thumb": "https://media-new.cargosnap.net/thumbnails/..."
}
A step can have multiple photos — entity_ids may contain more than one ID.
4c. form steps → Look in form_submits[]
A form step captures structured data. The workflow step definition tells you which form via data.form_id.
How to trace it:
The workflow step has data.form_id: 18584The run step has entity_ids: [19365868]
  1. Find form_submit id 19365868 in the form_submits[] array
The form_submit contains a form.fields[] array with every field the user filled in:
{
  "id": 19365868,
  "form_id": 18584,
  "nick": "Jane Doe",
  "submit_date_time": "2026-02-25 16:03:40.000",
  "form": {
    "fields": [
      { "id": 205708, "label": "Select category",    "type": "single_select", "value": "Option A" },
      { "id": 205709, "label": "Select subcategory", "type": "single_select", "value": "Option B" },
      { "id": 205710, "label": "Describe the issue",  "type": "single_select", "value": "[\"Choice 1\"]" },
      { "id": 215408, "label": "Flag for review",     "type": "checkbox",      "value": "1" }
    ]
  }
}
Note on value formats:
 
Some single_select values come back as plain strings ("Option A"), while others are wrapped in a JSON array ("[\"Choice 1\"]"). Always handle both in your Logic App — check if the value starts with [" and parse accordingly.
The form_submit also contains metadata like nick (who submitted it), submit_date_time, latitude/longitude, and location.
4d. Skipped steps
When a step was skipped (status: "skipped"), entity_ids is an empty array []. No data was captured — nothing to look up.
4e. distributionList steps
These trigger email notifications from within Cargosnap. They don't produce data you need to extract — if done, the notification was sent; if skipped, it wasn't.

5. Handling Multiple Forms (e.g. Multi-Language)
A common scenario: the same workflow is used by users in different languages. The English and Dutch versions ask the same questions, but because they are different forms in Cargosnap, every field_id is different.
 
For example, "Select category" might be:English form → field_id: 205708
  • Dutch form → field_id: 201618
Solution: A Field ID Mapping TableDefine a lookup object (a Compose action in your Logic App) that maps every language-specific field_id to a single canonical name:
{
  "205708": "category",
  "201618": "category",
  "205709": "subcategory",
  "201619": "subcategory",
  "205710": "issue_type",
  "201620": "issue_type",
  "215408": "flag_for_review",
  "215409": "flag_for_review"
}
When looping over the form fields, resolve the canonical name with:
 
outputs('FieldMapping')?[string(item()?['id'])]
 
This eliminates any need for language detection or form_id branching — both 205708 and 201618 simply resolve to "category".
 
When a new language or form variant is added, just add rows to the mapping. No logic changes.

6. Putting It Together: Logic App Pattern
Here is the recommended step-by-step pattern:
  1. Trigger — HTTP webhook receives the workflow_run payload
  2. Compose FieldMapping — define the field_id → canonical name lookup
  3. HTTP GET — https://api.cargosnap.com/api/v2/files/{file_id} with API-TOKEN header
  4. Parse JSON — parse the file response
  5. Find the workflow_run — filter workflow_runs[] to match the webhook's id
  6. Extract scan values — from fields[], match on the field_id defined in the seal step
  7. Extract the form_submit — from the matched run's steps, find the step with entity_type: "form_submits" and status: "done", take entity_ids[0], and look it up in form_submits[]
  8. Loop over form fields — for each field in form.fields[], resolve the canonical name via the mapping and build your output
  9. Extract image URLs — from uploads[], match on the upload IDs from the run steps
  10. Send downstream — database insert, EDI message, email, API call, etc.
7. Gotchas and Tips
  • entity_type lies. A seal step shows entity_type: "uploads" in the run step. Always look at workflow.steps[].type to know what a step actually is.
  • single_select values are inconsistent. Some are plain strings, some are JSON arrays. Always check and parse.
  • A file can have multiple workflow runs. Don't assume there's only one. Match on the webhook's id to find the right run.
  • Skipped steps have empty entity_ids. Check status: "done" before trying to look up data.
  • The fields[] array is flat. All scan/barcode values across all workflow runs on the file live in one top-level array. Use field_id to find the one you need.
  • GPS and location data are available on both uploads[] (per photo) and form_submits[] (per form submission). Use whichever is most relevant for your use