I'm trying to add a card as a destination to a managed account as per https://stripe.com/docs/api#account_create_card. Request goes like this:
HTTP Method POST
HTTP URI https://api.stripe.com/v1/accounts/<acct_id>/external_accounts
HTTP Protocol HTTP/1.1
HTTP Header Accept : application/json
HTTP Header Authorization : Basic <auth_value>
HTTP Header Stripe-Version : 2016-07-06
HTTP Content application/x-www-form-urlencoded
HTTP Body external_account[object]=card
HTTP Body external_account[cvc]=121
HTTP Body external_account[exp_month]=11
HTTP Body external_account[exp_year]=2018
HTTP Body external_account[number]=4000056655665556
HTTP Body external_account[currency]=usd`
Server replies with such json:
{
"error" : {
"type" : "invalid_request_error",
"message" : "Requests made on behalf of a connected account must use card tokens from Stripe.js, but card details were directly provided.",
"param" : "external_account"
}
}
what am I missing? We don't use stripe.js, all interaction with Stripe happens on the backend.
you are using card details and passing it to external_account parameter which only takes the token of the card. To use card details just pass the object, cvc etc parameters directly. don't send these details to external_account paramter
Related
I'm in "Integration Request". I've set HTTP integration type and the Endpoint URL.
Below, I see "HTTP Headers, but if I try to add an header, there is a strange "mapped from" value I don't understand.
Setting an HTTP Proxy integration add a Mapping template I also don't understand.
I just need to pass the Authorization:xxxx and X-Auth-Username:xxxxx from the original request to the endpoint
Can't find an easy way...
I set HTTP proxy integration and added in the HTTP Headers (and deployed):
method.request.header.Authorization
method.request.header.X-Auth-Username
I also added as required Authoriaxtion and X-Auth-Username in Method request header as required.
But I get an error upon calling the api:
Authorization header requires 'Credential' parameter.
Authorization header requires 'Signature' parameter.
Authorization header requires 'SignedHeaders' parameter.
Authorization header requires existence of either a 'X-Amz-Date' or a 'Date' header
Hmmm maybe it's a "naming" problem?
So I changed "authorization" with MyAuthentication in the method request, and after in the integration Header, I mapped Authorization to
method.request.header.MyAuthentication
Now if I call my api with MyAuthorization in the header, I get "Missing Authentication Token", without hitting the api server
Click on 'Method Request' , expand 'HTTP Request Headers' and add a header Authorization . Now go back and click on 'Integration Request' , expand 'HTTP Headers' and add Header Name Authorization and 'Mapped from' method.request.header.Authorization . Basically for any header XYZ on 'Method Request' tab should have corresponding mapping on 'Integration Request' method.request.header.XYZ .
To Correctly use aws API Gateway as a pure http proxy and make it pass the Authorization header as-is to your backend API, you need to do two things:
In the Method Request: Make sure to add the Authorization header to the Http Request Headers section.
With this, AWS does not assume that the Authorization header is of your own implementation and the gateway does not expect it to contain AWS own format of multiple parameters such as SignedHeaders, Signature, X-Amz-Date , etc..
2. In the Integration Request: Make sure to select the Use HTTP Proxy Integration.
This makes sure that the request is being sent to the target as-is and thus the Authorization header not to be consumed and discarded as part of AWS own SigV4 authorization.
The following was correct...I was calling the original api path instead of te api gateway path....
I set HTTP proxy integration and added in the HTTP Headers (and deployed):
method.request.header.Authorization
method.request.header.X-Auth-Username
URL :
https://circuitsandbox.net/rest/v2/webhooks
My Headers :
Content-Type : application/x-www-form-urlencoded
Authorization : Bearer ot-xxxxxxxxxxxx
Body :
url - Some URl
filter - CONVERSATION.CREATE
Error I am getting :
"The permission to access this resource is not granted. Scopes ::= [ALL, READ_CONVERSATIONS, READ_USER]"
Plus If i want to send extra filters thn will it be comma separated values?
If you are getting a 403, I would suspect a scope error (as mentioned by Roger) or an authentication problem.
For the first, please show us which scopes are currently selected for the application ; for authentication, can you check if you can make other API calls successfully ?
Here is what it looks like in Postman
Make sure your app registration contains the scopes that your app is asking for. For a simple outgoing webhook registration you would only need the scope READ_CONVERSATIONS.
See https://github.com/circuit/circuit-REST-bot/blob/master/app.js for an example on how to register for a webhook. This example registers for CONVERSATION.ADD, but CONVERSATION.CREATE is very similar.
If you still have problems please post a code example, or even a link to an app on repl.it.
Here is an example HTTP request to register the webhook. Note that the body is sent as text/plain (which is the default and its header can be omitted). Also note that the callback url is http. https is not yet supported.
POST https://circuitsandbox.net/rest/v2/webhooks HTTP/1.1
Host: circuitsandbox.net
Content-Type: text/plain
Authorization: Bearer <token>
url=http://90587c6d.ngrok.io/webhook&filter=CONVERSATION.CREATE
and here is a curl command
curl -X POST https://circuitsandbox.net/rest/v2/webhooks -H "Authorization: Bearer <token>" -d "url=http://90587c6d.ngrok.io/webhook&filter=CONVERSATION.CREATE"
I was trying to setup Jmeter for Salesforce API testing. However getting the below error during Salesforce authorization:
"error":"unsupported_grant_type","error_description":"grant type not
supported"
I am passing the parameters as in the screenshots attached. The same parameters when passed in Postman works fine, however I am getting this error in Jmeter. Please let me know if I am making some error in passing the parameters in Jmeter.
Jmeter_HTTP Header Manager
Jmeter_HTTP Request
Jmeter_Sampler Result
According to HTTP Status Code 400 documentation
The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
Looking into your request, you're sending Content-Type header as application/json therefore your server expects JSON and you're providing something different.
My expectation is that you should switch to Body Data tab of the HTTP Request sampler and set the request body to look like:
Check out REST API Testing - How to Do it Right article for more information on REST APIs testing using JMeter.
I struggle with the same issue but it finally worked for me by doing the following:
Use Content-Type application/x-www-form-urlencoded in an HTTP Header Manager
Make sure is a POST Method and that you're using https
Not sure if it is necessary but in the Parameters tab make sure all (grant_type, password, client_secret_ client_id and username) are Content-Type application/x-www-form-urlencoded and check the URL Encode option for all
Only check "Follow Redirects" and "Use KeepAlive" options in the HTTP Request
hope it works for you too
I am creating Rest API but I am confused in URL structure. I have to send just one parameter to server in my Post request. should I send it through path variable or in request body? what are the best practices?
Example Current URL:
api/v1/users/{id}/name/{name}
name is the variable I want to send to server for to change state
Thanks
URL usually identifies resource you want to update.
So the data should go inside in request body
To update user name you may send this to server:
POST api/v1/users/{id} HTTP/1.1
Content-Type: application/x-www-form-urlencoded
name=string
I have an old web application I have to support (which I did not write).
When I fill out a form and submit then check the "Network" tab in Chrome I see "Request Payload" where I would normally see "Form Data". What is the difference between the two and when would one be sent instead of the other?
Googled this, but didn't really find any info explaining this (just people trying to get javascript apps to send "Form Data" instead of "Request Payload".
The Request Payload - or to be more precise: payload body of a HTTP Request
is the data normally send by a POST or PUT Request.
It's the part after the headers and the CRLF of a HTTP Request.
A request with Content-Type: application/json may look like this:
POST /some-path HTTP/1.1
Content-Type: application/json
{ "foo" : "bar", "name" : "John" }
If you submit this per AJAX the browser simply shows you what it is submitting as payload body. That’s all it can do because it has no idea where the data is coming from.
If you submit a HTML-Form with method="POST" and Content-Type: application/x-www-form-urlencoded or Content-Type: multipart/form-data your request may look like this:
POST /some-path HTTP/1.1
Content-Type: application/x-www-form-urlencoded
foo=bar&name=John
In this case the form-data is the request payload. Here the Browser knows more: it knows that bar is the value of the input-field foo of the submitted form. And that’s what it is showing to you.
So, they differ in the Content-Type but not in the way data is submitted. In both cases the data is in the message-body. And Chrome distinguishes how the data is presented to you in the Developer Tools.
In Chrome, request with 'Content-Type:application/json' shows as Request PayedLoad and sends data as json object.
But request with 'Content-Type:application/x-www-form-urlencoded' shows Form Data and sends data as Key:Value Pair, so if you have array of object in one key it flats that key's value:
{ Id: 1,
name:'john',
phones:[{title:'home',number:111111,...},
{title:'office',number:22222,...}]
}
sends
{ Id: 1,
name:'john',
phones:[object object]
phones:[object object]
}
tl;dr of lefloh's (excellent) answer:
If an HTTP request has a message body, it is a "Request Payload"
"Form Data" is a subset of Request Payload in which the body is encoded as key1=value1&key2=value2
Whenever Google Chrome can distinguish Form Data from a generic Request Payload, it customizes the formatting