Branch.io links missing analytics parameters (campaign, channel, feature, etc.) - branch.io

I created a Branch link and left all the analytics parameters empty (i.e. I did not specify campaign, channel, feature, etc.). On my website, I then use that link and append parameters as necessary:
http://example.com/XXXXXXXX?~campaign=mycampaign&~feature=myfeature&~stage=mystage&~tags=tag1,tag2&matchType=m&network=n&placement=1&adposition=1&device=d&url=some-url
Up until recently, the Branch Web SDK provided me with all these parameters. Now, ~campaign and the rest of these params are no longer in the data_parsed object that's returned. What happened?? Why does data_parsed not have these?
Side note: The ~referring_link value returned by Branch is correct. It shows the full link as specified above.

The five default link parameters (Campaign, Feature, Channel, Stage, and Tags) cannot be overwritten on existing links by appending query parameters. This helps prevent analytics information on a link from being altered after the link has been shared (with an ad network, for example).
This will work for new links, however, which you can create by appending query parameters to your default link domain. If your default link domain was "example.app.link," for example, tapping on the following link would cause a new Branch link created with channel, feature, and campaign set:
https://example.app.link?channel=facebook&feature=sharing&campaign=winter
So you are basically doing this correctly, but you need to append your query parameters to the default link domain and not an already-existing link.

Related

Share dynamic content on LinkedIn

I have a JS based CMS that populates a single page with different content based on URL parameters passed to the page. I am using the shareURL format (https://www.linkedin.com/shareArticle?mini=true&url=''&title=''&summary=''&source='')
But the parameters I pass are never used it always falls back to what is being served directly from the server.
Do I have to use the API to make this work and if so can I use the API without making the user authenticate?
Is there a correct way to pass this so that linked in will display the correct data.
After testing this more I realised that the linked ins share URL does not take its parameters it only takes what is served from the server. So I changed my build process not to get the pages in run time but to precompile them onto the server. Maybe in the future linked in will have resolved this for dynamic pages.

Direct URL to Evernote notebook, note and tag

Our product (Yoke.io) integrates Evernote through REST API. We need to generate direct URL link to a specific notebook, note or tag so that user can click the link to access them.
However, current URL format contains parameters named "ses", "sh" and "sds" in addition to the ids for notebook/note/tag. I have no idea what these parameters mean and if they are different for different users, platforms, etc.
For example, if I want to access a notebook with id "3ec5f3c1-bd4d-4f94-b924-367b13eaf3bc", and generate the following links:
https://www.evernote.com/Home.action#b=3ec5f3c1-bd4d-4f94-b924-367b13eaf3bc
https://www.evernote.com/Home.action#b=3ec5f3c1-bd4d-4f94-b924-367b13eaf3bc&ses=4&sh=1&sds=5&
The first link (#1) won't work but the second link (#2) works.
I could hard-code "ses", "sh" and "sds" parameters in the URL but my feelings is that these parameters will change for different users.
Could anyone explain more on what are these parameters for and how I can generate a direct URL link to a specific Evernote notebook/note/tag?
Thanks a lot for your help.
Regards,
Tao
ses, sh and sds are hash parameters we use when serializing the state of the web client. If you try manipulating the hash parameters to get the web client into a certain state, note that these are undocumented APIs and are subject to change at any time. That said, they won't change super often.
None of those three parameters will change on a per-user basis, they represent the "view" of the client you're in at the time. The simplest way to get a url in the format you like is to navigate to that view in the web client, copy the hash, and replace note and/or notebook guids in the url (b for the notebook guid and n for the note guid).

Multiple endpoints to expose different views of the same resource

I'm struggling to find an answer to this (perhaps because I'm not asking the question properly) ...
I'm building API to expose resources for a basic social networking service I'm creating.
My understanding is that the structure of URLs in an API is essentially a hierarchy, directory like structure. I think that means I can have multiple endpoints to reach the same resources or collections of resource links.
For example:
I have an endpoint
www.domain.api.org/users/{:uid}/posts
Which will return all posts sent by the user or that the user is tagged in. Seems ok, but what if I have an endpoint such as:
www.domain.api.org/posts
Which when hit with a http GET will return all public posts (i.e. all users' posts plus his friends' and public posts).
The difference is that the first URL points to user owned resources whereas the second to public ones (of which the users posts are included of course)
Are these okay or am I doing it the wrong / less sensible way?
To reiterate, can I have multiple endpoints which point to different contexts/views of the same resource?
Basically multiple endpoints for the same resources should be avoided. However in this particular case it does make sense.
What you can do is to introduce optional query param userId to the following endpoint:
www.domain.api.org/posts/?userId=<userId>
If this substitutes the first endpoint you mentioned that's the way to go.
I would like to add ontop of #Opal's answer.
Are these okay or am I doing it the wrong / less sensible way?
Ideally, like Opal mentioned, you would use queryParams in your url. For many applications I have build, I don't know the uids returned from the api beforehand, so selecting an item and passing it inside my url as a query parameter makes sense. But it also has the added benefit of having your key inside your url, allowing you to bookmark it, pass the url to another user and they will automatically see the same data you want them to see.
To iterate: Is your current implementation wrong? No, but ideally you would use a combination of both route parameters are query parameters to achieve this
To create an endpoints, you have to be sure that you have these information at once:
Name of the endpoint
Status: activate or not (required) - is the endpoint activated or disable
Service profile (required) - ID of the Service Profile assigned to the endpoint.
Tariff profile (required) - ID of the tariff Profile assigned to the endpoint.
You can add another optional informations, and be sure of the structure of your endpoint.
Hope this helps you.

Adding recipient Groups to a CiviCRM Mailing via REST.. how?

I have been able so far to create a new civi Mailing object and populate it, but confusingly I can't see a parameter in that to specify the mail destination group.
For context, I am dealing with Civi using pure REST api from a remote server. I have a solution to getting a custom template onto the server; the new problem is setting a schedule and delivery group, and initiating the send. I am using the python-civicrm library from github as the intermediary on the client.
I presume send happens as a result of setting the schedule -- i.e. I don't need an API call to say 'send mailing'? Is setting 'sheduled date' == 'now' safe or should I set a date of 'now + 1min' or similar?
So that leaves setting the delivery group. We already have groups defined in the DB, and I want to specify the group by name (and preferably be able to verify in advance that a group name is a valid destination, perhaps by doing a group name -> id lookup).
I think there might be a parameter to Mailing create 'groups' which can have keys 'include' and 'exclude'; at least, that's what the web form seems to do. However it's not mentioned in the REST api implementation.
Can anyone offer pointers?
I think you will find all you need in the following link :
Example of api call that is using the group include/exclude : https://gist.github.com/xurizaemon/6775471
Discussion about implementing mailing as an api - http://forum.civicrm.org/index.php?topic=24075.0
Otherwise, if it doesn't work, i suggest that you :
help adding this api in the CiviCRM Core - you could have some help on this on irc #civicrm (and have a look at https://issues.civicrm.org/jira/browse/CRM-11023)
OR create an extension with the api you need. It will be automatically available for REST. If you haven't created an extension yet, i suggest you go to the page http://wiki.civicrm.org/confluence/display/CRMDOC/Create+a+Module+Extension. It's quite straightforward with civix installed.
The table you need to check in the database is civicrm_mailing_group
To confirm, the problem was that (a) I needed to use groups[include]=array(ids) as mentioned by samuelsov, but also (b) I needed to use the json={...} form of request through REST, because the HTTP params syntax doesn't support nested data.

How can I retrieve a Gitlab Project tag list through the API?

I'm writing a REST client to look at project information available from several gitlab servers at the same time in one consolidated place. I understand REST and am able to pull the project details I need except one: the tags.
I'm not talking about git repository tags, those I'm able to get to just fine. I'm referring to the tags that are set under Project Settings. These are tags that, from what i can tell, are meant to be a form of describing the project, not referencing a particular commit hash.
I submitted a merge request back to the Gitlab folks, if accept, any REST call that involves a Project class will include a "tag_list" field with all the project labels.
The merge request is available here: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/329
EDIT: This was merged in Gitlab version 7.10.0 so now you can just run a GET on the Project and the tag_list will be included with the JSON response.
Try this:
http://www.example.com.br/api/v3/projects/#{str}/repository/tags?private_token=yourtoken"
Note that in #{str} variable, if you using a group/repository structure, you must replace the dash to %2F, for example, you must set:
http://www.example.com.br/api/v3/projects/group%2Frepository/repository/tags?private_token=yourtoken"
The response to your request will be the body. So you can console log response.body to retrieve the tags.
Not possible: ACCEPTING MERGE REQUEST at: http://feedback.gitlab.com/forums/176466-general/suggestions/6325819-project-labels-via-api , so feel free to implement it if you need it.
Should be simple: just return the project.tag_list (see: https://github.com/mbleigh/acts-as-taggable-on) as a JSON list from https://github.com/gitlabhq/gitlabhq/blob/41518a467dcef61deca24ad2f6205c6fd5706e1b/lib/api/projects.rb#L60
Always check the request tracker first for features ;) True, in this case you may have done it an not found because of label vs tag keyword confusion, I think it was renamed at some point, so always search for both.