Mapping Workflow

It is necessary to maintain a Mapping Dictionary if there is no shared identifier already known to both Sportcast and the integrator. This dictionary is maintained by the integrator following this basic workflow:

Step 1: Entity Listing Sportcast provides the integrator with a list of entities for anything that needs to be mapped. This list can include: leagues, teams, fixtures and players. The entity list can be provided in Excel or a custom end point can be established where the entity list can be dynamically fetched. The message format can be customized but is typically just the entity name, sometimes an abbreviation/nickname and the Sportcast Id.

Step 2: Mapping

When a new fixture for a supported league enters the Sportcast system we push a message to a client endpoint with the details. This is the generic message format:

Multiple fixtures can be sent in one message. This message is the same response format as the GetFixtureList API which can be queried for disaster recovery, testing/development and service start-up.

The integrator maps the Sportcast entity to their own internal entity and maintains this dictionary for the lifecycle of the integration. Once a mapping is created it is preferred that the integrator share the mapping information with Sportcast. Typically this is done by posting a simple message containing both the SportcastId and the integrator's mapped Id to a custom HTTPS end point.

A typical mapping message would be as follows, with the ConsumerFixtureId being the client identifier and FixtureId being the Sportcast identifier:

Using this information, Sportcast adds the mapping to the Sportcast database so that mappings are now maintained by both parties.

Step 3: Exposing the Mapped Ids Once Sportcast has knowledge of the mapped entity Ids, we will provide these Ids in all appropriate messages and APIs used by the integrator.