API v4: Difference in permissions between GetAutotradeActiveOrders and GetAutotradeHistoricalOrders

C2 Software Development
1

I’m working with the C2 API v4 and I have two API keys:

• One is a reduced‑access key (no trading rights).

• The other is a full‑access key (trading rights enabled).

I’m seeing some inconsistent behavior between the autotrade endpoints and these keys:

  • When I call GetAutotradeActiveOrders, the request only succeeds if I use the full‑access key. When I use the reduced‑access key, the API returns error code 1002 with the message "Permission".

  • When I call GetAutotradeHistoricalOrders, I observe the opposite. The request succeeds with the reduced‑access key, but when I try the full‑access key, the API returns error code 1002 with the message "Not authorized to access Endpoint".

According to the v4 documentation, both endpoints are informational. I would have expected that both keys be allowed to call both endpoints. Instead, the permission requirements seem like random.

Has anyone else encountered this? Is there a different scope or key type I should be using to retrieve both active and historical orders from my autotrade account? Any guidance from C2 on which key type is allowed to call which autotrade endpoints would be appreciated.

2

Hi Marina,

The full-access (aka ‘user’) key profile was missing the required permission for GetAutotradeHistoricalOrders. It’s now been added.

I could not replicate your other issue with GetAutotradeActiveOrders: I tried both your keys and they worked fine. Could you try again and let me know?

Francis

3

Hi Francis,

Thanks for the update. I can confirm that both GetAutotradeHistoricalOrders and GetAutotradeActiveOrders are now working correctly with their respective keys.

Could you please take a look at the GetAutoTradeOpenPositions endpoint? When I call it with my “no trading rights” key, I still receive a permission error. Since this endpoint is informational, I would expect it to work with both keys.

Also, I noticed a discrepancy between the API documentation and the actual responses. The docs show response fields beginning with a lowercase letter, for example:

{
  "results": [
    {
      "id": 0,
      "orderId": "string",
      "strategyId": 0
      …
    }
  ]
}

However, the API returns fields starting with uppercase letters:

{
  "Results": [
    {
      "Id": 0,
      "OrderId": "string",
      "StrategyId": 0
      …
    }
  ]
}

Some consistency between the documentation and the API responses would be greatly appreciated, as a case mismatch can cause issues when parsing JSON.

Lastly, it would be really helpful if the documentation could clarify which endpoints are available to full-access keys versus reduced (no trading rights) keys. This guidance would help developers avoid the kind of trial-and-error I’ve been encountering.

Thanks again for your help!

Marina

4

That was another permission missing for the developer profile. It’s now been added. Our permissioning system is designed to be very restrictive to prevent unauthorized access to clietn data, and sometimes this happens.

Our API is not case-sensitive, but it’s a good point as many client-side libraries are case sensitive, so we will change the documentation generation library to use PascalCase for consistency.