Skip to main content

Follow Accepted Data to Ready Results

Before you start​

Use your tenant login and keep the receipt UUID returned by a successful ingest request. For CLI examples, replace client with your authenticated profile and the UUID placeholders with identifiers returned for your tenant.

Follow one event​

  1. Open Get started (/onboarding) to read the saved bootstrap state and its next action. Returning after login resumes the same durable setup.

  2. Send a small valid batch using Send events. Check every result, not just HTTP acceptance.

  3. Open Ready data (/ready-data). Under Readiness doctor, enter the Receipt UUID and select Check receipt. Keep its coverage and next action with the receipt. custdctl onboarding doctor --profile client checks bootstrap state; it does not accept a receipt UUID.

  4. Select a prepared output whose state permits querying. The CLI can list and inspect the same outputs:

    custdctl prepared-data catalog --profile client
    custdctl prepared-data get --profile client --output-uuid <output-uuid>

For example, follow the receipt from your first test event until it changes from accepted/processing to ready, then inspect its output's coverage and watermark. Expected result: a ready output with provenance, or an explicit warning and next action. HTTP acceptance alone does not prove query readiness.

Recover without losing the trail​

Follow the returned recovery action: wait at least pollAfterSeconds for poll, respect maxRetries for retry, and retain the same receipt/output identifiers. For rotate, use your credential lifecycle. For escalate, provide the request ID and redacted warning codes to support. Do not include credentials or payloads.

Partial/stale values remain usable only with their warnings visible. Wrong-tenant and absent identifiers both return not found. Check your tenant and the copied identifier rather than probing other tenants.