Home

API V2 Release Date

%3CLINGO-SUB%20id%3D%22lingo-sub-77433%22%20slang%3D%22en-US%22%3EAPI%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-77433%22%20slang%3D%22en-US%22%3E%3CP%3EWhen%20will%20v2%20of%20the%20API%20be%20release%20to%20developers%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-77433%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAPI%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EDeveloper%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EREST%20API%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EYammer%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-298217%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-298217%22%20slang%3D%22en-US%22%3E%3CP%3EAny%20update%20on%20V2%20release%20and%20documentation%20%3F%20I%20only%20can%20find%20v1%20documentation%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-83854%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-83854%22%20slang%3D%22en-US%22%3ESeems%20there's%20no%20info%20on%20release%20dates%20there%20-%20unless%20I'm%20using%20search%20wrong.%20Also%2C%20V2%20should%20include%20views%2C%20likes%20per%20message%2C%20and%20likes%20with%20a%20datestamp!%20Why%3F%20When%20you%20measure%20%22user%20activity%22%20it%20would%20be%20nice%20to%20know%20the%20relation%20between%20views%2C%20likes%2C%20and%20replies.%20We%20want%20to%20measure%20the%20activity%20of%20likes%20and%20views%20over%20a%20given%20timeframe%20as%20well.%20Yes%2C%20I've%20seen%20the%20aggregate%20data%20in%20the%20O365%20admin%20console%2C%20but%20it%20doesn't%20give%20us%20data%20you%20can%20actually%20use.%3CBR%20%2F%3E%3CBR%20%2F%3EI%20want%20to%20be%20able%20to%20answer%3A%3CBR%20%2F%3E%3CBR%20%2F%3E%22Hey%2C%20how%20many%20people%20visited%20our%20group%20this%20month%3F%22%3CBR%20%2F%3E%22How%20many%20people%20viewed%20this%20message%20posted%20by%20our%20CEO%20vs%20if%20the%20same%20message%20posted%20by%20ME%22%3CBR%20%2F%3E%22Are%20people%20more%20prone%20to%20like%20a%20message%20when%20a%20hashtag%20is%20included%3F%22%3CBR%20%2F%3E%22How%20many%20likes%20does%20it%20take%20to%20get%20the%20the%20center...%22%20-%20well%20maybe%20not%20this%20one.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-82401%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-82401%22%20slang%3D%22en-US%22%3E%3CP%3EI%20am%20using%20the%20Yammer%20Export%20API%20to%20download%20message%20data%20on%20a%20nightly%20basis.%20%26nbsp%3BThe%20%3CSPAN%3EYammer%20%3C%2FSPAN%3EExport%20API%20does%20not%20ommitt%20any%20messages%2C%20and%20you%20can%20pull%20all%20messages%20in%20one%20request.%20%26nbsp%3BBut%2C%20the%20%3CSPAN%3EYammer%20%3C%2FSPAN%3EExport%20API%20does%20not%20include%20Likes%20data%20for%20each%20message.%20%26nbsp%3BSo%2C%20if%20you%20want%20Likes%20data%2C%20you'll%20have%20to%20work%20with%20the%20Yammer%20API.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-82399%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-82399%22%20slang%3D%22en-US%22%3E%3CP%3EIn%20my%20case%20I'm%20on%20a%20team%20within%20my%20company%20who's%20goal%20is%20to%20improve%20internal%20communication.%20%26nbsp%3BYammer%20is%20a%20big%20part%20of%20our%20plan.%20%26nbsp%3BAs%20such%20I%20am%20exporting%20all%20of%20the%20message%20data%20out%20of%20Yammer%20into%20our%20Business%20Inteligence%20platform%20(DOMO)%20to%20be%20able%20to%20dig%20into%20the%20data%20and%20measure%20KPI%20over%20time.%20%26nbsp%3BWe%20can't%20get%20meaningful%20BI%20out%20of%20the%20Yammer%20data%20with%2040%25%20of%20the%20data%20missing.%20%26nbsp%3BSo%2C%20that's%20what%20I've%20been%20working%20to%20solve%20for.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-82249%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-82249%22%20slang%3D%22en-US%22%3EGotcha%20!%3CBR%20%2F%3EPlease%20correct%20me%20if%20I'm%20wrong%2C%20but%20I%20presume%20that%20you%20are%20running%20the%20export%20API%20in%20some%20cron%20job%20to%20update%20the%20database%20periodically.%20I%20am%20actually%20building%20an%20app%20which%20crunches%20data%20in%20real%20time%20from%20yammer%2C%20so%20the%20export%20API%20path%20might%20not%20be%20useful%20for%20me%20%3A(%3CBR%20%2F%3E%3CBR%20%2F%3EIs%20the%20%2Fexport%20API%20also%20omitting%20the%20data%20%3F%20(I%20am%20currently%20using%20Yammer%20OAuth%20which%20is%20omitting%20the%20data)%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-82221%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-82221%22%20slang%3D%22en-US%22%3E%3CP%3EIt's%20great%20to%20see%20this%20discussion%2C%20and%20the%20shared%20advice%20from%20the%20devs%20in%20our%20Yammer%20community.%3C%2FP%3E%0A%3CP%3EIt%20would%20help%20me%20to%20go%20up%20a%20level%2C%20to%20understand%20the%20use%20case(s)%20you're%20building%20for.%20%26nbsp%3BPlease%20post%20your%20use%20cases%2Fuser%20scenarios.%20Thanks!%3C%2FP%3E%0A%3CP%3E-%20Sabra%2C%20Yammer%20Platform%20Team%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-82023%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-82023%22%20slang%3D%22en-US%22%3E%3CP%3EVimanyu%20on%20my%20current%20path%20I'm%20using%20the%20export%20API%20to%20get%20all%20of%20the%20messages%2C%20then%20I'm%20looping%20through%20each%20message%26nbsp%3Busing%20the%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fwww.yammer.com%2Fapi%2Fv1%2Fusers%2Fliked_message%2F%3AMessage_id.json%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fwww.yammer.com%2Fapi%2Fv1%2Fusers%2Fliked_message%2F%3AMessage_id.json%3C%2FA%3E%20to%20get%20the%20like%20data.%20%26nbsp%3BThe%20rate%20limit%20is%20painful%20as%20you'd%20expect.%20%26nbsp%3BAlso%2C%20the%20CSV%20formatting%20from%20the%20export%20API%20is%20poorly%20formed%2C%20which%20has%20complicated%20this%20effort%2C%20but%20it%20does%20appear%20to%20be%20doable.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-81767%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-81767%22%20slang%3D%22en-US%22%3EHi%20Ben%2C%20just%20in%20case%20it%20might%20be%20helpful%20to%20you%20-%20I%20have%20a%20little%20lead%20in%20figuring%20out%20what%2040%25%20data%20omission%20means%20-%20and%20how%20it%20can%20somehow%20be%20a%20%22design%20decision%22.%3CBR%20%2F%3EYammer%20API%20%22collapses%22%20the%20threads%20so%20that%20we%20only%20get%20to%20see%20the%20latest%20entry%20on%20a%20specific%20thread%20and%20only%20that%20latest%20entry%20is%20retrieved%20from%20the%20messages%20GET%20API.%20If%20we%20look%20at%20the%20meta-data%20of%20the%20message%20object%2C%20we'll%20find%20that%20the%20%22replied_to_id%22%20has%20thread_id%20of%20the%20original%20post%20(original%20post%20has%20thread_id%20%3D%20message%20id%20and%20replied_to_id%20%3D%20null).%20So%20my%20solution%20is%20to%20store%20all%20the%20thread_id%20in%20a%20hash-set%20and%20then%20find%20all%20messages%20in%20a%20specific%20thread%20by%20making%20calls%20to%20messages%2Fin_thread%2FthreadID.json.%20By%20iterating%20over%20entire%20hash-set%20of%20thread_id%2C%20we%20can%20GET%20all%20messages.%20However%2C%20there%20is%20a%20catch%20to%20this%20-%20RATE%20LIMITS.%3CBR%20%2F%3E%3CBR%20%2F%3EWould%20appreciate%20any%20help%2Fadvice%20on%20this.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-81764%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-81764%22%20slang%3D%22en-US%22%3EI%20have%20been%20trying%20nearly%20the%20same%20thing%20i.e.%20to%20GET%20all%20messages%20from%20Yammer%20REST%20API%20using%20endpoint%20messages%2Fsent.json%2C%20and%20I%20cannot%20tell%20you%20how%20bumpy%20this%20journey%20has%20been%20!%20First%20of%20all%20there%20is%20no%20mention%20of%20batch%20size%20being%2020%20apart%20from%20a%20casual%20reference%20%22For%20example%2C%20if%20you%E2%80%99re%20currently%20viewing%2020%20messages%20%22.%20Then%20I%20found%20out%20that%20%22limit%22%20doesn't%20work%20as%20expected%20-%20It'll%20give%20you%20anything%20less%20than%2020%20but%20nothing%20larger%20than%2020.%20I%20somehow%20fixed%20it%20by%20making%20sequential%20AJAX%20calls%20and%20switching%20to%20Yampy%20(Python%20SDK)%20from%20JS%20SDK%20so%20that%20I%20can%20GET%20message%20array%20having%20length%20more%20than%2020%20by%20finding%20oldest%20message%20ID%20and%20then%20making%20sequential%20calls%20until%20GET%20API%20returns%20message%20array%20of%20length%20zero%20!%3CBR%20%2F%3E%3CBR%20%2F%3ECurrently%2C%20I%20am%20also%20stuck%20with%20random%20missing%20data%20from%20the%20GET%20API%20-%20is%20there%20any%20work-around%20for%20this%20%3F%20I%20haven't%20yet%20tried%20this%2C%20but%20I%20thought%20of%20a%20way%20to%20store%20all%20the%20thread_id%20in%20a%20hash-set%20and%20then%20making%20GET%20request%20to%20messages%2Fin_thread%2FthreadID.json%20by%20iterating%20over%20that%20hash-set.%20However%2C%20with%20this%20way%20I%20presume%20that%20rate%20limits%20will%20bind%20my%20hands%20down.%3CBR%20%2F%3E%3CBR%20%2F%3EPlease%20let%20me%20know%20if%20you%20can%20think%20of%20a%20better%20solution%20for%20this.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-81513%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-81513%22%20slang%3D%22en-US%22%3E%3CP%3ERE%3A%20%26nbsp%3B%231%20and%20%233%3CBR%20%2F%3EIt%20was%20worth%20a%20shot.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ERE%3A%26nbsp%3B%232%3CBR%20%2F%3EWe're%26nbsp%3Btrying%20to%20download%20data%20for%20all%20of%20our%20messages.%20%26nbsp%3BBest%20I%20can%20tell%20the%20API%20is%20randomly%20ommitting%2040%25%20of%20the%20messages.%20%26nbsp%3BHow%20is%20one%20supposed%20to%20programatically%20know%20which%2040%25%20is%20missing%20and%20thereby%20what%20requests%20of%20the%20API%20will%20retrieve%20that%20missing%2040%25%3F%20%26nbsp%3BI%20don't%20believe%20it%20is%20technically%20possible.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENew%20question...the%20phone%20support%20rep%20indicated%20that%20v2%20of%20the%20API%20resolved%20this%20missing%20message%20data%20issue.%20%26nbsp%3BSounds%20like%20you%20might%20be%20indicating%20that%20that%20isn't%20accurate.%20%26nbsp%3BWould%20you%20confirm%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-81397%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-81397%22%20slang%3D%22en-US%22%3E%3CP%3EThank%20you%20for%20the%20details.%20For%20%231%20and%20%232%20-%20the%20answer%20given%20by%20a%20Yammer%20Support%20Engineer%20on%20%3CA%20href%3D%22%26nbsp%3Bhttps%3A%2F%2Fstackoverflow.com%2Fquestions%2F44523121%2Fyammer-api-get-messages-json-returns-incomplete-results%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3EStackOverflow%3C%2FA%3E%20is%20correct%3A%3C%2FP%3E%0A%3CP%3E%22%3CSPAN%3EThere%20are%20technical%20limits%20on%20the%20number%20of%20items%20that%20will%20be%20returned%20from%20the%20REST%20API%20for%20messages.%20These%20were%20designed%20for%20client%20applications%20that%20need%20recent%20data.%20The%20best%20option%20would%20be%20to%20use%20individual%20calls%20to%20the%20message%20endpoint%20from%20the%20REST%20API%20(api_url%20field)%20to%20fill%20in%20any%20gaps%20in%20your%20archive.%20Make%20sure%20everything%20is%20stored%20in%20a%20persistent%20fashion.%22%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EI%20don't%20expect%20%233%20to%20happen.%20%26nbsp%3BI%20will%20add%20%234%20as%20a%20feature%20request.%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-81126%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-81126%22%20slang%3D%22en-US%22%3E%3CP%3EA%20phone%20support%20rep%20indicated%20to%20me%20that%20a%20%22design%20decision%22%20as%20he%20called%20it%2C%20I%20call%20it%20a%20bug%20around%20downloading%20messages%20has%20been%20resolved%20in%20v2%20of%20the%20API.%20%26nbsp%3BThe%20same%20support%20rep%20indicated%20that%20yammer.com%20is%20already%20running%20on%20v2%20of%20the%20API.%20%26nbsp%3BI%20asked%20when%20v2%20would%20be%20made%20available%20to%20developers%2C%20and%20the%20support%20rep%20didn't%20know.%20%26nbsp%3BI%20also%20asked%20him%20where%20I%20might%20signup%20for%20updates%20so%20I%20could%20be%20one%20of%20the%20first%20to%20know%20when%20v2%20would%20be%20released%2C%20the%20support%20rep%20didn't%20know.%3CBR%20%2F%3E%3CBR%20%2F%3EWhat%20would%20I%20like%20in%20v2%3F%3CBR%20%2F%3E1.%20Download%20all%20messages%20with%201%20request.%3CBR%20%2F%3E2.%20%26nbsp%3BIf%20not%20%231%2C%20then%20make%20the%20GET%26nbsp%3Bmessages%20endpoint%20work.%20%26nbsp%3BRight%20now%20it%20randomly%20ommits%2040%25%20of%20the%20data.%20%26nbsp%3BThis%20is%20the%20bug%20I%20report%20on%20Stackoverflow%20and%20by%20phone%20and%20was%20told%20this%20was%20a%20%22design%20decision%22.%3CBR%20%2F%3E3.%20A%20higher%20messages%20per%20request%20and%26nbsp%3Bhigher%20rate%20limit%20would%20be%20nice!%3CBR%20%2F%3E4.%26nbsp%3BIn%20the%20export%20API%20it'd%20be%20nice%20if%20the%20messages.csv%20included%20likes%20data.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-80994%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-80994%22%20slang%3D%22en-US%22%3E%3CP%3EVictor%20-%20any%20Yammer%20Platform%20updates%20are%20shared%20on%20the%20dev%20blog%3A%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fdeveloper.yammer.com%2Fblog%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdeveloper.yammer.com%2Fblog%3C%2FA%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-80993%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-80993%22%20slang%3D%22en-US%22%3E%3CP%3EBen%20-%20What%20are%20you%20looking%20for%3F%20(from%20a%20V2)%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-80354%22%20slang%3D%22en-US%22%3ERe%3A%20API%20V2%20Release%20Date%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-80354%22%20slang%3D%22en-US%22%3EIs%20there%20a%20place%20where%20the%20V2%20updates%2Fchanges%20are%20posted%3F%3C%2FLINGO-BODY%3E
Ben Hudson
Occasional Contributor

When will v2 of the API be release to developers?

15 Replies
Is there a place where the V2 updates/changes are posted?

Ben - What are you looking for? (from a V2)

Victor - any Yammer Platform updates are shared on the dev blog: https://developer.yammer.com/blog

A phone support rep indicated to me that a "design decision" as he called it, I call it a bug around downloading messages has been resolved in v2 of the API.  The same support rep indicated that yammer.com is already running on v2 of the API.  I asked when v2 would be made available to developers, and the support rep didn't know.  I also asked him where I might signup for updates so I could be one of the first to know when v2 would be released, the support rep didn't know.

What would I like in v2?
1. Download all messages with 1 request.
2.  If not #1, then make the GET messages endpoint work.  Right now it randomly ommits 40% of the data.  This is the bug I report on Stackoverflow and by phone and was told this was a "design decision".
3. A higher messages per request and higher rate limit would be nice!
4. In the export API it'd be nice if the messages.csv included likes data.

Thank you for the details. For #1 and #2 - the answer given by a Yammer Support Engineer on StackOverflow is correct:

"There are technical limits on the number of items that will be returned from the REST API for messages. These were designed for client applications that need recent data. The best option would be to use individual calls to the message endpoint from the REST API (api_url field) to fill in any gaps in your archive. Make sure everything is stored in a persistent fashion."

 

I don't expect #3 to happen.  I will add #4 as a feature request. 

 

RE:  #1 and #3
It was worth a shot.

 

RE: #2
We're trying to download data for all of our messages.  Best I can tell the API is randomly ommitting 40% of the messages.  How is one supposed to programatically know which 40% is missing and thereby what requests of the API will retrieve that missing 40%?  I don't believe it is technically possible.

 

New question...the phone support rep indicated that v2 of the API resolved this missing message data issue.  Sounds like you might be indicating that that isn't accurate.  Would you confirm?

I have been trying nearly the same thing i.e. to GET all messages from Yammer REST API using endpoint messages/sent.json, and I cannot tell you how bumpy this journey has been ! First of all there is no mention of batch size being 20 apart from a casual reference "For example, if you’re currently viewing 20 messages ". Then I found out that "limit" doesn't work as expected - It'll give you anything less than 20 but nothing larger than 20. I somehow fixed it by making sequential AJAX calls and switching to Yampy (Python SDK) from JS SDK so that I can GET message array having length more than 20 by finding oldest message ID and then making sequential calls until GET API returns message array of length zero !

Currently, I am also stuck with random missing data from the GET API - is there any work-around for this ? I haven't yet tried this, but I thought of a way to store all the thread_id in a hash-set and then making GET request to messages/in_thread/threadID.json by iterating over that hash-set. However, with this way I presume that rate limits will bind my hands down.

Please let me know if you can think of a better solution for this.
Hi Ben, just in case it might be helpful to you - I have a little lead in figuring out what 40% data omission means - and how it can somehow be a "design decision".
Yammer API "collapses" the threads so that we only get to see the latest entry on a specific thread and only that latest entry is retrieved from the messages GET API. If we look at the meta-data of the message object, we'll find that the "replied_to_id" has thread_id of the original post (original post has thread_id = message id and replied_to_id = null). So my solution is to store all the thread_id in a hash-set and then find all messages in a specific thread by making calls to messages/in_thread/threadID.json. By iterating over entire hash-set of thread_id, we can GET all messages. However, there is a catch to this - RATE LIMITS.

Would appreciate any help/advice on this.

Vimanyu on my current path I'm using the export API to get all of the messages, then I'm looping through each message using the https://www.yammer.com/api/v1/users/liked_message/:Message_id.json to get the like data.  The rate limit is painful as you'd expect.  Also, the CSV formatting from the export API is poorly formed, which has complicated this effort, but it does appear to be doable.

It's great to see this discussion, and the shared advice from the devs in our Yammer community.

It would help me to go up a level, to understand the use case(s) you're building for.  Please post your use cases/user scenarios. Thanks!

- Sabra, Yammer Platform Team

Gotcha !
Please correct me if I'm wrong, but I presume that you are running the export API in some cron job to update the database periodically. I am actually building an app which crunches data in real time from yammer, so the export API path might not be useful for me :(

Is the /export API also omitting the data ? (I am currently using Yammer OAuth which is omitting the data)

In my case I'm on a team within my company who's goal is to improve internal communication.  Yammer is a big part of our plan.  As such I am exporting all of the message data out of Yammer into our Business Inteligence platform (DOMO) to be able to dig into the data and measure KPI over time.  We can't get meaningful BI out of the Yammer data with 40% of the data missing.  So, that's what I've been working to solve for.

I am using the Yammer Export API to download message data on a nightly basis.  The Yammer Export API does not ommitt any messages, and you can pull all messages in one request.  But, the Yammer Export API does not include Likes data for each message.  So, if you want Likes data, you'll have to work with the Yammer API.

Highlighted
Seems there's no info on release dates there - unless I'm using search wrong. Also, V2 should include views, likes per message, and likes with a datestamp! Why? When you measure "user activity" it would be nice to know the relation between views, likes, and replies. We want to measure the activity of likes and views over a given timeframe as well. Yes, I've seen the aggregate data in the O365 admin console, but it doesn't give us data you can actually use.

I want to be able to answer:

"Hey, how many people visited our group this month?"
"How many people viewed this message posted by our CEO vs if the same message posted by ME"
"Are people more prone to like a message when a hashtag is included?"
"How many likes does it take to get the the center..." - well maybe not this one.

Any update on V2 release and documentation ? I only can find v1 documentation

Related Conversations