Capture and Inspect Logs
Capture the application facts that explain a behavior question. Keep the original records until their admission is known.
Prerequisites
- The intended workspace, Project and Fieldloop source.
- Authorization to submit to that destination.
- Actual captured content and stable application event identities.
- Explicit source processing consent where screening is enabled.
Submit captured records
Use the source's supported submission path with the configured destination. Application-library calls can submit batches and inspect receipts without installing a CLI or signing in through a browser.
Follow the Python, TypeScript or Go quickstart for a complete batch example, or use the Fieldloop REST guide.
Provide a Fieldloop submission credential through your application's approved secret mechanism. A newly created Fieldloop key grants that capability across its workspace; the sender still identifies the Project and source. Existing more restricted keys keep their restrictions.
Preserve the exact batch content and idempotency key when recovering an uncertain request. A successful admission does not mean every row has completed processing.
Inspect Logs
Open Logs, choose the intended time range and source, then inspect the original record, relationships and processing state. Captured messages, context, trajectories and feedback remain distinct fields rather than a synthesized replacement for what happened.
Read receipt counts for accepted, duplicate, conflicting and rejected rows. A processed batch can still contain row-level outcomes that need attention.
Object and state changes
Submission records durable intake and admits processing work. Processing publishes the captured log and its attributable snapshot. Further analysis can create or update Threads separately.
SDK buffering can acknowledge memory before server admission. It is not a disk outbox or a guarantee of crash delivery. Caller-owned cancellation and recovery should preserve the exact source records and batch identity.
Success criteria
- Records reached the intended Project and source.
- Original content and event identities are preserved.
- Admission and processing outcomes are understood separately.
- Credentials do not appear in logs, reports or copied tasks.
Common failure modes
- Using a key for another workspace.
- Re-encoding changed content under the same retry identity.
- Treating receipt polling as a new submission.
- Assuming a captured record was analyzed without source consent.
- Treating temporary client buffering as durable admission.