BearBreakerBearBreaker executes through Alpaca. That choice keeps the setup simple: one broker, one documented REST interface, and a paper environment that behaves like the live one. Before the system can place a single order you need to generate API credentials and put them in your configuration files.
Alpaca gives you two values, a key ID and a secret key, and two base endpoints, one for paper and one for live. The key pair identifies your account and authorises order submission, position lookups, and account queries. The endpoint decides which account those calls hit. Paper and live keys are not interchangeable, so keep them in separate configuration blocks and label them clearly. Nothing hurts more than discovering a "test run" was pointed at real money.
Those credentials live on your machine or on your own server. They are never sent to me and there is no BearBreaker cloud account holding them. If you host on a VPS, restrict file permissions so only your user can read the configuration, and avoid pasting keys into shared terminals or screenshots. If a key is ever exposed, revoke it in the Alpaca dashboard and generate a new pair. Revocation is immediate and costs nothing.
Once the keys are in place, start in paper mode and let a few full cycles run. Watch the log confirm account connectivity, read back positions, and place its first controlled seed order. If the log shows authentication errors, the usual causes are a trailing space in the key, mismatched paper keys against the live endpoint, or a clock that is far out of sync on the host machine.
Only after you have watched the connection stay stable across several sessions should you swap in live credentials. The code does not change. The endpoint and the consequences do.