I played with this a little last night - got the API to accept new values,  and fed them through to the point that it was performing the Ticket: (using source as "Staff" rather than API) .... also ended up supplying the additional value for the help topid ID that it seems to want when performing the manual add that wasnt required with the "API" user.... so its definitely triggering a different condition set...But the ticket is still being created as if a user is submitting through email.   The source shows different, but the entry in the ticket history shows it was created by the user, and the email response is that there was a ticket opened... not the content that I sent.  The only thing I can think of is that there are 2 paths through the system... the API and users follow one, whereas the logged in support users follow another (before hitting common low level functionality).Is the "normal" workflow not followed when a support person submits a ticket?

Ok - there is a second path though the system... Ticket: is used for staff....

In api.ticket.php – check for new “asStaff” -> true

  if found  use Ticket::open($vars, &$errors)   

(not create... allow non "asStaff" to follow existing path) 

   (likely need to add additional values to the API to support the 'open' call)

I'll fork on github and let you decide what to do with it :)

pull request there for you.Sample JSON array:

$data = array(

'name' => 'slartibardfast',

'email' => 'me@myemail.com',

'subject' => 'Test API message',

'message' => 'This is a test of the osTicket extended API',

'ip' => 'a.b.c.d',

'attachments' => array() ,

'source' => 'other',

'asStaff' => 1,

'topicId' => 1

);

Source should be one of "email", "phone", "other"

asStaff can be either id# of the Staff member, or staff name (creation of new Staff allows both options already... 1 is just easier)

topicId is required by the validation, represents a topic# reference for user.

hmm... some deeper side effects. My testing has been through an interactive PHP interpreter, and I just got a slew of these emailsThe culprit seems to be that there is old code in my v1.9.2 that was upgraded from 1.8.0 ...The select that it's complaining about has no relevance to the database content of that table... id=1 refers to the 'isonline' key.. Unknown column 'ostversion' in 'field list'---- Backtrace ----#0 (root)/include/mysqli.php(169): osTicket->logDBError('DB Error #1054', '[SELECT `ostver...')#1 (root)/include/class.config.php(1208): db_query('SELECT `ostvers...')#2 (root)/include/class.ostsession.php(35): OsticketConfig->getDBVersion()#3 (root)/include/class.ostsession.php(154): osTicketSession->osTicketSession(86400)#4 (root)/include/class.osticket.php(58): osTicketSession->start(86400)#5 (root)/include/class.osticket.php(448): osTicket->osTicket()#6 (root)/include/api.tickets.php(129): osTicket->start()#7 (root)/include/api.tickets.php(106): TicketApiController->createTicket(Array)#8 : TicketApiController->create('json')#9 (root)/include/class.dispatcher.php(145): call_user_func_array(Array, Array)#10 (root)/include/class.dispatcher.php(38): UrlMatcher->dispatch('/tickets.json', NULL)#11 (root)/api/http.php(31): Dispatcher->resolve('/tickets.json')#12 {main}