Best way to log API calls that create records

Perhaps a logic hook after_routing, which evaluates the platform and user, can decide whether to log somewhere the provided data.

If you have access to core code you can add logging to ~/include/api/RestService.php just below the comment that has "// This looks like the post contents are JSON".

Something like:

                    // This looks like the post contents are JSON
                    // Note: If we want to support rest based XML, we will need to change this

@$GLOBALS['log']->fatal("POSTED DATA:$postContents");

Add extra code to filter out unwanted requests based on $this->getRequest()->getRequestURI().

If it is sugarondemand then you may be able to create a ~/custom/include/api/RestService.php, derive from the core code RestService and override getRequestArgs(). I've not tried that though.

Please don't make any changes to the core files.. this is not upgrade save. Always make changes using the custom dataframework. 

I can't agree with you on this. Adding temporary logging to core code is often the only way to diagnose complex issues. Esp. SugarBPM issues (which there have been many). If OP has access to the core code then this is a quick way to prove what a client is sending.

I wonder wether this approach works for monitoring API calls to Sugar Sell/Serve and other products deployed in the Sugar Cloud.

Do you know if such code adjustments comply to Sugar Cloud Policy? 

There is no-code upgrade safe approach could be applied in case of the the variety of API calls is not too significant

1. Use Roles to restrict creating records of all modules for the user, which is used loggin via API

2.Configure a custom endpoint by adding new LB Services record and allow APi user to access this module

3. Draw a flowchart with Logic Builder that will check the JSON retrieved via custom endpoint and, after logging the JSON, to decide yourself in a flowchart wether to create or update any Sugar records or not and, if nessesary, to return  error-refusal to the inquiring system with explanation

This approach will make all the API access 100% managable by Sugar Admin an also would help to make  the custom business logic implemented in Sugar respected for the API calls

Let me know if there is a need of example

You may also read about Sugar Partner's experience with Logic Builder in Clubs blog:

 sugarclub.sugarcrm.com/.../how-analysts-can-do-more-for-customers-and-their-own-company

You should be able to identify issue on SugarBPM via apache or nginx  Logs, I just create a application logichook to check when SugarBPM run and logs the bean IDs and Some parts of the arguments. Change core files are always a critical change and normally it will be overwriting. 

Actually the answer was the 'before_respond' logic hook.  There I can access the incoming call and the response generated by Sugar

Actually the answer was the 'before_respond' logic hook.  There I can access the incoming call and the response generated by Sugar

I wish that was a rule, sadly it's not.  I mean I ended up doing this entirely in custom but I also have at least a dozen files I have to manually upgrade each time because of all the hard coding in the Sugar code base still.  I mean I wanted to make the Field Name Placement default to ABOVE but its all hard coded in the users bean.  Not sure why they did it but the drop down is NOT defined in a language file but hard coded.   In a feature added in v10.  Holy crap batman.

I mean its a good mantra to live by  but "always" is a pipe dream still.