Skip to main content
POST
Ingest timing data from a timing provider

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Body

application/json

One timing-inbound contract-v1 message: a timing provider reporting data (a bib number, a shipment, or both) for one LDT startlist entry.

schemaVersion
string
required

Contract schema version. Currently supported: "1.0".

messageId
string
required

Provider-generated unique id for this message — the idempotency and dead-letter correlation key.

Minimum string length: 1
provider
string
required

The timing provider code issued to you by Let's Do This. Must match the provider the bearer token was issued for.

Minimum string length: 1
ldtStartlistEntryId
string
required

The LDT startlist entry id the data applies to — the join key LDT sent outbound.

Minimum string length: 1
data
TimingInboundData · object
required

Timing data for one participant. Every field is optional here because a provider may report them in separate messages, but a message must carry at least one field this integration recognises — enforced in the handler, not in this type, because the index signature below leaves the generated JSON schema unable to express it. Unknown fields are still accepted and passed through to the timing pipeline untouched.

changedAt
string<date-time>
required

When the value changed at the provider (last-writer-wins ordering).

providerRef
TimingInboundProviderRef · object

Provider-native identifiers on a timing-inbound message — optional context that is not processed by Let's Do This today; safe to omit.

{key}
any

Response

Default Response

Acknowledgement that messages were received and queued — NOT yet applied; messages are applied asynchronously, and any per-record failure is reported separately rather than in this response.

received
number
required
messageIds
string[]
required