Skip to main content

Send another JSON data type

In this tutorial, you will use Bash and curl to send a simulated checklist as a registered experimental data type. Unlike ISO 19848, this workflow does not require a DataChannelList: the payload follows the registered type's contract.

Customer-test environment

This tutorial uses the customer-test environment. Both the base URL and the API key must be for customer test; a production key is not interchangeable with a customer-test key. The experimental data type must also exist in customer test.

Before you start

You need Bash, a text editor, curl 7.76 or newer, and a customer-test ingest API key for the customer + data provider connection you will use.

  • Sending on your own behalf: you are both customer and data provider and typically use one API key per environment.
  • Providing data for customers: keep each customer's API key in secure storage. Select the customer-test key for the customer whose data you are sending in this exercise. Never share one key across customers.

The key is not scoped to assets or data types. You can use the same customer's connection as in the ISO 19848 tutorial; a different data type does not require a new key. See authentication for the full boundary.

Separately, ask your DNV representative for an experimental data type and version in customer test that accepts the checklist payload below. This is an illustrative contract, not a built-in data type. Have the type registered before running the tutorial; posting JSON does not register a type.

Choose a test asset for the selected customer. Do not submit the simulated checklist to production or an operational asset.

1. Configure your environment

Replace the placeholders with the selected connection's customer-test key, the registered experimental data type and version, and your test asset ID:

export VISTA_GATEWAY_URL='https://vista-gateway-customer-test-api.dnv.com'
export VISTA_GATEWAY_API_KEY='<customer-test-api-key-for-this-connection>'
export VISTA_DATA_TYPE='<registered-experimental-data-type>'
export VISTA_TYPE_VERSION='<registered-version>'
export VISTA_ASSET_ID='<test-asset-id-for-this-customer>'

Keep this shell open for the remaining steps. Treat shell history containing real keys as sensitive; do not enable shell tracing (set -x) or verbose HTTP logging with credentials. URL-encode path segments and query values if they contain reserved characters.

2. Create the checklist

Save the following as checklist.json:

{
"checklistId": "tutorial-checklist-001",
"completedAt": "2026-01-01T12:00:00Z",
"items": [
{
"name": "Emergency exit clear",
"passed": true
},
{
"name": "Safety signage visible",
"passed": true
}
]
}

The document contains two simulated checks. The asset ID will be supplied in the request URL, not in an ISO 19848 header. Field names and value types come from the registered contract; this example does not define a universal checklist format.

3. Send the checklist

Run:

curl --fail-with-body --silent --show-error --include \
--request POST "${VISTA_GATEWAY_URL}/experimental/${VISTA_DATA_TYPE}/${VISTA_ASSET_ID}?typeVersion=${VISTA_TYPE_VERSION}" \
--header "Authorization: ApiKey ${VISTA_GATEWAY_API_KEY}" \
--header 'Content-Type: application/json' \
--header 'User-Agent: GatewayTutorial/1.0' \
--header 'X-Package-External-Id: tutorial-checklist-001' \
--header 'X-Package-Correlation-Id: tutorial-checklist-run-001' \
--data-binary @checklist.json

Check for HTTP status 200 and a response body containing packageId:

{
"packageId": "11111111-1111-4111-8111-111111111111"
}

Your ID will be different. Record the actual ID with your checklist reference. If the request fails, check that the type and version are registered as experimental in customer test and that the payload matches their contract. Use troubleshooting for other errors.

You have submitted a non-ISO JSON package. Acceptance does not confirm downstream processing, and resending can create another package. To integrate your own data format, follow Ingest other data types.