The questions behind a dependable data connection.

Describe what the source actually delivers.

Start with a representative file or payload and the system that produces it. Does the source create a new file for each interval, append rows to one file, expose a provider feed, or require a custom client to fetch an API? Who controls its credentials and format? How are corrections and historical records made available? These details are more useful than a vendor name alone.

List the instrument identifier, channel names, timestamp format, timezone, numeric types, and missing-value markers. Check whether one message contains one instrument or several, and whether a source field is a measurement or a status string. A sample that includes ordinary irregularities is more valuable than a perfectly cleaned example.

• ↳Identity: stable instrument and channel names.
• ↳Time: collection timestamp, timezone, and expected cadence.
• ↳Values: type, unit, missing-data convention, and correction behavior.

Match the route to that behavior.

Use an FTP pipeline when the source already delivers delimited files to a remote location. The pipeline can watch new files in a folder or new rows in a file, with a parser that defines the mapping. Use the Affinity integration for supported provider inventory and readings, reviewing the discovered profiles and the project's granted sites.

Use the Ingestion API when your gateway or integration controls delivery. A custom integration can fetch another vendor's API and submit readings in SanSignal's format. That route gives you a way to connect other systems, but its authentication, mapping, scheduling, and error handling still need to be implemented and operated.

Verify meaning as well as transport.

Compare a known source reading with the destination instrument after processing. Check the identifier, exact time, channel, value, and unit. A timezone shift can produce an apparently missing reading in one view and an unexpected reading in another. A text value that should be numeric can prevent the calculation or comparison you intended.

For FTP, inspect the parser preview and its diagnostics against representative rows. For provider mappings, review the catalog proposal. For API delivery, retain request and run IDs, then follow the result. Admission is asynchronous: the API response is one step in the path, not confirmation that the final value and its calculations are ready.

Make retries and recovery deliberate.

A network interruption can make a sender uncertain whether its batch was accepted. The Ingestion API uses an idempotency key to identify the same logical batch. Retry an unchanged batch with the same connection and key; give new or changed batches new keys. Reusing a key for a different payload can replay the earlier admission instead of importing the change.

Keep enough local context to connect delivery attempts to processing runs. Establish who reviews failed mappings, rejected rows, and source gaps, and verify the affected period after recovery. Connection health, source activity, and stored readings are complementary evidence. Together they help an operator distinguish transport trouble from a data or calculation issue.