Why my Notion API return a 404 status, even though i already connect my Database with my Notion Integration, where am i getting this wrong?
Here's my request via Postman:
request to notion api using database_id
And here's my database id:
database_id
Database connected with my Notion Integration:
database connected with my notion integration
My Notion Workspace connected with my Notion Integration:
workspace connected with my integration
im hundred percent sure already providing the correct bearer token from my integration on my request via postman, why am i getting this error?
I've tried follow allong with the Notion offical documentation guides but it just doesnt work
"Dont believe everything you see on the internet", i just figured it out it's turn out that my Database is actually not a Database when you create add a new page in notion it doesn't mean that you're making a new database.
In order to create a new database in Notion you need to specified that page you just added to behave as a database, at the first place i thought when i add a new page in Notion it'll automatically to behave as a database as i follow along with some tutorial out there.
Related
I'm using Notion API to display a collection of photos in a react app (using graphql).
For that I've created a simple database in notion, with basic information (title, status, tags, category, photo url).
Everything is fine with my test set of data. I can see it in my react app, in graphql (appolo studio), in Postman and in Notion
But I cannot not access new data recently contributed.
Not in my react app and even not in Postman (I can see only the intial set of data).
I've checked the authorizations, everything is clean.
These new data are available in Notion (I can see and edit them).
When I (owner of the project) add a new row, the data is available in postman and in the app.
If I copy and paste a row contributed by my friend, the data is not available.
The additional data was provided by a friend of mine, with a guest status in the project.
So my only finding so far is that there is a limitation on data provided by a guest, even if it seems a bit weird.
Are there any known limitations on Notion API due to the status of the contributor ?
Or are there other limitations that could explain these partial results ?
I'm using django and trying to integrate it with quickbooks online through python-quickbooks package and already did so and it works fine, but the problem is I don't want to store the tokens in the request session because I'm trying to access them outside the views, to be exact I'm trying to send an invoice each time an invoice(invoice model from django) object was made I want to send one to quickbooks and I'm doing this through django signals but I can't access the session from the signals so where is the best place to store them on the server side?
thanks in advance.
You can create new Django model just for your integration and query it when you need to get tokens. Especially it can be useful if you plan to have multiple integrations, you can add relation from object (which is related to signal) to "integration object".
We are working in the office using Oracle APEX to create some web services. After beating our heads against the wall we finally figured out that the terms get & post when talking about RESTful services are not the same as standard HTTP.
We will need to create two types of web services;
In the first, the external application passes a few fields and the method queries a record and sends the data back to the external application.
In the second an external application builds a 30 field record that needs to be inserted by the method into the DB.
In a normal web app we would in both cases typically http post the data to to a cgi (asp, aspx, pl...) page that would parse the fields and do what needs to be done.
Since we have written the new app in APEX, and we would like to join the late 20th century, we thought we would use a web service on the provider side. The consumer will be AS3/flex/flash.
Can we still use the traditional http post and/or http get methodology of defining name=data pairs and send them to the web service?
What we have seen so far is that the data passed (at least in an APEX Restful GET) needs to be positional and not name=data pairs.
I guess the first question is where can we get some basic concepts on how to pass data using "RESTful" get & post? Something aimed at a web service dolt would be good.
Another question is if the HTTP get/post methodolgy can be used, how would it be done in Oracle APEX v5.0?
There is a lot of questions inside your post, perhaps if you narrow it down to a specific problem, you'd get better answers. I've used RESTful services with APEX 4.2, 5, 5.1 and they work just fine.
In the first, the external application passes a few fields and the method queries a record and sends the data back to the external application.
This is typical GET request. You pass the parameters (I usually pass them as part of the URL), use them in query, and return the values. You can even pass them to PL/SQL block, do whatever processing you need, then return the results.
In the second an external application builds a 30 field record that needs to be inserted by the method into the DB.
This is typcial POST request (although you still can use GET but not recommended). The format of how the data is being sent is important. I've done that using JSON format, and received as bind variable :body at APEX end. In APEX you can parse it and insert it into a table.
Few resources might help you to get going:
http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/apex/r50/Restful%20Services/restful_services.html#section1
This is especially helpful for POST:
https://ruepprich.wordpress.com/2016/03/22/apex-rest-post/
Currently I set up a RESTful API backend using Django and I can list a set of articles by the following GET:
api/articles/
Also, I can get a single article by:
api/article/1/
Each article is owned by a certain user, and one user could have multiple articles of course.
On the frond end side, I present all the articles at loading of the page, and I hope the user who is logged in currently could see the articles that they own in a different style, e.g, outlined by a box, and has a associated "delete" or "edit" button.
This requires me to tell, after the retrieval of the articles, which ones are owned by the current user programmatically. One way of doing this is to check the current user id with the owner id. However I feel this is not a good choice as the user id is the check is done fully on the client side and may be not consistent with the actual server judgement.
Therefore, is there a way, to tell by looking at the response of the GET, (say, let the server return a property "editable=true/false") to get whether the current user could edit(PUT) the resource?
I understand that this could be done at the server side, by attaching such a property manually. However, I am just asking whether there is better/common practice.
I just started learning web development and I am sorry if the question sounds trivial. Thank you!
You can attach propriety manually as you suggested. The advance of this approach is that you dont need any other http request.
Second possibility might be, that your client intentionally request information about endpoint permissions. In this case I would suggest to use OPTIONS HTTP method. You send OPTIONS HTTP request to api/articles/1 and backend returns wanted info. This might be exactly what OPTIONS method and DRF metadata were made for.
http://www.django-rest-framework.org/api-guide/metadata/
I think that this is a very interesting question.
Several options that come to me:
You can add to the GET api/article/1 response a HTTP header with this information i.e. HTTP_METHODS_ALLOWED=PUT,PATH,DELETE. Doing this way helps the API client because it does not need to know anything else. I think that this is not a good approach when more than one entity is returned.
call to OPTIONS api/article/1. Allowed methods for that user on that resource can be returned but notice that, in my opinion, this approach is not very good in terms of performance, because it duplicates the number of requests to the server.
But what if the entity returned also contains information on the owner or it? can, in this case the client know which policy apply and try to figure out it by itself? notice that the policy can be obtained from another endpoint (just one call would be needed) or even with the login response. If your entities do not contain that kind of information, it could be also returned as a HTTP header (like first option above)
BUMP: This is not a dead request. I'm still hoping to get a solid answer from someone at Facebook or anyone else. Thanks.
Revised Inquiry: I don't know if I'm not asking the right question, or if I'm asking a valid question that no one can answer.
New Questions:
Can we use FQL or another means to get all of the requests seen at reqs.php? I'm essentially looking for something like this:
SELECT request_id, app_id FROM apprequest WHERE recipient_uid = me()
Notifications return that data but app requests are often batched into a single record with a link identifying some but not all requests. I want individual records for all app requests currently open. The data to do this must be available, as this is the data used to build notifications! It just seems that this is not being made available to us. :(
Thanks!
Original Inquiry Follows:
I have an app that aggregates various sources of Facebook information for a user. One of the sets of data I'm working on is the collection of apprequests which have been sent to this user by friends. For example, I open GreatApp and click to send a request to you. You may or may not use GreatApp but let's assume you haven't blocked requests from it. You now open my AggregatorApp that shows my request to you, and the included link back to GreatApp. The data you see is the same as at reqs.php but formatted differently, with much more data, and of course simply much better. ;)
I thought that is what we got in apprequests. From this question I'm understanding that apprequests is a collection of requests sent out by the current application.
When using path/me/apprequests, we don't need to specify an app ID. But I believe here we do need to provide an app token rather than a user token. Is that correct? If that's correct then this confirms that the requests are those that this app sent out, not requests generated by other apps.
When using FQL, we need to identify the uid of the app as well as the id of the request in order to query the apprequests table. I get that, but even with a valid request id and app id (and valid permissions) FQL doesn't return request data. (I haven't checked with an app id, maybe that's the key.)
I am hoping people will provide some concrete examples for any of the above, specifically getting inbound requests from other apps, and confirmation about what token or other detail is expected for /apprequests and the apprequests table to return data.
Thanks!
Other threads asking the same question without a good (or any) response:
thread1 thread2
You need to make a graph api request to get the apprequests connection for a user. See the current documentation here: http://developers.facebook.com/docs/reference/api/user/.
In the Connections table, the documentation correctly notes that you need an application access token to retrive the requests to that user. There's a bug in the documentation under (http://developers.facebook.com/docs/reference/api/user/#apprequests) that claims you need a user access token. This is incorrect, and (as you've seen) will return an empty list of requests.
Requests sent by an application are only visible to the application. The user can't see or delete these requests (though they are able to hide the request). The reason for this is that the applications can put data into the requests (255 characters) that's never exposed to the user or other applications.
I don't think there's a way you'll be able to aggregate a user's requests from apps that you don't have an access token for.
What I have found out (before my question was deleted) was that you can't access requests with a user token, and app tokens can only access requests that app has sent (and I found that out myself in the documentation and playing with the graph explorer). Since I know there are iPhone apps and browser plugins for processing requests, I assume they are accessing the page itself and parsing the data (like scraping a site). The downfall to that approach is that on the request page only around 100 requests from each app are shown at one time.
(Unless some people have found a way that they aren't sharing...)
You are right, you need the app_access_token and not the user_access_token.
I think the FB documentation has an error.
The definitive answer was provided by a Facebook developer here in response to my bug report. The resolution is that this is By Design. This relates to the note by #noah-callaway that there's probably some app-specific data in requests that should not be available to other apps.
This is a shame, in my opinion, because as Facebook is all about sharing data among friends, I think it adds a dimension to the ecosystem when apps can share (limited and reasonable) information among one another.
Thanks for the responses!