# Data Services API problem

**URL:** <https://forums.collective2.com/t/data-services-api-problem/1084>\
**Category:** C2 Software Development\
**Created:** [January 21, 2011, 3:55am UTC](https://forums.collective2.com/t/data-services-api-problem/1084 "2011-01-21T03:55:28Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![WD](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/32.png) [@WD](https://forums.collective2.com/u/WD)\
**Post date:** [January 21, 2011, 3:55am UTC](https://forums.collective2.com/t/data-services-api-problem/1084/1 "2011-01-21T03:55:28Z")

</div>

Hi all,  
  
  
  
I’m using the Data Services API to retrieve information about my trading systems in an automated way using Java.  
  
  
  
Sometimes (seems to happen totally random) I get an **“Unknown Session” error** back from C2.  
  
  
  
This is what I do twice every hour:  
  
  
  
1) **request session** using appropriate command  
  
2) **request info** (signal, trades, open positions, …)  
  
3) **logout**  
  
  
  
**Problem** : after succesfully getting a session(id) in step 1, I get the “Unknown session” error in step 2. Even after serveral tries. I even tried using a small delay (couple of secs) between step 1 and step 2.  
  
  
  
It never happens when using a browser (firefox, chrome, …) but only when connecting through my own software although I changed the header to pretend to be a firefox browser  
  
  
  
What can cause this ?  
  
Is this some C2 issue ?  
  
Any ideas ?  
  
  
  
Best regards,  
  
Wouter

---

<div class="post-metadata">

**Author:** ![MatthewKlein](https://yyz2.discourse-cdn.com/flex028/user_avatar/forums.collective2.com/matthewklein/32/21382_2.png) [@MatthewKlein](https://forums.collective2.com/u/MatthewKlein)\
**Post date:** [February 2, 2011, 9:28am UTC](https://forums.collective2.com/t/data-services-api-problem/1084/2 "2011-02-02T09:28:13Z")

</div>

Wouter:  
  
  
  
Are you still seeing this problem? We recently made changes to the way our secondary database reads from our primary database, and this may have reduced (or even eliminated) the problem. Looking for feedback…