Odds Feed Timestamps: Measure Age, Not Just Response Time
An odds feed can answer a request in 40 milliseconds while returning a record that is several seconds old. Response time measures the request. Data age measures the information inside it. A useful integration keeps those concepts separate.
The first step is a timestamp dictionary: one short definition for every clock the provider exposes and every clock your own application records.
Identify what each timestamp describes
A source timestamp may represent when the upstream system created a record. A publication timestamp may describe when an intermediary released it. Your receipt timestamp records when your collector observed it. A response-generation timestamp can change even when the underlying information does not.
Those names are illustrative. Ask the supplier for the actual field meanings, precision and time zone. Never infer semantics from a field simply being called timestamp.
Work through a counterexample
Imagine a hypothetical record created at 12:00:00.000, published at 12:00:02.000 and received at 12:00:02.100. The publication-to-receipt interval is 100 milliseconds. The source-to-receipt interval is 2.1 seconds.
If a dashboard shows only the former, it conceals two seconds of upstream processing. If clocks are not synchronized, neither subtraction can be trusted as a precise latency measurement. Label the clock assumptions beside the number.
Decide which clock drives which feature
Use receipt time for collector activity and source time, when properly defined, for information age. Preserve publication time when it helps separate upstream and delivery delays.
For a public display, “last received” is honest when that is all you can measure. “Updated just now” can be misleading if it merely describes a fresh HTTP response carrying an old record.
- Is the connection active?: Useful evidence – Recent successful receipt
- Is the information advancing?: Useful evidence – Source version or meaningful update
- Where did delay accumulate?: Useful evidence – Comparable clocks at multiple stages
- Can we reconstruct the past?: Useful evidence – Stored timestamps and source identity
Handle units and missing values explicitly
Seconds and milliseconds since an epoch are easy to confuse. Validate expected ranges and reject implausible future dates. Preserve an absent timestamp as unknown rather than inserting the current time, which creates false freshness.
For textual interchange, RFC 3339 defines an Internet timestamp format. Using a recognizable format helps interoperability; it does not establish what an application-specific timestamp means.
Ask a better supplier question
Instead of asking only “How fast is your API?”, ask “Which timestamp represents the underlying observation, and how can we distinguish a heartbeat from a changed record?”
Review the sample data available through 7 Unicorn Gaming's live demonstration and confirm field semantics against its Odds API documentation. A timestamp dictionary is a small deliverable that prevents much larger disagreements about freshness later.