WEBVTT

00:00:01.300 --> 00:00:05.041
A strategy may identify something it wants to do and still be

00:00:05.041 --> 00:00:08.782
unable to do it. Permission is one reason. For Live activity, TraderLobby

00:00:08.782 --> 00:00:12.523
uses an authorized exchange connection to request supported actions. That connection is

00:00:12.523 --> 00:00:16.264
a controlled route to your exchange account. It is not a transfer

00:00:16.264 --> 00:00:20.005
of ownership of your funds, and it is not an unlimited instruction

00:00:20.005 --> 00:00:21.875
to act however the app chooses.

00:00:22.375 --> 00:00:25.967
Return to API Connections and inspect the selected connection without editing it.

00:00:25.967 --> 00:00:29.559
Confirm the exchange, the account context shown, and the available connection or

00:00:29.559 --> 00:00:33.150
order-permission status. Being able to read a balance does not by itself

00:00:33.150 --> 00:00:36.742
establish that an order can be submitted. A connection can answer one

00:00:36.742 --> 00:00:40.334
kind of request while another kind is unavailable or rejected. Read the

00:00:40.334 --> 00:00:43.926
relevant status rather than treating Connected as an answer to every permission

00:00:43.926 --> 00:00:44.225
question.

00:00:44.725 --> 00:00:48.395
Permissions exist at more than one level. Your app role affects which

00:00:48.395 --> 00:00:52.064
controls you can use. Your access to a strategy affects whether that

00:00:52.064 --> 00:00:55.734
offering is available to you. The exchange connection affects which account actions

00:00:55.734 --> 00:00:59.403
are permitted. The current trading context and its controls can also restrict

00:00:59.403 --> 00:01:03.073
activity. These checks work together. Passing one does not skip the others,

00:01:03.073 --> 00:01:05.825
and purchasing access does not repair a connection problem.

00:01:06.325 --> 00:01:10.028
The account and connection deserve special attention when you have more than

00:01:10.028 --> 00:01:13.731
one. Two connections can belong to the same exchange and still refer

00:01:13.731 --> 00:01:17.434
to different account contexts. A strategy result from one context is not

00:01:17.434 --> 00:01:21.136
proof that another connection is ready. Before interpreting a blocked action, confirm

00:01:21.136 --> 00:01:24.839
that you are inspecting the connection associated with the strategy or position

00:01:24.839 --> 00:01:27.925
in question. Matching the coin symbol alone is not enough.

00:01:28.425 --> 00:01:32.380
Permission also does not guarantee acceptance. The exchange may apply order-size rules,

00:01:32.380 --> 00:01:36.336
available-balance checks, market availability, or other restrictions. A request that was allowed

00:01:36.336 --> 00:01:40.291
to leave the app can still fail to complete as intended. Keep

00:01:40.291 --> 00:01:44.247
the steps separate in your mind: allowed to request, request received, and

00:01:44.247 --> 00:01:48.202
action completed. The result must be inspected after the request, not assumed

00:01:48.202 --> 00:01:49.850
from the permission screen beforehand.

00:01:50.350 --> 00:01:54.175
For example, imagine that a strategy is enabled and its subscription is

00:01:54.175 --> 00:01:58.000
active, but the selected connection cannot place orders. Increasing its allocation would

00:01:58.000 --> 00:02:01.825
not answer that problem. The useful next step is to read the

00:02:01.825 --> 00:02:05.650
connection's status and the specific message associated with the failure. Likewise, if

00:02:05.650 --> 00:02:09.475
a control is unavailable because of your role, changing a strategy setting

00:02:09.475 --> 00:02:12.025
is not a substitute for the right access.

00:02:12.525 --> 00:02:16.001
Your checkpoint is a short explanation: This strategy has access, it belongs

00:02:16.001 --> 00:02:19.476
to this context, and these are the permissions I can currently verify.

00:02:19.476 --> 00:02:22.952
Leave credentials private while doing that. You can describe a status without

00:02:22.952 --> 00:02:26.428
showing an API key or secret. In this lesson we are learning

00:02:26.428 --> 00:02:29.904
how to inspect the boundaries. We are not changing permissions or moving

00:02:29.904 --> 00:02:32.800
into Live to test whether an order will go through.