Configure and verify deliveries

Use an ADMIN identity to configure and trigger delivery. Golden supports HTTP, Kafka, JDBC and Golden-table destinations. A completed synchronization and a completed downstream delivery are separate outcomes.

Prepare the destination

1. Choose the destination type, its dataset and credentials.
2. Use a test receiver and a small, disposable entity while validating the flow.
3. Configure any required transformation.
4. Test the destination resource. HTTP, JDBC and Kafka tests check connectivity and preview payloads without sending the selected records as real deliveries.
5. Attach the destination to the entity, preserving its other configuration.

A resource test can contact the configured system. Its success does not replace verification of a real delivered record. Aurelia’s example destinations are illustrative and unattached; configure a receiver you control before using them.

Deliver the current records

Set ENTITY_ID to the disposable entity. This request delivers its current full set without loading or reindexing:

jq -n --arg id "$ENTITY_ID" \
  '{id:$id,loadMask:"NONE",indexClassificationMask:"NONE",sinkMask:"FULL"}' |
curl --fail-with-body --silent --show-error --request PUT \
  -H "Authorization: Bearer $GOLDEN_ADMIN_TOKEN" \
  -H "Content-Type: application/json" --data-binary @- \
  "$GOLDEN_URL/api/entities/synchronize" > delivery-response.json
RUN_ID=$(jq -er '.run.id' delivery-response.json)

Read GET /api/jobs/runs/{RUN_ID} until the run finishes. A full delivery can send records the receiver has seen before. Define how the receiver handles repeated identity and operations before enabling it.

Verify at the receiver

Compare expected and received record counts, _id, business fields and provenance. Check insert, update and deletion semantics for the selected protocol. Inspect destination events as well as the run: pending delivery may continue after the synchronization has completed.

Enable recurring work only after both Golden and the receiver show the intended result. Remove the disposable flow and its resources after the test.

Recover a pending or failed delivery

Use task and event recovery to inspect the destination, resolve the cause, and revalidate failed events. A timeout can leave the result ambiguous: check the receiver before replaying. Do not clear pending events as a substitute for correcting the delivery failure.

Export a downloadable file instead

POST /api/tables/export produces data files in Golden; it does not send to an entity destination. With TABLE_ID set to a table you may export:

jq -n --arg source "$TABLE_ID" \
  '{source:$source,chunkRecords:0,maxRecords:6,sampleRecords:-1}' |
curl --fail-with-body --silent --show-error \
  -H "Authorization: Bearer $GOLDEN_ADMIN_TOKEN" \
  -H "Content-Type: application/json" --data-binary @- \
  "$GOLDEN_URL/api/tables/export" > export-response.json

Follow run.id, find the resulting export in Files, verify its source and creation time, and download it through /api/files/download/{fileId}. chunkRecords:0 requests no chunking. Remove the test export after checking it. Table-definition exchange through /api/tables/extract is a different operation and does not export the table’s business records.