# Why API 2 mode
**URL:** https://forums.digi.com/t/why-api-2-mode/1479
**Category:** XBee - 802.15.4
**Created:** [March 5, 2010, 7:16am UTC](https://forums.digi.com/t/why-api-2-mode/1479 "2010-03-05T07:16:12Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@SkyMoCo](https://forums.digi.com/u/SkyMoCo)
#### Post date: [March 5, 2010, 7:16am UTC](https://forums.digi.com/t/why-api-2-mode/1479/1 "2010-03-05T07:16:12Z")
Maybe I’m missing something, but why would you want to use API-2 mode over API-1 mode. Is it for the case where the serial devices that talk to the XBee modules use XON-XOFF and you cannot just have them use hardware flow control. But the XBee doesn’t support XON-XOFF, is this just using the least common denominator approach. Basically, with API-2 mode the XBee will talk to just about anything?
Just wondering. I’ve had pretty good luck with getting a couple basic stamps to talk to each using XBee’s and to a central computer running linux with an XBee attached to it. I’ve always used API-2 mode but I really cannot say exactly why other than that is what the java api mode I found for the linux end of thing supports.
---
### Author:  [@johnf](https://forums.digi.com/u/johnf)
#### Post date: [March 5, 2010, 9:28am UTC](https://forums.digi.com/t/why-api-2-mode/1479/2 "2010-03-05T09:28:44Z")
Your idea is right: hardware flow control is between each XBee and its host, whereas XON/XOFF is between the two hosts. XBees don’t take any special notice of XON/XOFF characters but API mode 2 is provided so that XON and XOFF can be transmitted from host to host without misinterpretation.
If you’re not using XON/XOFF then you don’t need API mode 2 (though it does no harm). Well, there’s one exception there: because the 0x7e character is also escaped when it happens inside a packet, API mode 2 does also make it easier to synchronize to the start of the next packet when things go wrong.
(Next time I reissue the cookbook you’ll find an added section on this.)