I have a doubt about real-time Instagram subscription in the API. Can i subscribe to whatever user i want? or there is some restrictions about the users that i want to subscribe?
I arises this doubt because in the Instagram of real time subscriptions page says: Note that this subscription is for all of the client's authenticated users, not just a specific user.
Its means that i can only subscribe the users that have authorithed my app in Instagram??
I have to make an app that consumes the instagram subscriptions and when there is a new photo it automatly saves it in the DB.
Thanks
A few things, first if you use the "user" type, then you are correct it will ping your endpoint any time any user who has authorized your app posts, there is no IG side filter (yet), but you can easily filter on your end once you get the notification. Oddly, I did notice it now sends the media_id of the post (although the docs say it doesn't!?). If users do not authorize your app, then the only way to get notifications is via the other endpoints such as by tag.
I have found some issues though when dealing with "private" users, and some strange filter behavior to watch out for.
A final point, you said you want to save to your db - that could be in violation of their use policy, so be sure to clearly understand what IG's rules are and that you don't break them.
Hope this helps,
P
Related
I have a backend running GraphQL, MongoDB + Mongoose, and Apollo. This application has functionality for user accounts and a friends list. Each user can login to their account and see a list of friends with their current 'status'; If a friend changes their status, I need that change to be reflected on the user's side. An example of this is like facebook's "green dot" on messenger that tells you when one of your friends is online using the application.
I have been searching documentation for GraphQL and have been suggested either Subscriptions or Live Queries. Subscriptions seem to be the majority of suggestions from what I understand, live queries are not officially part of GraphQL or were dropped.
Does anyone have a solution to getting "live" data with GraphQL/MongoDB that doesn't involve polling for this scenario?
You already seem to have your answer: subscriptions!
Using your example, consider two users - mikep17 and mcy. You are mikep17, logged into your application and viewing your list of friends and their statuses. I am your friend, and I log in as you are viewing this list, and you want to see that in your application's UI.
On the frontend, in your application's instance, your application will execute a subscription to some event. Let's call it friendStatusChange. Now your application is "listening" for that event in order to respond accordingly. Let's assume that when your application receives the event, it can parse out the information that "I" (mcy) have changed from offline => online and then use that to add the "green dot" next to my username.
On the backend, your GraphQL server will have code that handles your user functionality - logging in, logging out, etc. It will need to be enhanced to hook into these actions and "publish" the friendStatusChange event as applicable.
Now, instead of your client constantly asking (polling) "did a friend's status change? how about now? now?", it can just listen and wait for your server to tap it on the shoulder and say "hey buddy, your friend mcy's status changed".
I plan to generate Facebook events (Conversion API) on server side when the user completes registration process. These events will be used for advertising my solution in Facebook and tuning target audience on registration events.
I use POST request to https://graph.facebook.com/v9.0/289777498957502/events to send events. I have to pass user_data entity inside a body of this request. This user data can be email address, click id, user IP address or something else.
I don't have any of these on server side but I can get it.
The problem is that I don't understand why Facebook needs user data and what exactly it needs as data. I can send everything to Facebook but I need to understand mandatory information it requires.
Do you know what should be sent as user data?
As an option I can send internal ID in my system of each user inside user data but I'm not sure Facebook will be happy with that.
Facebook manuals are a pure joke. Literally all are outdated and no information on user data content and why it's required.
The problem is that I don't understand why Facebook needs user data
Because your conversion is (ideally) supposed to get connected to an actual user account. Facebook knows, who the user is, as long as we are on the client side, and their pixel is embedded somewhere - they can make the cross-domain requests in the background, to see who is currently logged-in to Facebook on the device. But if you send conversion data later, from your server - how would they be supposed to associate that with a specific user then, if you don’t send them any data that could identify one?
and what exactly it needs as data.
If you have anything that can uniquely identify the Facebook user, then send that.
Otherwise, send as much data as you can – to increase the posibility, that Facebook will be able to match this to a specific individual.
Check the list they provide under https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters
If the user is logged in to your Facebook app while they are on your site, then send the fb_login_id – that is as unique and specific, as can be.
If you don’t use Facebook login on your site, or the user can also perform the action in question without being logged into your Facebook app - then send whatever you have, that identifies them on your end.
In case no unique match is possible, then send as much as possible - first & last name, phone number, date of birth - all those help to narrow down who the user might be on Facebook’s side.
The same data, or at least as much of it as is available at this time, should also be send with the pixel tracking code on the client side already. https://developers.facebook.com/docs/facebook-pixel/advanced/advanced-matching/ has details on that.
My goal is to make a website, in which user could customize a photo and then provide his friends indicators like name or id. My next task is to fetch that info from database and send messages on specific date to provided users. Ex birthday wishes, greetings, and so on.
I studied facebook send api for a few days now and couldn't find solution for myself. If I want to send message, I need to have Page-scoped id of user, which is acquired when the person text you first, which is not desired, because person wouldn't know what it is.
Also I was looking into Customer matching API, also seems to require the same PSID. The next thing I checked was Send Dialog API, which seems to send messages instantly, but not on the specific date. Also I checked unofficial facebook-chat-api, which asks for user ID, whereas I can find my id, I couldn't find ids of my friends.
So I just want to know is it even possible, if yes, I'd really appreciate your help.
User to User communication is not possible (and not allowed) in an automatic way, there is no API for it except for the Send Dialog. The Messenger platform is for page to user communication only.
Do not use inofficial tools, they are not allowed and might get you banned.
I just got starte with programming a Facebook app. I already wrote an app for the VZ-Network, and there they have something called 'Persistant Storage'. Basically its an environment where you can save custom data on each user account. With your app you can read this data from the current user as well as from the users friends. Now I want to port my app to Facebook and my problem is that I didn't find such functionality here yet.
For now I would like to finish and launch this as soon as possible, so it would be nice if I could c&p as much of the code as possible.
Since the data is contains information about participation, at some point I would like to use the Facebook event object. But I was wondering if that could cause problems since it would require to create those events publically in order to use them in my app. Couldn't that lead to legal problems when I create such events with those who actually host the events in the real world? Would I have to ask the hosts to create those events, could I automate this process, or in case they don't have a Facebook account ask them to approve that the app creates the event for them?
I also need to know in what events the users friends participate, so I can't simply save the information on my server, since I don't have the friend info there.
In any case, it seems much easier to me to simply use a list of EventIDs on each user account to check whether or not the user participates in an event.
I hope this is allowed but I have a number of questions regarding Facebook Connect, I'm quite unsure on how I should approach implementing it.
I am working on a live music type service and currently have user registration, etc. If I were to implement Facebook Connect alongside this, would I still be able to email the Facebook Connect users as if they were on my database?
Also, would it instead be possible to let users who have Facebook "link" their accounts once registered so I am able to give them the benefits of sharing via Facebook and inviting friends while still having an actual registered user on my system.
I have tried to read up answers to the above questions but what I've found is quite ambiguous.
Thanks, look forward to your views.
Facebook's documentation process is very poor, so don't feel bad about having a hard time getting started. Their wiki-style approach to documentation without any real official documents tends to leave the "process flow" tough to grasp, and requires piecing together parts of a bunch of randomly scattered docs.
Facebook has an obligation to protect privacy, so they never make a user's actual email address available to application developers, through Connect or normal applications. They do have a proxied email system in place that you can use, however, you must get explicit permission from a user in order to email them. There's a decent document on proxied email here. You can get permission by prompting for it; there's several methods for doing so linked in that document.
In regards to linking Facebook and local accounts, this would definitely be the way to go. Once a Connect user logs in, you want to store that fact for that user so you can provide the Facebook-specific functionality. I would simply create a normal user account in the database for every new Connect user that came by, with it's own local id, so that you don't have to do special handling of two different types of user accounts all over the site. That being said, the account would obviously have to be marked as a Facebook user's account (I use an externalId column in my users table), and any part of the site that relied on information you might otherwise have locally would have to handle the Facebook aspect properly (such as using proxied email instead of normal email).
For existing users, you could arrange an "account link" by having a process whereby they log into FB Connect after they've logged into the site already, and you could detect that and simply add their FB id to your users table. After that, they could log in through Connect in the future, or through your normal process. I've never done this, but it should be possible.
If you write the account handling code generically enough, your site will be able to function well no matter what kind of user you throw at it.