QBO raises the error code 2250 "You must fill out at least one split line". Why does it need to pass a line for deleting an invoice? Should it just require invoice.id?
For whatever bizarre reason, the Intuit v3 "delete" call requires that you pass the entire invoice object to the delete call in order to delete an invoice.
It's weird, yes. Unfortunately, it's also the way the API works and is required.
You can see this documented here:
https://developer.intuit.com/docs/0025_quickbooksapi/0050_data_services/010_calling_data_services/060_delete
Quoting:
The request body includes the full payload of the object as returned in a read response.
I figured a hack way without submitting the entire object. It accepts an empty line and sync token along with the invoice id.
Related
I Am using react. I have a fetch setup in an useEffect to grab the data from a database from the backend. It pulls the account and sends it back to the front where i can access it from there.
From the File I want to access the user information i have a console log
I want to be able to grab like the firstname, lastname individually and use them in the script. how do i go about that. I did try to console log UserData.user and it gave me this result
However when i went to try to get firstname like userData.user.firstname i was met with an error. Im pretty new to react and pushing myself with things ive never done before to learn and any help would be great
Thank you everyone who does help it means alot
Please note all information in screenshots are fictitious and are just prop data.
EDIT:
This may be because you are trying to read the user information before the api returns the data. so check if the array has data before trying to access it . You can use save navigation to check for undefined or null
UserData.user[0]?.firstname
Based on your screenshot the data you are getting back is an array of user objects. To access it you will need to use:
userData.user[0].firstname
Note that this will access the first user object in the array - you will likely need checks to ensure the data data exists before accessing it, e.g.:
if (userData.user.length > 0) {
// Access data as needed
}
user is an array so you can acces like this
userData.user[0].firstname;
it will be better if you update your endPoint to get an object instead, so you can have access and check easier
The log entries of my app result in jsonPayload while the gae request log entries use protoPayload. Just like in protoPayload, I added a requestId in my logging that shows up in jsonPayload. However, when using the log viewer where "Show entries from same request" action, I don't see my log entries since the filter uses protoPayload.requestId="xyz". I tried to use an or condition with jsonPayload.requestId="xyz" but that didn't help. Ideally I wouldn't even want to manually edit the clause as it will be painful to do everytime. Seems like per the following documentation, the requestId in each of these types of payloads don't map to the same underlying bigquery field.
https://cloud.google.com/logging/docs/export/bigquery
There is also a "trace" field directly on the log entry and that is same for all the related logs. However, there is no field called trace to search. Doing a text search does return all the entries. While this works, again the UX is bad as it requires first drilling down to the request log entry, copying the trace value and then doing a query.
So, are there any other options to tie the request log entry with the rest of the app log entries for that request easily?
There is a field called "trace" that is on the log entry which works. I think I was confused with the "traceId" within the protoPayload. Note that to get the "trace" field to show up with json payload, the field name should be "logging.googleapis.com/trace"
When using gmail API, history.list method we get "bare" message ids with no additional field from the fields in 'labelAdded', 'labelRemoved', 'messageAdded', 'messageRemoved'. Why is that? And is it possible that a new message has been added but when we use this method, the field messageAdded hasn't been used, so we receive it "bare" ?
According to the GMail history API, the list only contains the id and threadId fields.
It works this way because the objective of the history API is to provide you with the changes that happened in the mailbox, not its contents.
After you obtain the list from Users.history: list you need to call Users.messages: get or Users.messages: list to get the full messages.
If the messageAdded field is empty, it means that no new messages were added after the last historyId you examined. You might have skipped some. Make sure that every time you query the API you internally store the last historyId you processed so you can resume from that point in the future and not lose any changes.
I am doing full sync this way: list of /threads and then a request to get each of the thread like /threads/{id}. However this returns me every message together with it's body data -> and I just want to fetch the metadata of the messages. I can see that in get 'messages/{id}' you can specify format but not in get threads/{id}
Threads.get() now supports format=METADATA and with that you can use the new "metadataIncludeHeaders" to further limit the headers list to a select few. This is much more efficient than using "fields" as it only fetches what is necessary from the backend rather than filtering it later on:
https://developers.google.com/gmail/api/v1/reference/users/threads/get
I assume that by metadata you mean the headers (no body). You can use the fields parameter to get just that (messages/payload/headers):
https://www.googleapis.com/gmail/v1/users/me/threads/{thread-id}?fields=messages%2Fpayload%2Fheaders&key={YOUR_API_KEY}
So here is what the method looks like now:
POST person/personId/edit
https://api.example.com/*key*/person/*personId*/edit?FName=Blah
I want this to change the first name of person at personId to Blah.
And if I need to add a person I say:
PUT person/create
https://api.example.com/*key*/person/create
and it will add a person with a new personId.
The general convention is usually:
GET => READ
POST => CREATE
DELETE => DELETE
PUT => UPDATE
A difference I can see is that you are also using different URIs, what is most commonly use is a single resource URI. But, anyways that's debatable so it is a matter of how you like it.
My interpretation of POST and PUT has always been:
POST - The server will receive an entity which it can use to perform an operation or create a resource. If the endpoint's intent is to create a resource, then POST will always create a NEW resource. In any case, each POST will be treated without regards to the state of a resource. You are simply posting information to the server for it to operate on.
Example:
Imagine a web service that will send a message to a user's cellphone. A POST could be used to provide the necessary information to the server which may not be appropriate for a GET. The request payload will include this information. No resources are being created on the server, so the operation returns 200 OK, indicating that the operation was completed successfully. The response may also include a body containing information from the server operation.
Imagine a web service that creates a ticket that is posted on a bulletin board. A POST could contain the information needed to make that post. The information is persisted on the server and returns a 201 Created (and maybe a response body which contains a user id, or a more completed object resulting from the creation). In all cases, when something is POSTed to this endpoint, a NEW ticket is created.
PUT - The server will receive an entity (with an ID, for example) with the intent of creating or replacing a resource. If the resource already exists, it will be replaced with the one within the request, otherwise a new resource will be created. In all cases, something is persisted on the server. Some way to uniquely identify the entity must be provided. In other words, the client is the one that creates the ID because it will be used if entity needs to be created. Most people I know struggle with this reality.
Example:
A web service receives a payload form the client containing user
information. The expectation is that the user will be saved. The
server will check to see if that user exists. If it does, it will
update that user by replacing it (in its entirety) with the new resource provided with
the request and return 200 OK or 204 No Content. If it does not
exist, it will create it and return 201 Created.