Hi there
I reproduced this on an OmniCore RW 8.1.1 VC and found the cause. Everything below is from that run, not from the docs.
1 and 3. The id has to be a braced GUID. Same controller, same call, fresh session each time, only the id format changed:
unbraced 890d22b5-9842-4192-ade0-a03e537f87c9
-> HTTP 400, ctrl=-1073435867, icode=-20103
"Control station id not allowed"
GET /rw/controlstation/id -> "none"
braced {8dd4cd46-5757-4f80-96e0-38de864be6a9}
-> 204 OK
GET /rw/controlstation/id -> "{8dd4cd46-5757-4f80-96e0-38de864be6a9}"
-1073435867 is 0xC004AB25 as a signed 32-bit int, and the icode matches your org_code -20103, so this is the identical error down to the org code. In C# use Guid.NewGuid().ToString("B") instead of .ToString(). The default “D” format has no braces.
liao_Chen found the same thing from the PC SDK side back in June, in “PCSDK 2026 register with rw8”( link). The sample in the PC SDK documentation is missing the braces.
The GET /rw/controlstation/id read-back is worth keeping as a check. It returns “none” when nothing is bound and echoes your id when the registration actually took.
4. The pin is mandatory but its value is not checked. I registered with 1234, with 9999 and with an empty string. All three worked, on a controller where I had never configured a pin. A non-numeric value, or leaving the field out entirely, gives 400 (-1073445879). So it has to be present and numeric, but nothing needs setting up in advance and nothing pairs against it. The display name is mandatory too.
5. There is no enable step. My flow is two calls, register and then request write access, nothing in between. I probed the controller for an enable endpoint:
POST /rw/controlstation/enableexternalcontrol -> 404
POST /rw/controlstation/externalcontrol/enable -> 404
POST /rw/controlstation/enable-external-control -> 404
GET /rw/controlstation/disableexternalcontrol -> 405
The 405 means that path exists and only the verb was wrong. The enable variants all give 404, so they do not exist. The resource listing under /rw/controlstation shows disableexternalcontrol with no counterpart. A remote client can drop external control but cannot give it to itself.
2 and 6. Nothing extra was needed. No extra RobotWare option, no RobotStudio setting. A plain VC registered fine once the id format was right.
One caveat. The pendant’s Remote Access toggle was already on for my VC, and it shows up as control-station-external-control-enabled: true in the write access status. I did not test it switched off, because switching it back on needs a physical long press on the virtual pendant and that would have broken my rig. If the braces alone do not fix it, check that toggle next. Also worth keeping in mind that you are on 8.1.0 and I am on 8.1.1.
7. Not a version mismatch. 26.2.11700.0 is the PC SDK 2026.2 build and it has no API changes compared to 2026.1. That pairing is not your problem.
8. Your sequence is right. Two things about RW8 that cost me time:
Registration is session scoped. Register once per connection, not per write, and again after a reconnect.
A write clears write access as a side effect. After a successful write the status resource reports the access as no longer held, while the same session carries on writing fine. So the ReleaseWriteAccess() at the end of your sequence can fail on something you already lost. Check the status first, or let the release fail quietly.
One more thing that might save you some time. Registration worked while a different station held write access, so registering and holding write access are independent. You do not have to wait for the controller to be free before you register.
Unrelated, but relevant if you are testing on 8.1.1: the RMMP service is broken there, every verb answers 500. I checked it back to back against a working RW 7.21. Do not lose a day on it thinking it is your code.
Thanks for your UAS grant answer on the Rapid.Start() thread by the way, that one had been open a long time.