WEBVTT

00:00:01.300 --> 00:00:05.307
Connections can need attention even after they worked before. A provider may

00:00:05.307 --> 00:00:09.314
reject a request, a credential may have expired or been revoked, or

00:00:09.314 --> 00:00:13.320
a required permission may no longer be available. Start with the message

00:00:13.320 --> 00:00:17.327
the app actually shows. A failed connection request does not, by itself,

00:00:17.327 --> 00:00:21.000
explain where every asset is or what happened to every order.

00:00:21.500 --> 00:00:25.545
Check the provider and connection name first. Then read the status and

00:00:25.545 --> 00:00:29.590
any error code or explanation. If the problem appears to be a

00:00:29.590 --> 00:00:33.635
temporary request failure, use the offered refresh or connection-check route deliberately and

00:00:33.635 --> 00:00:37.681
read its result. Repeating the same action rapidly does not create better

00:00:37.681 --> 00:00:41.726
evidence, and an older displayed balance should not be mistaken for a

00:00:41.726 --> 00:00:42.400
successful refresh.

00:00:42.900 --> 00:00:47.011
If the issue concerns credentials or permissions, review the exchange's own access

00:00:47.011 --> 00:00:51.123
settings privately. Confirm that you are looking at the credential intended for

00:00:51.123 --> 00:00:55.234
TraderLobby. Do not post the key, secret, passphrase, or private key in

00:00:55.234 --> 00:00:59.346
a support request. A useful report names the affected provider, the action

00:00:59.346 --> 00:01:03.457
that failed, and a redacted message, without exposing the material that grants

00:01:03.457 --> 00:01:03.800
access.

00:01:04.300 --> 00:01:08.300
The current connection screens do not provide a way to reveal and

00:01:08.300 --> 00:01:12.300
edit the saved secret. If replacement credentials are needed, follow the supported

00:01:12.300 --> 00:01:16.300
setup and removal workflow, and check the new result. Do not guess

00:01:16.300 --> 00:01:20.300
that changing a connection name updates the underlying key. The label and

00:01:20.300 --> 00:01:23.300
the access credential are different pieces of the connection.

00:01:23.800 --> 00:01:28.081
Now distinguish removal inside TraderLobby from revocation at the exchange. Desktop offers

00:01:28.081 --> 00:01:32.363
Remove on the connection card. Mobile offers Delete and then a confirmation

00:01:32.363 --> 00:01:36.644
with Delete permanently. The mobile explanation says this removes the connection and

00:01:36.644 --> 00:01:40.925
its stored credentials. Do not assume the desktop button will give you

00:01:40.925 --> 00:01:44.850
the same extra confirmation; leave both untouched while following the lesson.

00:01:45.350 --> 00:01:49.785
Removing the stored TraderLobby connection is not the same as revoking the

00:01:49.785 --> 00:01:54.219
API credential in the provider's account settings. If your intention is to

00:01:54.219 --> 00:01:58.654
revoke that credential, use the exchange's own access-management process as well and

00:01:58.654 --> 00:02:03.088
verify the result there. Do not assume that deleting the local connection

00:02:03.088 --> 00:02:05.675
makes a copied credential unusable everywhere else.

00:02:06.175 --> 00:02:10.478
Removal also does not liquidate holdings, withdraw assets, cancel every outstanding order,

00:02:10.478 --> 00:02:14.782
or settle a subscription. If you intend to stop trading, handle the

00:02:14.782 --> 00:02:19.085
relevant automation, orders, and positions through their own workflows and confirm what

00:02:19.085 --> 00:02:23.389
happened. Losing the app's access can make managing an existing exchange position

00:02:23.389 --> 00:02:26.975
from TraderLobby harder; it does not make that position disappear.

00:02:27.475 --> 00:02:31.375
There is one more context check after removal. If you remove the

00:02:31.375 --> 00:02:35.275
default connection, the current app can select another remaining valid connection as

00:02:35.275 --> 00:02:39.175
the default. Inspect the list afterward rather than assuming there is now

00:02:39.175 --> 00:02:43.075
no default. If no usable connection remains, read the resulting limitations. Do

00:02:43.075 --> 00:02:46.975
not create a replacement merely to clear a message while you are

00:02:46.975 --> 00:02:48.275
still investigating the problem.

00:02:48.775 --> 00:02:53.073
For your check, explain how you would respond to a failed refresh,

00:02:53.073 --> 00:02:57.371
where you would review exchange permissions, and how local removal differs from

00:02:57.371 --> 00:03:01.669
provider revocation. Do not remove or revoke anything for practice. The result

00:03:01.669 --> 00:03:05.967
we want is a clear repair plan that protects access and keeps

00:03:05.967 --> 00:03:07.400
the account context understandable.