This page follows one piece of work from the moment a Contributor submits it to the moment your API read returns it, and shows where to look when it does not arrive. Along the way it is submitted, accepted, delivered, authorized, and finally read by you; those are distinct states, and each of them can hold it up.
Use Campaign → Reviews → Review to inspect individual work. Configure the workflow and fields in Builder. Use an authorized API request for programmatic delivery.
Choose the delivered fields
An ETL step decides which fields an API consumer receives for each accepted record, and under which names. It changes nothing in the original SubmissionThe record created when work is submitted: Campaign → Reviews → Review still shows what the Contributor submitted.
- In the CampaignA developer's data-production project and its settings Builder, add an ETL step between Accept and Sink, then double-click it to open its panel.
- Under Delivered fields, each row reads one or more Form fields into one API field. Before you edit anything, the table only shows the default: saving now delivers every form field unchanged, including fields the form gains later. Your first edit turns the table into the list of delivered fields.
- To rename a field, type the new name in its API field — for example,
categoryin theanswerrow. To stop delivering a field, remove its row (×). A field the form collects but the list leaves out appears under Collected but not delivered: select Deliver it too to add it back, or turn on Also deliver form fields this mapping does not name to pass every unlisted field through under its own name. - Open a row's options (⌄) to set Required, which holds back a record that has no value, or a Default when empty. To read a second form field into the same API field, add it with + field: the two values are joined, unless you turn on Fallback, which takes the first one that has a value.
- Select Try a sample, type what a Contributor might submit, and compare Delivered shape with what your consumer expects. A blank sample field counts as not collected; while every field is blank, the preview shows each field's name instead of a value. The preview does not show everything delivery does: with Also deliver form fields this mapping does not name on, the record also carries every other field the Contributor filled, under its own name; and a record is held back, not delivered, when a Required row has no value and no default, or when a value is not listed while Hold the record back on a value that is not listed above is on — the preview still shows such a record.
- Select Save. Save stays unavailable while red text in the panel names a problem, such as a field without a name or two fields with the same name. Saving the step saves the Campaign's workflow; there is no separate canvas save. On a running Campaign, Save first asks you to confirm the change.
For this illustrative mapping, a Review showing answer: "fruit" corresponds to data.category: "fruit" in an eligible delivered record. If answer is empty, the sample preview omits category unless you set a default. Check the actual record in the API response before treating the preview as proof of delivery.
Reset to form fields lists every form field again, but as a list: a field the form gains later is not delivered unless Also deliver form fields this mapping does not name is on. Removing every row goes back to the default. Check each workflow branch separately.
Before changing a mapping already used by consumers, compare its output field names and missing-value rules with their expected schema. Test a new delivered record and check how historic records or exports behave for that Campaign; changing the mapping does not rewrite original Submissions or establish that older delivered records were backfilled.
Sink, subscription, and API
The accepted branch can connect directly to Sink or pass through ETL first. Sink stores workflow output; its JSON and CSV settings do not generate a downloadable file by themselves.
The API can return a submission only after it is accepted and the Contributor's reward is recorded. Even then, you see it only if your subscription and filters include it. A successful Sink save alone cannot prove that a subscription has readable records; the absence of a Sink alone cannot explain every empty API result.
For a particular Submission, follow this order:
| What you find | Check next |
|---|---|
| No accepted result in Campaign → Reviews → Review | Inspect the review outcome and feedback before investigating delivery. |
| Accepted, but reward grant is unknown | The Contributor can check that Submission's Activity or Awarded record. If you cannot see its reward state, ask support to check it by Submission ID. |
| Reward granted, but the small API read is empty | Confirm the same organization's Subscription ID, its scope, the selected mode and filters. If these match, ask support to trace delivery for that Submission. |
| API returns a record | Match its submission_id and data to the Review and agreed mapping before using it. |
| The records disagree, or you cannot locate the missing stage | Send the Campaign, Submission and Subscription IDs and the observed status to support. Keep API Keys and private submitted content out of the request. |
The API response establishes what this subscription actually returned.
Chain references and actual files
An on-chain anchor records identifiers, digests, and file references. Original files and metadata are usually held off-chain. A hash helps verify content consistency; a URI locates referenced content. Finding a chain record does not give you the original file or permission to use it, and does not establish that every file is encrypted or permanently stored. Continue with provenance and data rights.