I am trying to achieve send of mail via SendGrid API.
Following is the JSON I am sending as a body of the POST Method
{
"content" : [
{
"type" : "text\/plain",
"value" : "Hello, World!"
}
],
"personalizations" : [
{
"to" : [
{
"email" : "sahpranav1712#gmail.com"
}
],
"subject" : "Hello, World!"
}
],
"from" : {
"email" : "iospranav1712#gmail.com"
}
}
and following is the return that I am getting
{"message":"Bad Request","field":null,"help":null}
This piece of info doesn't help much.
The authorization is in place, and I believe correctly.
Perhaps, I might have missed some sort of settings in the SendGrid App
If it helps im using Objective-C.
Please help!!
I experienced the same issue and the problem was actually that all substitutions in the personalizations field need to be string values (see https://github.com/sendgrid/sendgrid-php/issues/264)
"personalizations": [{
"to": [{
"email": "mail#gmail.com"
}],
"substitutions": {
"{myFloatVal}": 16.5,
"{firstname}": "Thomas"
}
}]
What exactly is a 400 BAD REQUEST?
Why you are getting 400 BAD REQUEST from SendGrid one can only guess. 400 BAD REQUEST means oh we probably know what happened we are just not telling you.
This is a common 'error handling technique' where the developer catches the error and simply returns false, hiding any of the details or reasons for the failure.
Check for duplicate addresses.
One possible reason, as was in my case, one of the CC addresses was also the TO address. You see among many other things, SendGrid does not allow an email address to occur more than once in a send request, and if you happen to list an email recipient more than once in any of the TO,CC, or BCC lists SendGrid just sends back 400 BAD REQUEST.
Other Reasons
There are dozens of other poorly documented reason for 400 BAD REQUEST and I sincerely wish you luck in finding out why SendGrid rejected yours. One of the other answers here may help you.
Not setting [manager setRequestSerializer:[AFJSONRequestSerializer serializer]];
was the issue!!!
My experience usually is that the body has to be without any new lines (\n or \r for example), otherwise it will return a 400 error. When I clear up any new lines, it works, I usually use something like:
reg_replace('/\s\s+/', ' ', $message)
While this is an old issue, the following might be helpful for others.
If you are using dynamic templates, make sure that the Id is correct. The dashboard does not lend itself to easy copying of the template id, which means that one can easily include an extra space in front of the id.
By adding a space (or any other character for that matter) to the id of the template, SendGrid will simply reply with a Bad Request, without letting you know why.
Check email list too. If there is null or empty string in your BCC or to list Sendgrid will throw BAD Request.
Related
I am very stuck. Tried everything I could think of to solve this issue, but I feel as though it is just something wrong with my JSON. When I build a dynamic template, I'd like to insert some variables for the send. As you can see in the example, simply just adding the first name in the handlebars. However, when I send tests using postman, I can not for the life of me get the first_name to display. I've tried so many different options in the JSON and nothing seems to work. Here is where I am currently at, omitting the first_name obviously. Any help on how to format this I would very much appreciate it.
{
"from": {"email":"example#example.com"},
"template_id":"ID HERE"
"personalizations": [
{
"to": [
{
"email":"recipient#gmail.com"
}
]
}
]
}
I tried 100 different variations of the request.
Twilio developer evangelist here.
I think that using that JSON is mainly for when you're using the API to send an email with a template. You then provide the JSON data as dynamic_template_data and it is populated in the email template.
first_name is a reserved field and substitution tag which lets you use any reserved or custom field data you've added to Marketing Campaigns to dynamically generate unique content for each recipient of your email. One common example is adding a recipient's first name to the body (or even the subject line) of your email.
The data that populates your Substitution Tags will come from the information you have stored about each contact.
You can work with substitution tags with the code editor or design editor.
Let me know if this helps at all!
I am trying to get a way to see if a message that i get using the Outlook Rest API using this url https://graph.microsoft.com/beta/me/messages('{messageid}') and seing if it is a reply. Normaly it would be from the Thread Id but the API doesn´t send one.
Is there anyway to see if the message is a reply?
API has one 'ConversationId' field. You can use that to group the messages.
{
...
"ConversationId": "AQQkADAwAT..."
...
}
This question has been answered here:
https://stackoverflow.com/a/60048538/3892957
Use GET https://graph.microsoft.com/v1.0/me/messages?$expand=SingleValueExtendedProperties($filter=(Id%20eq%20'Integer%200x1081'))
If a Message had been replied to you would see a result like
"singleValueExtendedProperties": [
{
"id": "Integer 0x1081",
"value": "102"
}
]
We have stock website and we help buyers connect with the sellers. We are creating API to let buyers push their contact details and get back the seller details. This is transaction and get logged in our database. We have created following API:
The request is POST, the URL looks like:
/api/leads
The request body looks like:
{
"buyermobile": "9999999999",
"stockid": "123"
}
The response looks like:
{
"sellermobile" : "8888888888",
"selleraddress": "123 avenue park"
}
We have a new requirement, i.e. we need to send back PDF URL (instead of "sellermobile" & "selleraddress"). This PDF URL would contain the seller details in case it comes from one of our client.
We have modified the same API, now the request body looks like:
{
"buyermobile": "9999999999",
"stockid": "123",
"ispdf": true
}
The response looks like:
{
"sellerdetailspdf" : "https://example.com/sellerdetails-1.pdf",
}
Is it RESTFUL to do this? OR we should create separate API for getting response as PDF?
I wouldn't approach it this way. What happens when you need to add XLS? Do you add "isxls" to the request too?
Things I'd consider:
Use a mime type for content negotiation. Post the same request, and specify in the Accept header what you expect back - JSON, PDF, etc. You're then actually getting the report instead of a link to the report, which may or may not be better.
- or -
Include a link in the typical lead response.
{
"sellermobile" : "8888888888",
"selleraddress": "123 avenue park",
"_links": {
"seller-details-pdf": "https://example.com/sellerdetails-1.pdf"
}
}
- or -
Support a query parameter that specifies the type in the response.
- or -
Have a single property that specifies the type in the response, rather than a boolean. Much cleaner to extend when you add new response types.
The first two options have the bonus that you don't require clients to handle multiple response types to a single request. That's not forbidden by any spec, but it's annoying for clients. Try not to annoy the people who you want to pay you. :)
Again the implementation looks good to me, however you could potentially look at breaking the return of the PDF URL to another endpoint maybe something like api/lead/pdf that way your request body is the same for api/lead and all subsequent endpoints under /lead. Allowing your routes and other code to handle small portioned tasks instead of having a route that handles multiple flags and multiple code routes.
That looks good to me - the same type of input should give the same type of response but in your case you have two different types of input - one with the "ispdf" flag and one without. So it's consistent to responds with two different types of response, one with the PDF link and one without.
That's still something you'll want to document but basically it's a correct implementation.
I've tried to change MUC subject using ejabberd API but didn't work. I use Postman to work with the API
api : /api/change_room_option
request body :
{
"name": "testgroup",
"service": "conference.localhost",
"option": "subject",
"value": "BookNerds"
}
error : "400 Bad Request"
I've enabled change_room_option in my ejabberd.yaml and set allow_change_subj to true. Using this configuration and same request body format, I successfully change 'title' and 'description'.
Note : I ran another test using Adium and successfully change the subject. When I check in database, subject and subject_author have been updated. Do I need to set subject_author too in the request body? If yes - I don't think it's possible since change_room_option will only accept four parameters as stated here
For a error case when calling some HTTP Rest service API, the response is as follows:
{
"statusCode": "400",
"error": "Bad Request",
"message": "Can not construct instance of java.math.BigDecimal from String value 'a': not a valid representation\n at [Source: org.apache.cxf.transport.http.AbstractHTTPDestination$1#2f650e17; line: 1, column: 2] (through reference chain: com.foo.services.dto.request.ItemToUpdate[\"quantity\"])",
"validation": {
"source": "PAYLOAD",
"keys": ["key"]
},
"errorIdentifiers": [],
}
I am wondering if the message field in the response is appropriate. It does reveal certain level of implementation to the end user. Is this considered as
no particular problem at all
just a bad cosmetic issue that won't cause serious problem, just not readable to end user
potential security risk that definitely needs to be fixed
I think that you should only log the stacktrace on the server side. IMO it's technical hints (in addition, perhaps the end user even doesn't use Java to interact with your API) and the only thing that interests the end user of your API is that there is here a validation error within the provided data.
Another remark is that you use the status code and statusmessage within your response payload. I think that you don't need to duplicate this since it's already present in the response.
I would suggest an error message like that:
{
"messages": {
"quantity": "this must be a valid number"
}
}
I use a JSON structure for the field messages since there could be several validation errors within the provided data. Note that it's only a suggestion and you could extend this to your exact needs.
Hope it helps.
Thierry