Important - Sunsetting Connect API v1

Hey @api,

As of today, v1 of the Connect API is now considered deprecated and will be removed in our next update in January 2023 (23.1).

This API was introduced way back in 2015 and has been an easy way to interact with Infinite Flight from third-party apps.

As we continue developing Infinite Flight and reworking key systems, we’re moving away from the system that Connect API v1 relies on internally. We’re replacing it with our state system exposed via Connect v2.

Next steps

  • If your app uses v1 of the Connect API, you will need to upgrade to v2 of the Connect API by early January.

  • v2 gives you access to every state in Infinite Flight and allows you to carry out most of the same functionality as v1. If you are missing any specific feature, please let us know in a reply to this topic.


Full documentation is available on our website thanks to contributions from @likeablegeek and @tomthetank:

State Explorer

Our website also allows you to explore all available states for specific aircraft to help with development:



Thanks to the awesome contributors below for creating libraries to interact with the Connect API v2. These are great starting points for any v2 app:

Questions or API requests?

Let us know below. Thanks!


Does that mean it’s not coming on then?

1 Like

v1 to v2 migration request

In Connect v1 we had the Live.GetTraffic endpoint to get information about surrounding traffic, however in v2 there is no such endpoint available.

Trello Link: Trello

Just a note that in v1 V/S was broken for traffic


So if anyone needs me, I’ll just be crying over here in the corner, then… 😭

(just kidding, I understand why you’re doing it…I just hope I get the In-Flight apps migrated over by then…)


We believe in you :)

It’ll be a good step forward for the long run, lots more possibilities with the new Connect API


Migration request: The v1 API had an is_stalling endpoint that the v2 API lacks. Could this be added to v2?


Kai asked me to update my requests in regards to this project:

  • migrate Live.GetTraffic() type method or equivalent
  • ability to receive pilot comms as ATC through API
  • ability to send ATC commands

I’m perpetually writing and re-writing the project to be more elegant(my graphical skills currently leave a lot to be desired), so no worries as to how long these would actually take. Thanks Cam/Kai & Co.!


Thanks for noting them here! I’m not sure we’ll be able to do ATC commands at this time, but we’ll look into it at some point when it works with the multiplayer changes we’re making

1 Like

So…here’s a collection of things that were in v1, but that I’m not finding (yet), that would be important for me to have in v2 in order to migrate In-Flight Assistant on over to v2.

Note that a couple of these I’ve talked with @Cameron about, but it’s possible some of them are already possible, I’m just not knowing where to look.

  • AccelerationZ (physical acceleration forward), there was also AccelerationX and Y but I don’t need those, myself. I do use this one.
  • IsPushbackActive - whether pushback is…ya know
  • Weight - the total weight of the aircraft, I use this for finding v-speeds. I realize I can iterate through all the tanks and all the cargo etc. but it’d sure be nice to still just have one single value to fetch
  • ApproachRunway - the name of the runway we are currently approaching. I use this for RAAS.
  • the command Camera.VirtualCockpit.SetViewAngle - I used this for shaky cam. I suppose I can use the OpenTrack API for this? But according to the API page, this is down and coming back in a future version?
  • Camera.VirtualCockpit.GetViewAngle - this gave me the virtual cockpit view angle, same as the point above, it was a JSON with a simple X and Y parameter
  • Camera.VirtualCockpit.ResetViewAngle - this reset the view angle once shaky cam was done
  • AppState told me whether I was in the MainMenu, or Playing
  • PlayMode told me whether I was in Record (normal I think?) or Replay mode
  • FlightPlanItems used to be a part of the JSON I got when I requested flightplan.get. I use this for the VNAV feature in IF-A. Looking at the API I currently see these, but that’s not the same thing as the whole list of waypoints.

  • I used to get a Fds.IFAPI.APINearestAirportsResponse when I ran InfiniteFlight.GetNearestAirports, this gave me a JSON with a list of Airports and Runways - I use this for RAAS as well.

Boy, do I have some work cut out for me if I’m going to get the IF apps moved over to v2. 😬

1 Like

AccelerationZ we don’t have (though we do have gforce_x and _y), there aren’t any endpoints for pushback except for the command (which just toggles if the tug is attached), weight would be super nice to have, and I don’t believe there’s an analogous endpoint for approach runway.

For the rest:

You can use infiniteflight/cameras/1/x_angle if you know the number of the camera you’d like to set. You may need to set infiniteflight/cameras/1/angle_override to true as well.

Getting infiniteflight/cameras/1/x_angle should work for this.

Depending on your use case, you can either set infiniteflight/cameras/1/x_angle to 0 (or what ever default you like), set angle override to false, or use commands/reset. Let me know if you need more detail and I can explore.

infiniteflight/app_state :) This might also work for PlayMode? Unsure but worth exploring.

There’s definitely an endpoint for this. Check out aircraft/0/flightplan/route and maybe aircraft/0/flightplan/full_info’s detailedInfo field. I can look closer later…

infiniteflight/nearest_airports :)


Hack suggestion: We have aircraft/0/headwind_component and airspeed_change_rate. Might be easier to just beg for a new endpoint though.


Again (as already done in Discord), thanks so much for this, Tom. Most of these are working great.

I tried this but it the camera smoothly moves to that position, which is not what I need for the shaky cam feature. The old API used to immediately move.

1 Like

Thanks to @tomthetank’s help, I’m about 85% of the way there with In-Flight Assistant on iOS! 🥳

Christmas Wishes 🙂

  • If at all possible, the ability to fetch values by string key instead of ID - without having to fetch that manifest thingy first (still not really sure what that thing is even FOR) - if a value can’t be fetched right now (e.g. because the user’s in the menu or whatever), then just return an error message or something! What good is the manifest & id system for? 😬 I keep having to request it because it might change if the user leaves the flight and comes back or whatever!
  • An API for fetching multiple values with a single request instead of having to send gazillions of requests
  • Missing API keys:
    • there’s no more “IsPushBackActive” (or whatever)
    • also no more “acceleration_x/y/z” to measure g-forces (the velocity_x/y/z is in global space, not local)
    • also no more just straight-up “weight” for getting the total weight (for total I’d currently have to iterate through all fuel tanks and stuff)…

Gotta echo the sentiment on the manifest. It seems to create far too much variation in the API, which is a nightmare to develop for.

From a high level philosophy point of view, APIs really need to remain consistent (within the same version of course), if an API request that worked a moment ago is expected to fail due to user action there really ought to be some notice to the application when it does so, or even better (not sure how this would work) an event emitter. Without this it makes it impossible to use reliably, I’d be happy to debate this topic.

1 Like

Already put my thoughts in the discord but they’re characteristically a bit all over the place so thought best to write them consolidated here where they can be discussed a bit more formally

Look, I’m a bit unhappy with how this is all being handled. Firstly it’s announced 1-2 months prior to the removal, which is right when there are Christmas/New Years holidays so IF developers cannot realistically be asked to implement all the stuff that is missing from v2 prior to the v1 removal date.

This means that whole projects which are centred around v1 features (my TCAS project for example) will now have to go on hold until it’s implemented in v2.

I really wish this were done either over a longer time span, or at a different time when there isn’t a major holiday. I understand and respect from speaking to @KaiM that this is a necessary step in project metal, but this doesn’t seem very well planned out.

Not trying to have a go at any one individual nor IF at large, I’d just like to see some changes made to this transition.


Thanks for your feedback. The goal of the topic is partly to help us find any breaking/missing changes that are important for the few apps still using Connect v1.

We don’t want to leave third-party devs in limbo, but unfortunately maintaining Connect v1 isn’t something we can do in the long-term anymore as we keep making overhauls to our codebase.

We’re happy to help find a middle ground for your project if you can note specifics that you need, and can make sure they are implemented + made available to you with plenty of time :)


Thanks for the feedback - to answer the question, primarily, it’s for internal performance. It’s an index-based lookup internally which becomes important for our implementation as multiple states are accessed frequently. We’re exposing our internal state system for maximum flexibility here (so any new states we add become available).

It’s also important as not every sim state will have the same states as you noted. In these cases, it’s fine to request the manifest multiple times.


How do we detect pushback as there doesn’t appear to be any State listed for it:

We’re working on it. We’ll be in touch with everyone in the new year to help sort you all out with pre-release versions with the updated v2 API.

1 Like

The UDP broadcast includes info on the port, this appears to be hardcoded to 10111 even though connect v2 uses 10112. Not wildly important, but as long as we’re pointing out errors I thought I’d note it.