It's not really a rule, it's a strong suggestion. Understanding the reason behind the rule is what's important. When you have more than one trigger on one object, and those triggers each fire on the same DML event, you cannot be sure which order they will execute in, and further, side effects from one won't be necessarily be visible in the other, which can frustrate a developer when they realize their validations are not working correctly, or two different triggers update the same field, causing one of the values to be lost, etc.
It's also likely that different triggers might need the same data, so you'll end up wasting SOQL calls that could have been aggregated together, etc. In short, having more than one trigger fire per object can make an unpredictable mess of things very quickly. To avoid this mess, they recommend having one object per trigger. You can logically follow the flow of the trigger from one line to the next, and there won't be any unintentional surprises in behavior. Having code that flows predictably, instead of randomly, is always a good idea.
That said, having more than one trigger per object is entirely possible, if you're sure you avoid wasted DML operations, SOQL/SOSL operations, unintentional clobbering of data, missed validations, and so on. It's entirely reasonable to expand the rule to say "you can only have one trigger per DML event per object." This means that one trigger handles, say "before update", while another handles "after update."
Or, again, assuming you make the necessary effort to avoid governor limits and invalid data states, it's also perfectly reasonable to say "you can have one trigger per business rule," in your case, a trigger that calls the API stuff, and another trigger for everything else. So long as they don't share any queries, DML operations, updates, validations, or anything else, there's no problem doing this.
Just be aware that the code will flow in whatever order it feels like (e.g. the API call might happen first, or not). Since you have to end up calling API calls asynchronously anyways, it doesn't really matter here, just be aware that if anything does go wrong, debugging the situation might get more complicated. Do not make any assumptions about which trigger goes first, and do not rely on data that may or may not have already been set by the other trigger.
It's not impossible to use multiple triggers per object. However, it happens that it is much easier to screw something up subtly in ways that not even a unit test can properly test for, so for novice developers, the rule is do not do it, while the rule for a more experienced developer is do it with caution, and document everything carefully. As long as you have good documentation so that someone doesn't come along later and introduces operation-dependent behavior, you should be fine.