Section
Integrations
These pieces connect systems. One is a multi-provider API integration. One is orchestration, automation, and the tests around them. One is the session a platform keeps when it opens a title from a provider, including a provider of playable titles.
The noun comes first. The timetable moves that noun, and it refuses to publish a listing the provider has withdrawn. The session piece starts when the platform opens a title that lives somewhere else, and it stores a clock instead of a folder of files.
Noun, then calls, then a clock
Open the listing piece first. Two providers are not two shapes. They share one noun: an identity, a display name, a time, and a status. Match on the provider’s stable identifier, then rename into that noun. A second provider enters the same shape even when its field is called something else on the wire. Staff notes and announcement text are other nouns. They can be joined later, by the listing identity, when someone has a reason to show them. Pulling them in on the first import makes every extra field look required.
You can check the noun without a live call. Take one listing the provider has already described on paper. Write the desk’s row by hand. Change only the display name and write the row again. You should still be pointing at one desk row. Change the identifier and you should be pointing at a second row, even if the display name matches. Those two results are the integration. The timetable comes after the noun is this dull.
The timetable piece orders the calls. A listing the provider has withdrawn is not published. A local write that fails does not become a public row to hide the exception. The public page is checked after the decision, not instead of it. Retry a timeout or a busy response, then stop. This publication’s example uses two retries. That number is an example, not a figure a specification demands. An unknown listing is a finished answer and is recorded once.
The session piece starts when a person opens a title the catalog already decided to show. The platform stores a start, an idle limit, an end, and the reason the session stopped. It stores the provider id and the title id. It does not store the score, the progress, or the title’s own rules. Those stay with the provider. The earlier of the handle’s expiry and the platform’s idle limit ends the session. A later visit is a new ask. Resume, in the failure this plate retires, was a folder of files with a dead handle.
Read them in that order: noun, calls, clock. The clock is meaningless if the noun is still two shapes, and the calls are meaningless if a withdrawn listing can still go public. The section lists all three. It does not replay them.
How multi-provider API integrations workAgree on one listing noun, match a stable identifier, and map each new provider into that noun instead of inventing a second shape.
API orchestration for a B2B platformOrder provider calls so a withdrawn listing cannot publish, record a failed write, and test the timetable with a stand-in.
Session architecture for a multi-provider platformStore a session as a start, an idle limit, an end, and the provider and title ids. Leave the title’s own rules with the provider.