This is a Node.js port of SteamKit2. It lets you interface with Steam without running an actual Steam client. Could be used to run an autonomous chat/trade bot.
npm install steam
Note: when installing from git, you have to additionally run
npm install inside
steam/node_modules/steam-resources to run the
prepublish script (see npm/npm#3055). It pulls Steam resources (Protobufs and SteamLanguage) from SteamKit2 and requires
Note: only Node.js v4.1.1 and above is supported.
require this module.
var Steam = ;
Steam is now a namespace object containing:
Then you'll want to create an instance of SteamClient and any handlers you need, call SteamClient#connect and assign event listeners.
var steamClient = ;var steamUser = steamClient;steamClient;steamClient;steamClient;
See example.js for the usage of some of the available API.
Steam.servers contains the list of CM servers node-steam will attempt to connect to. The bootstrapped list (see servers.js) is not always up-to-date and might contain dead servers. To avoid timeouts, replace it with your own list before logging in if you have one (see 'servers' event).
Whenever a method accepts (or an event provides) an
ESomething, it's a Number that represents some enum value. See enums.steamd and eresult.steamd for the whole list of them. For each enum, there is an equivalently named property on
Steam. The property is an object; for each of the enum's members, there is an equivalently named property on the object with an equivalent value.
Note that you can't easily get the string value from the number, but you probably don't need to. You can still use them in conditions (e.g.
if (type == Steam.EChatEntryType.Emote) ...) or switch statements.
Whenever a method accepts (or an event provides) a
CMsgSomething, it's an object that represents a protobuf message. It has an equivalently named property for each set field in the specified message with the type as follows:
bytesfields: Buffer objects
See the wiki for descriptions of protobuf fields.
Most of the API is provided by handler classes that internally send and receive low-level client messages using 'message'/send:
If you think some unimplemented functionality belongs in one of the existing handlers, feel free to submit an issue to discuss it.
A boolean that indicates whether you are currently connected and the encryption handshake is complete. 'connected' is emitted when it changes to
true, and 'error' is emitted when it changes to
false unless you called disconnect. Sending any client messages is only allowed while this is
A boolean that indicates whether you are currently logged on. Calling any handler methods other than SteamUser#logOn is only allowed while logged on.
Your session ID while logged on, otherwise unspecified. (Note: this has nothing to do with the "sessionid" cookie)
Your own SteamID while logged on, otherwise unspecified. Must be set to a valid initial value before sending a logon message (SteamUser#logOn does that for you).
You can call this method at any time. If you are already connected, disconnects you first. If there is an ongoing connection attempt, cancels it.
Immediately terminates the connection and prevents any events (including 'error') from being emitted until you connect again. If you are already disconnected, does nothing. If there is an ongoing connection attempt, cancels it.
Connection closed by the server. Only emitted if the encryption handshake is complete, otherwise it will reconnect automatically.
loggedOn is now
Logon response received. If
loggedOn is now
node-steam will use this new list when reconnecting, but it will be lost when your application restarts. You might want to save it to a file or a database and assign it to
Steam.servers before logging in next time.
Steam.servers will be automatically updated after this event is emitted. This will be useful if you want to compare the old list with the new one for some reason - otherwise it shouldn't matter.
You were logged off from Steam.
loggedOn is now
Sending and receiving client messages is designed to be symmetrical, so the event and the method are documented together. Both have the following arguments:
header- an object representing the message header. It has the following properties:
CMsgProtoBufHeaderobject if this message is protobuf-backed, otherwise
header.protois falsy. The following fields are reserved for internal use and shall be ignored:
jobid_target. (Note: pass an empty object if you don't need to set any fields)
body- a Buffer containing the rest of the message. (Note: in SteamKit2's terms, this is "Body" plus "Payload")
callback(optional) - if not falsy, then this message is a request, and
callbackshall be called with any response to it instead of 'message'/send.
callbackhas the same arguments as 'message'/send.