The four questions your integration platform should answer at 3 a.m.
When a partner says "we never got it", the answer should take seconds, not a log search across five systems. Four questions worth testing your integration layer against.
Integration platforms are bought on features and judged at 3 a.m.
At that hour nobody cares how many connectors the brochure listed. Someone is awake because a partner says an order never arrived, and the only thing that matters is how quickly a person who did not build the flow can find out what happened.
These are the four questions that decide it. They are worth asking of whatever you run today, Bitween or not.
1. Where is this message?
A partner gives you an order number, not a message id. If finding it means grepping logs across five services, the answer takes an hour.
The fix is to index messages by the business keys people actually quote. In Bitween, each information type declares promoted properties: named paths into the payload, such as order.id or a tracking number. Every exchange has those values extracted and stored when it arrives, so an order number typed into a search box finds the message, whatever system it came from.
Two more things make the difference at 3 a.m.:
A correlation id shared by everything in one flow, so a request and the exchange created from its response come back in one search.
Filters in the URL, so the view you found can be pasted into a chat and the next person sees exactly what you saw.
2. Why did it fail, and what did we actually send?
"It failed" is not an answer. The question behind the question is whose fault it is, and the only way to settle that is to keep the evidence.
Every Bitween exchange keeps up to three files: the input that arrived, the output the mapper produced, and the response that came back. With those side by side, the conversation with a partner stops being a disagreement about what was sent.
A message you cannot show is a message you cannot defend.
Worth knowing: payload files expire on the storage lifecycle you configure, 30 days by default, while the exchange records themselves stay. Decide that retention deliberately, because it is the window in which you can prove what you sent.
3. What happens next, and is it already handled?
The worst state is ambiguity: does someone need to act, or is the system retrying?
That should be a property of the platform, not folklore. In Bitween a retry policy decides per failure, and the exchange records what it decided and why:
{
"name": "Transient network errors",
"appliesTo": ["Error"],
"matchers": [
{ "type": "exceptionType", "value": "HttpRequestException" },
{ "type": "contains", "value": "503:" }
],
"action": "Allow",
"budget": {
"maxAttemptsPerError": 5,
"maxAttemptsTotal": 500,
"delayStrategy": { "type": "exponential", "initialDelayMs": 30000, "multiplier": 2, "maxDelayMs": 1800000 }
}
}
Three parts matter more than the syntax:
Match precisely. A 503 from a partner is worth retrying. A 400 that says "invalid tax id" never is, and retrying it just multiplies the noise.
Cap twice. Once per message, so one poisoned document cannot loop, and once across the subscription, so an outage cannot turn into thousands of calls against a partner already on the floor.
Alert once. When a shared budget runs out, one alert goes to the people who can act, instead of one per failure.
The person woken at 3 a.m. then reads a sentence rather than a guess: retry two of five, next attempt in four minutes, or blocked because the group said so.
4. Who changed this, and when?
Most "sudden" integration failures are not sudden. Someone changed an endpoint, a mapping, a credential or a retry rule, and the change and the failure are hours apart.
An audit trail that records the old and new value of every property, written in the same transaction as the change, turns that from an argument into a lookup. Bitween's cannot be edited or deleted through the API, which is the point: the record is useful only if nobody can quietly fix it afterwards.
The test
Take one real flow, and time yourself:
Find yesterday's message by the number your partner would quote.
Show what was sent and what came back.
Say whether it will be retried, and when it stops.
Name the last person who changed that flow.
If all four take under a minute, your integration layer is doing its job. If any of them needs a developer, that is the gap worth closing first, whatever you close it with.