Skip to main content
Commands let your application take action on a vehicle. Unlike signals, which read vehicle state, commands write to it — they alter the data or state of the vehicle.

​
Available Commands

Charge schedules are supported on a subset of makes. Requests for a vehicle whose make does not support them return a VEHICLE_NOT_CAPABLE compatibility error:
After creating a schedule, read it back from the ChargeTimers signal. Timers with "type": "LOCATION" include a scheduleType and scheduleId — use the scheduleId to issue DELETE requests. The signal reflects all schedules on the vehicle, including any set outside of the API.

​
Data State Changes

Commands do not return updated vehicle state. After issuing a command, confirm or monitor its effect by reading the corresponding signal — via the Vehicle Data API or a Webhooks. Signal updates may be delayed as the change propagates to the vehicle.

​
Key Concepts

​
sc-user-id Header

All command endpoints require the sc-user-id header. Your bearer token is application-level and does not carry per-user context, so this header must be provided on every request to identify which user’s vehicle to act on.

​
202 Response

Most commands resolve in under 175 seconds and return a single, complete response. If a command takes longer than that, Smartcar sends a 202 Accepted status to keep the connection open while the command finishes, instead of timing out. A 202 is not the final result — it’s a signal that the command is still running. The connection stays open, and Smartcar streams the complete response body on that same connection once the command finishes. Always read the full response body to determine whether the command succeeded or failed.
There’s no Content-Length header on a 202 response, since the final size isn’t known yet. Don’t read a fixed number of bytes or treat the arrival of any bytes as the response being complete — wait for the connection to close (or the chunked stream to send its final chunk) before parsing the body.
Most HTTP clients (axios, node-fetch, requests, OkHttp, etc.) handle this correctly by default. If you’ve configured a client with a short read timeout, or one that returns as soon as the first bytes arrive, you may get a partial or empty result instead of the actual command outcome.
If you’re testing with curl, add -N (--no-buffer) to see the response stream in as it arrives — the 202, then the final result once the command finishes — instead of curl waiting and printing everything at once when the connection closes. Add -i to also see the status line and headers along with the body: