Is it possible to retrieve a list of usernames from some sort of GET statement of a public account?
I've seen many websites reference followers of a public account, but after reading through the IG API Documentation it says the account needs to be authenticated.
What other ways of retrieving an public accounts followers are there?
Thanks, and I apologize if any of my terminology isn't correct.
You can do somethings without authentication.
some endpoints don't require a access_token.
for example:
GET/users/user-id
if you pass any valid id you will receive something like that:
{
"data": {
"id": "1574083",
"username": "snoopdogg",
"full_name": "Snoop Dogg",
"profile_picture": "http://distillery.s3.amazonaws.com/profiles/profile_1574083_75sq_1295469061.jpg",
"bio": "This is my bio",
"website": "http://snoopdogg.com",
"counts": {
"media": 1320,
"follows": 420,
"followed_by": 3410
}
}
and to retrieve a list of usernames you can you send a request to GET/users/search https://instagram.com/developer/endpoints/users/#get_users_search
It also doesn't required a access_token
if you already have the user-id and would like to retrieve followers and following you can do it without a access_token too
just send a request to
GET /users/user-id/follows
and/or
GET /users/user-id/followed-by
you also can test your request on this website: https://apigee.com/console/instagram
enjoy :)
Related
I have had my API Integration promoted to my Production environment for a few weeks now and all is well but I ran into a new issue that I need help understanding. The process is setting up impersonation. The hierarchy of the organization is relatively simple:
My Integration was built under Company A and so far 100% of Company A accounts are able to be impersonated as expected. The issue came up when Company B was added to the Organization and one of the existing accounts was included in the list to be impersonated. The following message is what I am getting back from my API call.
I have Organization Admin permissions as well as Admin permissions on all of the Company Accounts too and this message appears even for me. My feeling is this is a simple administrative function to grant the User in Company A the permissions to access either a User in Company B or all of Company B. I am just not seeing where this gets setup. I hope anyone can point me in the right direction on this one.
=== 07/06/2022 - Adding additional details ===
/oauth/userinfo respose...
{
"sub": "xxxxx-xx-xx-xx-xxxxx",
"name": "Greg Miller",
"given_name": "Greg",
"family_name": "Miller",
"created": "2017-11-10T18:26:23.583",
"email": "greg.miller#companyA.com",
"accounts": [
{
"account_id": "xxxxx-xx-xx-xx-xxxxx",
"is_default": true,
"account_name": "CompanyA",
"base_uri": "https://###.docusign.net",
"organization": {
"organization_id": "xxxxx-xx-xx-xx-xxxxx",
"links": [
{
"rel": "self",
"href": "https://account.docusign.com/organizations/xxxxx-xx-xx-xx-xxxxx"
}
]
}
},
{
"account_id": "zzzzz-zz-zz-zz-zzzzz",
"is_default": false,
"account_name": "CompanyB",
"base_uri": "https://###.docusign.net",
"organization": {
"organization_id": "zzzzz-zz-zz-zz-zzzzz",
"links": [
{
"rel": "self",
"href": "https://account.docusign.com/organizations/zzzzz-zz-zz-zz-zzzzz"
}
]
}
}
]
}
Additional Info Added 07/07/22
Both Company A and Company B base_uri designation is the same "https://na2.docusign.net"
This is the /oauth/userinfo data returned using the JWT created for the Company B user account I am trying to impersonate.
{
"sub": "xxxxx-xx-xx-xx-xxxxx",
"name": "Company B",
"given_name": "CompanyB",
"family_name": "XYZ TEAM",
"created": "2021-03-31T18:20:05.23",
"email": "xyzteam#companyb.com",
"accounts": [
{
"account_id": "xxxxx-xx-xx-xx-xxxxx",
"is_default": true,
"account_name": "Compan B",
"base_uri": "https://na2.docusign.net",
"organization": {
"organization_id": "xxxxx-xx-xx-xx-xxxxx",
"links": [
{
"rel": "self",
"href": "https://account.docusign.com/organizations/xxxxx-xx-xx-xx-xxxxx"
}
]
}
}
]
}
The steps I take are basically the same as you outline:
Generate JWT Access Token
I am manually storing the required userinfo data userID(sub) and base_uri in a local db table.
I am using CURL to make my API calls " $base_uri.'/restapi/v2.1/accounts/'.$AccountID.'/views/console'"
You have two choices for accessing data in Company B (Account B):
Add the user in Company A (Account A) to also be a user in Account B. (Users can have memberships in more than one account.)
To access the data in Account B (Company B), impersonate a (different) user who is in account B. This is done via the eSign Admin app or via the Org Admin app.
By design, a user who is not in Account B cannot access any data in Account B. (This is the error message you're receiving.)
Note: you do not need to make any changes to your app's integration key (client ID)--all client IDs in production can be used with any user, with any account the user has access to.
To see which accounts the current user has access to, use the /oauth/userinfo API method.
Added
When you get the message User does not have a valid membership in this account check:
What account is the request using? (What is the URL of the request?)
Was the request sent to the right base url for the account?
What result does the current access token provide when calling the /oauth/userinfo API method.
Your test API calls should be:
Get an access token
Call /oauth/userinfo
Call the eSign API (eg list envelopes or somesuch) for each of the accounts listed in /oauth/userinfo
From the WebHook documentation for a store/customer/address/updated/store/customer/address/created events should have following payload:
{
"scope": "store/customer/address/created",
"store_id": "1025646",
"data": {
"type": "customer",
"id": 60,
"address": {
"customer_id": 32
}
},
"hash": "416ca9c01779515de91824aa1cac9012ee691e7a",
"created_at": 1561481620,
"producer": "stores/{store_hash}"
}
However, in the logs we don't see the "address" part. The payload is always coming as:
{
created_at: 1573847377
data: {
id: 2246136
type: "customer"
}
hash: "%hash%"
producer: "%producer%"
scope: "store/customer/address/updated"
store_id: "%storeid%"
}
And the payload.data.id is not the customer id, as fetching customer by given ID always results in 404.
Fetching address with given id is also impossible, as the resource url should include customer_id which is absent in the response.
Contacted BigCommerce support already, but maybe someone had solved this issue already?
Saw relevant question in the BigCommerce's community, but it was also unanswered.
I have encountered a similar problem, and believe I have isolated the conditions under which it occurs.
I am building an app with MEAN stack that uses bigcommerce API/webhooks.
When I tried to create a customer address in-app, it makes an API request to BigCommerce and creates customer addresses in BigCommerce. Via the webhooks, I have implemented the store_customer_address_created hook event.
So there are two cases when the address webhook event is being triggered:
When the customer address is created in-app and it sends an address creation request via the API to BigCommerce.
When the customer address is directly created in the BigCommerce admin.
Here are the responses from those:
"scope": "store/customer/address/created",
"store_id": "1025646",
"data": {
"type": "customer",
"id": 60,
},
"hash": "416ca9c01779515de91824aa1cac9012ee691e7a",
"created_at": 1561481620,
"producer": "stores/{store_hash}"
}
{
"scope": "store/customer/address/created",
"store_id": "1025646",
"data": {
"type": "customer",
"id": 60,
"address": {
"customer_id": 32
}
},
"hash": "416ca9c01779515de91824aa1cac9012ee691e7a",
"created_at": 1561481620,
"producer": "stores/{store_hash}"
}
As you can see, the address field is not included when the customer address is being created by the API. I’m not sure if it is designed by the BigCommerce team, or a special case. But I think we can identify if the customer address is being created by the BigCommerce admin directly or via the API myself based on this distinction.
I believe you are encountering the first case on your end.
I hope this helps and please update me if you have any other opinions.
It is fairly strange to see this webhook response without the address field, and I haven't had any luck replicating this with scope for store/customer/address/updated. Are you working with any other code beyond this webhook or testing the webhook event specifically?
I am using the Graph API to get details from business users. Since most of the Profile is Non-Business, would like to find-out, if there is an API to get the Profile Type?
During the trial, I keep getting the following message and also discovered sometime the API is misbehaving..
{
"error": {
"message": "Invalid user id",
"type": "OAuthException",
"code": 110,
"error_subcode": 2207013,
"is_transient": false,
"error_user_title": "Cannot find User",
"error_user_msg": "The user with username: rohit_xxx cannot be found.",
"fbtrace_id": "FkKgUvBdJWZ"
}
}
So, If I know the Profile Type in advance, We can handle the response in much better way..
Thanks in Advance..
The instagram Graph API is designed to work with creator/business accounts. This is specified in multiple places.
If a user doesn't have business/creator account, the instagram id would be empty in the response.
curl -i -X GET \
"https://graph.facebook.com/v3.2/{fb-page-id}?fields=instagram_business_account&access_token={access-token}"
Response:
{
"instagram_business_account": {
"id": "" // Connected IG User ID
},
"id": "134895793791914" // Facebook Page ID
}
I have a service account that is using DocuSign's polling to retrieve a list of envelopes that had a status change. These envelopes were sent by various internal users. When I go to retrieve the envelopes, I'd like to retrieve who the sender of the envelope is (sender's name and email).
I initially excepted this information to be part of the Envelope object, but it's not:
Envelope envInfo = envelopesApi.GetEnvelope(AccountId, envelopeId);
I've tried various other API calls and reviewed documentation, but none of them seem to provide a way to get the sender's name and email.
Can this information be retrieved?
There actually is a way that you can get Sender Name and Email for an Envelope via the API. First, issue a Get Envelope Audit Events request to identify the UserId of the Sender. Then, use that UserId to issue a Get User request to obtain the sender's name and email address. Here are the steps, with sample requests/responses (irrelevant info omitted, for brevity):
1) Get Envelope Audit Events
Request:
GET /accounts/{accountId}/envelopes/{envelopeId}/audit_events
Response:
{
"auditEvents": [
{
"eventFields": [
...
{
"name": "UserName",
"value": "John Doe"
},
{
"name": "UserId",
"value": "af465e97-83a6-472c-a25b-ebad10e4cc6a"
},
{
"name": "Action",
"value": "Registered"
},
{
"name": "Message",
"value": "The envelope was created by John Doe"
},
{
"name": "EnvelopeStatus",
"value": "created"
},
...
]
},
...
]
}
2) Get User (specifying the UserId from the previous response)
Request:
GET /accounts/{accountId}/users/af465e97-83a6-472c-a25b-ebad10e4cc6a
Response:
{
"userName": "John Doe",
"userId": "af465e97-83a6-472c-a25b-ebad10e4cc6a",
"email": "john.doe#test.com",
"firstName": "John",
"lastName": "Doe",
...
}
Another option (if you're creating the Envelopes with the API to begin with) would be to always specify "Custom Envelope Fields" for each Envelope at creation-time that contain the sender's name and email address. Doing it this way would let you retrieve this info with the same request you're already issuing to retrieve the envelope info (provided that you include the extra querystring parameter (include=custom_fields):
GET accounts/{accountId}/envelopes/{envelopeId}?include=custom_fields
DocuSign does not work in this way, as envelopes are linked to a user and its user's documents so no one can access the document until and unless user shares the envelopes with anyone. So there are no APIs which will inform you the sender email/name by querying DS on envelopeId. You have two ways to achieve this requirement:
Use DS Connect (recommended way), configure Connect in your DS
Account and DocuSign will push the connect messages with the sender
details in that XML message when a subscribed trigger event occurs
Another way is you need to get OAUTH access token of all your users and
then call DS APIs to know the envelopes for each user
Connect message will look like below:
<UserName>Sender Name</UserName>
<Email>SenderEmail#email.com</Email>
Can someone tell me how to get the distributorPassword or an AppToken for a demo account?
I am trying to use the Create Account call (https://demo.docusign.net/restapi/v2/accounts) in the Docusign REST interface. This call requires a distributorCode and distributorPassword. These don't appear to be the same as the Username, Password, and IntegratorKey used for the other REST calls.
It looks like you can retrieve the distributorCode and distributorPassword using the Get Account Provisioning call (https://demo.docusign.net/restapi/v2/accounts/provisioning). This call requires an AppToken be supplied in the X-DocuSign-AppToken header. I am using a demo account and haven't been able to find out how to get an AppToken for this account.
The REST call Get Account Info (accounts/:accountId) appears to also return a distributorCode and distributorPassword but when I call it using my accountId I get a distributorCode (DEVCENTER_DEMO_APRIL2013) but not a distributorPassword.
Get Account Info response:
{
"currentPlanId": "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"planName": "DEVCENTER_DEMO_APRIL2013",
"planStartDate": "2014-09-05T22:44:35.8230000Z",
"planEndDate": "2015-09-05T22:44:35.8230000Z",
"billingPeriodStartDate": "2014-09-05T07:00:00.0000000Z",
"billingPeriodEndDate": "2014-10-05T07:00:00.0000000Z",
"billingPeriodEnvelopesSent": "0",
"billingPeriodEnvelopesAllowed": "unlimited",
"billingPeriodDaysRemaining": "27",
"canUpgrade": "false",
"canCancelRenewal": "false",
"envelopeSendingBlocked": "false",
"envelopeUnitPrice": "$0.00",
"suspensionStatus": "",
"accountName": "xxxxxx",
"connectPermission": "full",
"docuSignLandingUrl": "http://www.docusign.com/products/sign_up/buy_now.php",
"distributorCode": "DEVCENTER_DEMO_APRIL2013",
"accountIdGuid": "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"currencyCode": "USD",
"forgottenPasswordQuestionsCount": "1",
"paymentMethod": "purchase_order",
"createdDate": "2014-09-05T22:44:35.7270000Z"
}
According to DocuSign, the distributorCode and distributorPassword will be issued to the owner of the DocuSign account once you sign up. They are different from your username, password and integrator key.
Then you can add them as extra header in your calls to their REST API using this format:
X-DocuSign-Distributor: <DistributorCredentials><DistributorCode>DocuSign</DistributorCode><Password>xxxx</Password></DistributorCredentials>