Linkedin Ads API What's the format of the `dateRange` request parameter? - rest

What's the right format for dateRange for rest-li v2?
The current examples in the documentation do not support it, and I don't understand from the rest-li documentation what's the format for it, exactly.
This is the request I make:
Headers:
X-Restli-Protocol-Version: 2.0.0
Authorization: Bearer <token-here>
URL (with request parameters):
https://api.linkedin.com/v2/adAnalyticsV2?q=analytics&pivot=CAMPAIGN&dateRange.start.day=1&dateRange.start.month=1&dateRange.start.year=2017&timeGranularity=DAILY
OR
URL - deconstructed (with request parameters):
Base URL:https://api.linkedin.com/v2
Params:
q:analytics
pivot:CAMPAIGN
dateRange.start.day:1
dateRange.start.month:1
dateRange.start.year:2017
timeGranularity:DAILY
Error I get:
{
"serviceErrorCode": 100,
"message": "Unpermitted fields present in PARAMETER: Data Processing >Exception while processing fields [/dateRange.start.day, /dateRange.start.month, >/dateRange.start.year]",
"status": 403
}
Note: I'm referred to a question with the same error in the comments, however this might be caused by a different reason, and the answer there does not work for me. If by StackOverflow's standards you still think that it's a duplicate, please let me know and I'll close this question.

The first solution didn't work for me. As Linkedin's API documentation is shit in regards to this it took me a lot of trial and error. #Gal-Grünfeld final structure is correct but the example isn't. Linkedin's docs say the key is dateRange.start which is wrong.
dateRange=(start:(day:1,month:9,year:2020))

Solution provided by one of the LinkedIn developers:
For Restli version 2, for parameter dateRange (tested only for endpoint AnalyticsV2):
rangeDate := (start[,end]) (end is optional)
start, end - type: Date
Date := (day, month, year)
day - type: integer (tested for single digit only)
month - type: integer (tested for single digit only)
year - type: integer (tested for 4 digits only)
Final structure (not including the optional end):
dateRange=(start:(day:,month:,year:))
Example:
dateRange=(start:1,month:1,year:2017)

When you are using Python and requests, the working format of 'dateRange' parameter is:
params = {
'q': 'analytics',
'dateRange.start.day': '1',
'dateRange.start.month': '1',
'dateRange.start.year': '2022',
'pivot': 'COMPANY',
'timeGranularity': 'DAILY'
}
But remember to remove (or not use at all) the header "X-Restli-Protocol-Version"

Be careful about the query parameter encoding, I am using Faraday library for HTTP get requests and it encodes the query string, so I am correctly using the dateRange=(start:(day:1,month:9,year:2020)), but at the end Faraday encodes it to something like this: dateRange%3D%28start%3A%28day%3A1%2Cmonth%3A9%2Cyear%3A2020%29%29. But linkedin expects the first brackets unencoded, I had same problem with other endpoint, where the List(something) was not working, but with curl it was working, the difference is encoding.

Related

What is the format for the minTime URI parameter in the VSTS REST API, Builds - List?

Given a VSTS REST API call like this:
https://*account*/*project*/_apis/build/builds?definitions=2&minTime=????queryOrder=startTimeDescending&api-version=4.1
What is the correct datetime format for the minTime value? Everything I have tried either returns all builds, or none, and is not filtering by date. For example, I have tried "31/08/2018", "2018-08-31T12:01:31.450Z", "08/31/2018". The format is not documented anywhere that I can see.
The format for minTime should be YYYY-MM-DD.
So the request URL looks like:
https://marinaliu.visualstudio.com/Git2/_apis/build/builds?definitions=41&queryOrder=queueTimeDescending&minTime=2018-09-01&api-version=4.1
Note: when you specify minTime in the request url, it's not working to specify queryOrder with startTimeDescending. Instead, you can remove &queryOrder=startTimeDescending from url, or you can replace with queueTimeDescending.
&minTime=2022-04-18T00:00:00&maxTime=2022-04-19T23:59:00
This also worked for me with time component in addition to date component.

Creating Group categories - D2L Valence

I am attempting to dynamically create a group category with in a course using the following service:
[/d2l/api/lp/(version)/(orgUnitId)/groupcategories/ \[POST\]][1]
The following is the GroupData (Group.GroupData in Create form) JSON block that I am sending to this service:
{
"Name": "New Group Category",
"Description": {
"Content": "",
"Type": "HTML"
},
"EnrollmentStyle": 0,
"EnrollmentQuantity": null,
"AutoEnroll": false,
"RandomizeEnrollments": false,
"NumberOfGroups": 5,
"MaxUsersPerGroup": null
}
I am making the call with the user context of a administrative "Utility" account. I have 2 test courses, both of which I have confirmed I am able create the category through the web interface using this utility account.
My problem is I am having mixed results depending on the course that I try to create the category in. In one course the course returns 200-OK, in the other it returns 403-Forbidden.
Here are the (simplified) requests :
Call 1
/d2l/api/lp/1.4/350110/groupcategories/
Result: 403-Forbidden
Call 2
/d2l/api/lp/1.4/19988/groupcategories/
Result: 200-OK
The only difference is the OrgUnitID. Version, JSON, and user context are all the same, yet I'm getting 2 different results. I have tried with several other courses and again, I have success in some but not all; always receiving a 403 as the error.
After some investigation, I believe I have found 2 distinct differences between courses that are successful and those that return 403.
Courses created just before April 2012 are successful, anything afterwards fail
Courses with a 5 digit Org Unit ID are successful, anything with 6 digits seems to fail.
So my thoughts are we either applied a patch late march / early April of 2012 which somehow changed how courses are flagged on creation, OR somehow only 5 digits (or less?) Org IDs are being accepted by the service.
I'm hoping someone could provide some insight or verify they have no issue with 6+ digit OUIDs and group category creation.
Further reviewing the documentation on API Responses - Disposition and error handling I realized that there are 3 possible cases for a 403 response:
Response body contains Timestamp out of range
Response body contains Invalid Token
application or calling user context does not have the permissions required for the attempted action
Given this, I took a closer look at the response header and realized the issue was actually #2 "Invalid Token", not #3 as I was assuming.
Investigating my code further it seems the user defined SHA256 function I was using was producing an incorrect HASH/Signature when the data being hashed was exactly 55 characters long (yes I realize how crazy this sounds). The temporary work around is to pad my OrgIDs with leading zeros, so my request would actually look something similar too:
/d2l/api/lp/1.4/00350110/groupcategories/
Thankfully, this seems to work, and is acceptable for the immediate future. Long term solution will be to replace my SHA256 function with something more reliable.
I am using Colfusion 7MX for my development, which does not have a native SHA256 Hash function, hence the use of the user defined function.

How can I get multiple %-encoded parameters into an apiary URI template?

The ApiaryIO spec—actually the RFC to which it points—indicates that you cannot use "." in a parameter name, you need to encode it to "%2E". That's fine, but there seems to be a bug where Apiary can only handle one such encoding. For example, the following
## Notes Collection [/notes{?foo%2Ebar}]
yields the following Code Example
request = Request('http://private-d1ee7-testingnewapiary.apiary-mock.com/notes?foo.bar=foo.bar')
which is correct. However, the following
## Notes Collection [/notes{?foo%2Ebar,baz%2Ebla}]
yields this Code Example:
request = Request('http://private-d1ee7-testingnewapiary.apiary-mock.com/notes?foo%252Ebar=foo%252Ebar&baz%252Ebla=baz%252Ebla')
Notice how in the first the Code Example you see it has "foo.bar" but in the second example it has "foo%252Ebar", which is incorrect.
The downstream effect here is that the incorrect URI is sent to the API server so the response is malformatted creating an error.
How do I encode many "."-containing parameters on the URI template and still get the proper code examples?
Will adding explicit example values for those parameters help?
For example:
## Notes Collection [/notes{?foo%2Ebar,baz%2Ebla}]
+ Parameters
+ foo%2Ebar (`42`)
+ baz%2Ebla (`24`)
Update
This seems to be a bug in the way the documentation / code samples are rendered. I have created the tracking issue here https://github.com/apiaryio/language-templates/issues/36.

getting unexpected invalid filter.created_at[from] error message

I'm making this kind of SoundCloud API request:
https://api.soundcloud.com/tracks.json?q=electro&limit=10&client_id=<my-client-id-that-I-removed-intentionally>&created_at%5Bfrom%5D=2014%2F11%2F24%2012%3A03%3A04&offset=0
and since recently, I'm getting this response:
code: 400,
body:
{"errors":[{"error_message":"invalid filter.created_at[from] value: '2014/11/24 12:03:04'"}]}
My request should be fine, according to the official documentation:
https://developers.soundcloud.com/docs/api/reference#tracks
Could you please tell me if I'm doing something wrong?
Thanks for the support in advance.
The problem is in the date format. The docs say dashes should be used in dates:
created_at[from] date (yyyy-mm-dd hh:mm:ss) return tracks created at this date or later
So it will work when you specify the date like this: 2014-11-24 12:03:04 (not with slashes).
We at SoundCloud recently changed the behaviour of the API to return errors for all kinds of for invalid input in filters in order to be clearer about what is allowed and what can be expected.

Search Facebook events and pagination (Graph API)

I am requesting this page to get the events with the keyword
"conference":https://graph.facebook.com/search?q=conference&type=event
This works fine.
The problem is the pagination returned:
"paging": {
"previous":"https://graph.facebook.com/search?q=conference&type=event&limit=25&since=2010-12-18T17%3A00%3A00%2B0000",
"next":"https://graph.facebook.com/search?q=conference&type=event&limit=25&until=2010-11-04T16%3A29%3A59%2B0000"
}
It seems to have more events with "conference", but requesting these 2 pagination URLS returns no data.
It's weird because it's the same for any requested keyword, and the pagination URLs returned by the Facebook API seems to always returns empty data.
Does anyone know what's the issue?
Thanks
I encountered similar confusion with a query against places. The "next" URL behaved exactly as you described it.
I could query location information using a url like this:
https://graph.facebook.com/search?access_token=INSERT_TOKEN&type=place&center=55.8660,-4.2715&distance=150&limit=10
And got back JSON with the first 10 places plus the following fragment which suggests the existence of paging params:
"paging": {
"next": "https://graph.facebook.com/search?access_token=INSERT_TOKEN&type=place&center=55.8660\u00252C-4.2715&distance=150&limit=10&offset=10"
Hitting that URL doesn't work. But I did figure out a combination of limit and offset params that gave me effective paging.
limit=10 & offset not defined => first 10 results
limit=20 & offset=10 => next 10 results
limit=30 & offset=20 => next 10 results
limit=40 & offset=30 => last 8 results (can stop here because less than 10 back)
limit=50 & offset=40 => confirmation that there are no more results
I realise that I've got "limit" and "offset" rather than the "limit" and "until" params that you get, but, hopefully you could apply the same technique i.e. keep incrementing the limit and inc the date/time to that of your last result?
I think this is a standard practice in Facebook Graph API. I think if your request resulted to a non empty JSON, they will always give you the next paging, even though it might be empty.
I am however not 100% sure, because Facebook Graph API does not seem to be very well documented... (for example they said we can modify this pagination thing but did not explain clearly how to do it).
Seems facebook has changed it recently.
Here's the fix:
For a datetime returned in next and previous as
"2011-01-18T08\u00253A42\u00253A35\u00252B0000",
replace all occurrences of "\u0025" with "%" and it should work fine.
If you notice the facebook's datetime format, it is
2011-01-18T08:42:35+0000
(date accepted by strtotime C function)