API orchestration for a B2B platform

Three calls can look parallel on a diagram and still publish the wrong row. A desk fetched a listing, wrote a local copy, and only then asked whether the listing was still offered. The answer came back withdrawn. The public page had already taken the local copy. Write the calls as a timetable before drawing them as arrows.

The timetable

1. Ask the provider for the listing, and wait. Without a listing there is nothing to store.
2. Ask whether the listing is still offered, and wait. A withdrawn listing stays off the public list.
3. Write the local copy and the public list. This step runs after the first two answers are in.

A fourth concern may lag. An announcement email can be queued after the public list is written. The email is outside the decision to publish. If the email is late, the list is still right, and the timetable says so. A later edit that publishes beside the offer-check has to cross that sentence first.

A call may be retried when the failure is a timeout, or a response that says the provider is busy. Retry that call twice, with a pause, and then stop. A response that says the listing is unknown is a finished answer. Record it once.

This order is the automation. The timetable can run without a person clicking through it. A person still owns the exceptions.

When the write fails

If the local write fails after the provider has said the listing is offered, the public list stays as it was. The desk stores a row: the provider identifier, the time of the attempt, and the sentence “Local write failed. Public list unchanged.” A person closes that row by confirming a fresh write, or by withholding the listing, and by looking at the public page either way.

Tests

The timetable can be exercised without the live provider. A stand-in answers the same noun from How multi-provider API integrations work: a listing identity, a display name, a time, and a status of offered or withdrawn, or a busy failure.

• An offered listing produces a public row.
• A withdrawn listing produces no public row and no email.
• A busy failure twice, then offered, produces the two retries and then the row.
• A busy failure three times produces the exception row, and the public list stays as it was.

After the stand-in is dull, run one joined pass against a test desk the provider has agreed to open, with a listing the provider will create and then withdraw. That pass may be slow. It catches a noun that has drifted. The four stand-in cases catch a timetable that publishes too early. Keep both, because they catch different failures.

Why the arrows lie

A diagram with three arrows leaving one box looks like three calls at once. The desk that fetched, wrote, and only then asked whether the listing was offered had that diagram. The public page took the local copy. The withdrawn answer arrived into a page that had already moved. The timetable is the sentence that forbids that order. Draw the arrows only after the sentence exists, and draw them in the order the sentence waits.

The email is the call that may lag. It is queued after the public list is written. A late email does not roll the list back. A failed email does not mean the listing was withdrawn. The timetable says the email is outside the decision to publish. A later edit that sends the email beside the offer-check has to cross that sentence first, in the file, not in a meeting.

Retry, then stop

Retry a call when the failure is a timeout, or a response that says the provider is busy. Retry that call twice, with a pause, and then stop. This publication’s example uses two retries. It is not a number a specification demands. Write the number next to the timetable so the next person does not “improve” it to ten and hide a provider that is down.

A response that says the listing is unknown is a finished answer. Record it once. Retrying an unknown listing turns a clear no into a slow no, and it can publish on a later try if someone confuses “unknown” with “busy.”

Close the exception in public

The failed write stores the provider identifier, the time of the attempt, and the sentence “Local write failed. Public list unchanged.” Closing that row is two looks, not one click. Confirm a fresh write, or withhold the listing. Then look at the public page. The row is not closed because the log says closed. It is closed because the public page matches the decision.

A person owns that close. The timetable can run the happy path without them. It should not invent a public row to make the exception disappear.

The stand-in and the joined pass

The stand-in answers the noun from How multi-provider API integrations work: identity, display name, time, and a status of offered or withdrawn, or a busy failure. The four cases are listed above. They will not notice that the provider renamed a field. The joined pass will. Keep the joined pass rare and real: one listing created, then withdrawn, on a desk the provider agreed to open. A pass that only hits the live provider, with no stand-in, will be too slow to catch a timetable that publishes on step two. A stand-in with no joined pass will stay green while the noun drifts.

Step two is where the lie shows

Draw the timetable as a list of steps, not as a picture of arrows. Arrows curve, and a curve hides which step publishes. Number them. Step one reads the provider. Step two writes the local row. Step three makes the row public, and only if step two recorded an offered listing that step one did not mark withdrawn. If your picture has a single arrow from “provider” to “public,” you have hidden step two. That is the arrow that lies. Split it until a withdrawn listing has a step where it stops.

Read the numbered list aloud. If you cannot say where a withdrawn listing exits, the list is not finished. The exit is a recorded decision, not a missing arrow. “We just don’t draw that case” means the case falls through to public. Draw the exit.

A failed local write stays off the public list

When step two fails, step three does not run. The public list is unchanged. The failure record stores the provider identifier, the time, and the sentence “Local write failed. Public list unchanged.” A person closes that record by looking at two places: a fresh write that succeeded, or a decision to withhold, and then the public page. The log saying closed is not the close. The public page matching the decision is the close.

Do not publish a placeholder row “so the list isn’t empty” while the write is broken. An empty gap where a listing should be is more honest than a public row the provider has not confirmed. The empty gap can carry the failure sentence on the desk. It does not carry a fabricated offered status.

Retry belongs only on a timeout or a response that says the provider is busy. This publication’s example retries twice and stops. Two is the example’s mark, written next to the timetable, not a number a specification demands. An unknown listing is not busy. It is a finished no. Record it once. A later retry that treats unknown as busy can publish on a second try if someone maps unknown into the busy path by mistake. Keep the paths separate in the numbered list.

The stand-in answers the paper

The stand-in does not impersonate a whole company. It answers the noun: identity, display name, time, and offered or withdrawn, plus a busy failure and an unknown. Those are the cases the numbered list mentions. If the list gains a case, the stand-in gains that answer, in the same edit. A stand-in that only returns offered will stay green while step three publishes a withdrawn listing. That stand-in is a painting of the happy arrow.

Run the stand-in on every change to the list. Run the joined pass rarely: one listing created, then withdrawn, on a desk the provider agreed to open. The joined pass is how you notice the provider renamed a field. The stand-in will not notice that, because the stand-in speaks your noun, not their new key. A week that only hits the live provider will be too slow to catch a timetable that publishes on step two. A week that only hits the stand-in will stay green while the noun drifts. You need both, at different tempos.

The sentence on the exception

The public sentence for a failed step is dull on purpose. “Local write failed. Public list unchanged.” It does not say the provider is down if you do not know that. It does not say the listing was withdrawn if the failure was a local write. The status words from the noun stay accurate. A sloppy sentence that calls every failure “withdrawn” will teach the next edit to treat them as one path.

A person owns the close. The timetable may run the happy path without them. It may not invent a public row to make the exception disappear before they look. Write their name, or the role, next to step three’s exception, so the numbered list shows the human step as a step and not as a footnote under the arrows.