Publish external context on a workload

Publish a deployment or ticket summary, map it to a Solarius resource, and confirm the approved context reaches its destination.

Publish a customer-owned deployment or ticket record beside a mapped Infra or Guard resource. The external record preserves its own identity and source URL; the native product retains ownership of its configuration and findings.

Before you beginCopy link

You need the following grants, credentials, and tools:

• A custom connection has an active custom-to-native External context grant and a native-to-custom inventory grant for the target.
• Your worker has records:write for its integration and resources:read. An authorized mapping administrator can approve the resource relationship.
• Your integration host has curl, a trusted API endpoint, and its worker key in the process environment.

Configure the variables before sending the request:

Publish a deployment recordCopy link

1. On the integration host, save the following JSON as deployment.json:

   {
     "kind": "deployment",
     "name": "Store release 42",
     "url": "https://deploy.example.com/releases/store-42",
     "state": "active",
     "labels": { "service": "store" }
   }

2. Create the record through Create or replace an external record:

   curl --fail-with-body --silent --show-error --dump-header record-headers.txt \
     --request PUT \
     --header "Authorization: Bearer $CONNECTOR_API_KEY" \
     --header 'Accept: application/json' \
     --header 'Content-Type: application/json' \
     --header 'If-None-Match: *' \
     --header "Idempotency-Key: $CONNECTOR_REQUEST_ID" \
     --data-binary @deployment.json \
     "$CONNECTOR_API_URL/organizations/$CONNECTOR_ORGANIZATION_ID/integrations/$CONNECTOR_INTEGRATION_ID/records/store-42"

   The 201 response includes data.resource_key, data.revision, and the submitted record. record-headers.txt contains the ETag needed for later replacement.

3. Record the returned resource key. In Connector → Integrations → Integration → Records, confirm the external ID store-42, source URL, and accepted revision.

If creation returns 412, read the existing record before deciding whether to replace it. If the request times out, retry with the same request ID and payload. Changing the payload requires a different logical request and a fresh key.

Map and confirm the destination contextCopy link

1. In Connection → Resources → Add mapping, select the external record and intended native resource by their qualified keys.
2. Review both source identities and select Confirm mapping.
3. In Connection → Activity, select Synchronize. Follow its operation until Succeeded and inspect the source references.
4. In the native product's resource details, open Connector context. Confirm the deployment name, source link, record revision, and observation time.

If the record is absent, inspect the active External context direction and mapping before publishing another copy. A published record without a mapping does not appear on an arbitrary native resource.

Replace or retire the contextCopy link

Read the record for its current ETag. To change its state or summary, repeat the PUT with If-Match and a fresh idempotency key. Submit every required field; omitted labels become an empty object. A stale ETag returns 412 without replacing the record.

To retire the record, use Delete an external record with its ETag. Confirm it is absent from present context and review the stale mapping. Historical events remain under journal retention. A ticket record's resolved state does not close a Guard finding or incident.