I was looking through the Foursquare API about Venue Events and found out that there is a difference between the documentation and the actual response.
In the documentation (https://developer.foursquare.com/docs/responses/event), it says that there can be fields such as startAt and endAt in the response. It doesn't mention a field called date.
However, when you go to the expolorer (https://developer.foursquare.com/docs/explore#req=venues/40afe980f964a5203bf31ee3/events), you can see that there is a field called date which contains the seconds from Unix epoch.
Is it because the allDay field is set to true?
Regards,
Norbert
Thanks for bringing up this inconsistency in the docs—the date field is there for an all-day event. We'll add this to the documentation.
Related
According to this "Account Updater only works with Visa and Mastercard"
So I want to find customers whose cards are going to expire in the next month and are from a different type than Visa or Mastercard.
In the docs I see I can filter by expiration date, but nothing about cardType (it mentions cardholderName)
var stream = gateway.customer.search(function (search) {
search.creditCardExpirationDate().is("12/13");
});
Is there a way I can filter this in the api request or should I need to get all results and filter out Visa and Mastercard customers?
Thanks.
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
Both you and #michelem are correct: the current api doesn't expose a method for filtering customers based on whether they contain a specific type of card. Your approach of filtering the results based on the Payment method is the best approach.
The GitHub API provides functionality to get stared items sorted by created date. But, I can't find a possibility to get this date.
Only three date-type fields are present in the response:
created_at: '2013-06-13T21:10:36Z',
updated_at: '2013-06-18T07:45:56Z',
pushed_at: '2013-06-17T16:52:44Z',
create_at here is always that date the repository created, not star. updated_at does not give the right information either.
On the GitHub site, if you check your stars, data is sorted properly and the correct time span is rendered. But it looks like the API misses that information.
That gist clearly show, that data returned "sorted", but created_at is wrong.
This can be done in the GitHub API v3 by adding the header:
Accept: application/vnd.github.v3.star+json
see here:
https://developer.github.com/v3/activity/starring/#alternative-response-with-star-creation-timestamps-1
https://developer.github.com/v3/activity/starring/#alternative-response-with-star-creation-timestamps
There is absolutely no way to get this information from the API. Your best chance of getting it is going through events either on the repository or each user that has starred the repository and that could take tons of parsing because the events could be in the thousands. The number of API calls to do so would be immense.
How can a workflow be told to wait until a specific date, or date field?
It works with timeout equals date, but I would much rather use wait until process time is on or after date.
When I try this the workflow is postponed until our distant ancestors have died of old age; it is the same if I put in a date field instead of a specific date (which is the end goal):
You want to consider what is considered a "timeout" for the desired behavior. The following links provide some more context.
Also, unless you have a really specific use case for using a specific date (like year end deadlines or processing) -- you'll probably want to use a datetime field on an entity as the basis for the right side of the comparison. You can always use the dialog on the right to choose a fixed date/time before or after any of the entity datetime fields.
http://social.technet.microsoft.com/wiki/contents/articles/11291.microsoft-dynamics-crm-2011-workflows-wait-and-timeout.aspx
http://www.powerobjects.com/blog/2012/11/06/multiple-waiting-workflows-wait-conditions-and-timeouts/
http://www.dynamicscrmtrickbag.com/2009/07/12/waits-timeouts/
Yes, it will use the current value of the field each time the workflow is checked.
Related: CRM2011 Workflow: What happens if the field which is used in the condition of the workflow is updated after the workflow has started?
I want to know how many check-ins has happened in a particular interval of time (foursquare venue search with startAt and endAt timestamp) at a location. (I have its geo-corrdinates)
So, I am trying to use FourSquare Venue Search with startAt and endAt information. The command works and gives output, but results are same as if without startAt and endAt term.
Example with start and end timestamp, https://api.foursquare.com/v2/venues/search?ll=-34.02977,151.10533&radius=100&startAt=1287421200&endAt=1287428399&limit=50
but the above command give almost the same result as
https://api.foursquare.com/v2/venues/search?ll=-34.02977,151.10533&radius=100&limit=50
1) I am wondering if Foursquare and kept an option to add these parameters and processes them ?
2) Although mentioned on FourSquare's website that all Venue API do not require authentication, "Venue Stats" does (it can solve my problem)
3) any possible solution is welcomed.
startAt and endAt are not supported parameters for venue/search. Granular information about check-in history for a venue are only made available to the venue's manager.
Has there been a change to the core venue field specials?
I'm using Venue Detail request (https://developer.foursquare.com/docs/venues/venues) to retrieve Venue Detail. As usual this request returns a "venue" for a response field.
What seems to have changed is the core venue field "specials". This now appears to be returning the same response fields as Specials/list ( https://developer.foursquare.com/docs/specials/list).
This requires iteration on specials.items as opposed to specials.
Looking at https://developer.foursquare.com/docs/responses/venue the Core venue field "specials" still should be returned as an array.
I'm trying to find in the change log where this may have changed?
The venues specials object is now using the standard count and items format that other lists in the api use.
The new format is only for clientversion 20120120 and later. Older versions get the old format.
We'll be updating the docs/changelog shortly.