Engineering note · Technical support engineering · by Ayman Sbeiti — I support high-trust software platforms · Hiring?
Engineering playbook · TIL
The integration that rejects the whole request
Core principle
Some systems reject an entire request over one invalid field, and from the sender's point of view it looks like nothing happened. Design for that before wiring any two systems together.
Real-world example
Support escalations from Intercom were silently failing to create Jira tickets. A required attribute could arrive empty, and Jira rejected the entire request rather than accepting partial data. The automation looked successful from the sending side, and nothing surfaced the rejection anywhere we were looking.
Why it happens
Plenty of APIs validate strictly and reject atomically: the whole request dies over one field. From the sender's side that can look identical to success unless someone deliberately closed the loop. The dangerous combination is strict validation on one side and fire-and-forget on the other.
What I now check
- What does the receiver do with a partially valid request? Accept and flag, accept partially, or reject entirely. The answer changes the whole failure model.
- Where does a rejection go? If the answer is "into the receiver's logs," then from the sender's side the answer is "nowhere."
- What would a silent failure look like from where people actually work? If it looks like success, it will eventually be one — for weeks.
- Send a request with a required field deliberately empty, and watch what happens from the sender's side.
Production takeaway
If nothing visibly fails when a required field is deliberately empty, the integration has a silent failure mode. The time to fix that is before it carries anything that matters.