curl -v --insecure -H "Authorization: Bearer A0154m48uAapcL0HYC1n.8kWdiQzwHIeh0qC3h66P2QGK0s" -H "Content-Type: application/json" https://api.paypal.com/v1/payments/payment
< HTTP/1.1 401 Unauthorized
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< PROXY_SERVER_INFO: host=slcjavapapi3029b.slc.paypal.com;threadId=39967
< Paypal-Debug-Id: b182cbfc9dd59
< CORRELATION-ID: b182cbfc9dd59
< Content-Language: *
< Date: Wed, 15 Jul 2015 22:16:05 GMT
< Content-Type: text/xml
< Content-Length: 0
Even though other endpoints work just fine, such as
curl -v --insecure -H "Authorization: Bearer A0154m48uAapcL0HYC1n.8kWdiQzwHIeh0qC3h66P2QGK0s" -H "Content-Type: application/json" https://api.paypal.com/v1/identity/openidconnect/userinfo/?schema=openid
< HTTP/1.1 200 OK
< Date: Wed, 15 Jul 2015 22:19:59 GMT
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< Paypal-Debug-Id: b93fbda0effed
< Content-Type: application/json;charset=UTF-8
< Content-Length: 107
< Set-Cookie: Apache=10.73.8.97.1436998799550367; path=/; expires=Fri, 07-Jul-45 22:19:59 GMT
< Vary: Accept-Encoding
Other endpoints work fine as well. It seems the payments listing always returns 401.
When you go live with your application to process direct credit card payments, you will need to make sure you are approved for live direct credit card payments.
A quick way to check is to log in at the Developer Site > go to My Account > under Live, click Enable next to Direct Credit Card.
Make sure you are using your Live Client ID and Secret.
Go Live With PayPal Payments
Related
I'm trying to set the content-type header of my cURL request to application/json.
This is the request I'm using in cmd (I left out the Json-Body):
curl -v -X POST http://localhost:40071/api/Sale --header 'Content-Type: application/json' -d '{[Json Body]}'
When running this command, cURL is logging the following:
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 127.0.0.1:40071...
* Connected to localhost (127.0.0.1) port 40071 (#0)
> POST /api/Sale HTTP/1.1
> Host: localhost:40071
> User-Agent: curl/7.79.1
> Accept: */*
> Content-Length: 332
> Content-Type: application/x-www-form-urlencoded
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 500 Internal Server Error
< Date: Tue, 09 Nov 2021 11:18:33 GMT
< Content-length: 0
<
My REST server is running into an exception because of HTTP 415 Unsupported Media Type.
It seems as if cURL did not make use of my "--header" parameter?
Because the log is showing that Content-Type: application/x-www-form-urlencoded was chosen.
I also tried it with the abbreviated parameter "-h".
Seems duplicate question, for more examples, refer here.
How to send a header using a HTTP request through a cURL call?
curl -X POST mockbin.org/request -H "Accept: application/json"
I would like to use the REST API of Github to manage the milestones and labels of some of my repositories, but I constantly fail to create new milestones or labels via REST. What do I miss?
I enable 2FA for my account and also create a personal access token, as it is described in Other Authentication Methods
For example I try to create a new milestone with this cURL command:
curl -X POST -v \
-H "Authorization: token MyPersonalAccessToken" \
-H "Content-Type: application/json" \
-H "Accept: application/vnd.github.v3+json" \
-d '{"title": "1", "state": "open", "description": "Milestone", "due_on": "2025-10-09T23:39:01Z"}' \
https://api.github.com/repos/obfischer/boxsack/milestones
I tried various other variants but all seems to be wrong. At least I always get only a 404 Not Found. According to the Github documentation this could also mean that my authentication failed, as Github returns a 404 Not Found response code to protect user data instead of returning a 401 Unauthorized.
But I am pretty sure that the authentication via the Person Access Token is working as I can see a user specific rate-limit headers in the response:
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 4999
Does someone have a clue why I can't create a milestone via REST?
Maybe your personal access token doesn't have the repo scope. I've just tested to send the request with a token without that scope & it also returns 404 :
< HTTP/1.1 404 Not Found
< Date: Sat, 26 Oct 2019 11:07:31 GMT
< Content-Type: application/json; charset=utf-8
< Content-Length: 125
< Server: GitHub.com
< Status: 404 Not Found
< X-RateLimit-Limit: 5000
< X-RateLimit-Remaining: 4989
< X-RateLimit-Reset: 1572091544
< X-OAuth-Scopes: [Here there should be repo] <================
< X-Accepted-OAuth-Scopes:
< X-GitHub-Media-Type: github.v3; format=json
< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type
< Access-Control-Allow-Origin: *
< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
< X-Frame-Options: deny
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
< Content-Security-Policy: default-src 'none'
< X-GitHub-Request-Id: 87B2:23EED:36F2B7F:42647AE:5DB428F3
<
{
"message": "Not Found",
"documentation_url": "https://developer.github.com/v3/issues/milestones/#create-a-milestone"
}
Can't understand how should look the following request
POST api/v1/authenticate
from here: Lingvo API
It's said: "Responds to POST request containing "Authorization: Basic
{ApiKey}" header."
I've tryend
POST https://developers.lingvolive.com/api/v1/authenticate with header ["Authorization":"BasicZjkzN2E4YTctZmUxMS00YTkxLThjMjEtYzBiOGU3NTY1Y2ZmOjk2NTUxYmI2YjRhNjRkOWRhNmQ5NTJkMzVlOWM2YjBk"]
also tried POST https://developers.lingvolive.com/api/v1/authenticate
with body
{"Authorization": "BasicZjkzN2E4YTctZmUxMS00YTkxLThjMjEtYzBiOGU3NTY1Y2ZmOjk2NTUxYmI2YjRhNjRkOWRhNmQ5NTJkMzVlOWM2YjBk"}
And every time getting 401 ;(
It would seem to me that you're just missing a space. The docs read that you should supply a header with the value:
"Authorization: Basic ZjkzN2E4YTctZmUxMS00YTkxLThjMjEtYzBiOGU3NTY1Y2ZmOjk2NTUxYmI2YjRhNjRkOWRhNmQ5NTJkMzVlOWM2YjBk"`
Rather than Authorization: BasicZjkzN2[...] as you have in your question.
I'll post my cURL output here that I used to validate my hypothesis. You're likely using a test account if you're sharing the API key on stackoverflow, but it's worth saying anyway: do not use the credentials you've shared here in production!
$ curl -X POST 'https://developers.lingvolive.com/api/v1/authenticate' -H 'Authorization: Basic ZjkzN2E4YTctZmUxMS00YTkxLThjMjEtYzBiOGU3NTY1Y2ZmOjk2NTUxYmI2YjRhNjRkOWRhNmQ5NTJkMzVlOWM2YjBk' -H 'Content-length: 0' -vvv
* Trying 40.74.55.233...
* Connected to developers.lingvolive.com (40.74.55.233) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
* Server certificate: *.lingvolive.com
* Server certificate: Go Daddy Secure Certificate Authority - G2
* Server certificate: Go Daddy Root Certificate Authority - G2
> POST /api/v1/authenticate HTTP/1.1
> Host: developers.lingvolive.com
> User-Agent: curl/7.49.1
> Accept: */*
> Authorization: Basic ZjkzN2E4YTctZmUxMS00YTkxLThjMjEtYzBiOGU3NTY1Y2ZmOjk2NTUxYmI2YjRhNjRkOWRhNmQ5NTJkMzVlOWM2YjBk
> Content-length: 0
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: application/json; charset=utf-8
< Expires: -1
< Server: Microsoft-IIS/8.5
< X-AspNet-Version: 4.0.30319
< X-Powered-By: ASP.NET
< Date: Mon, 14 Nov 2016 14:06:46 GMT
< Content-Length: 318
<
* Connection #0 to host developers.lingvolive.com left intact
"ZXlKaGJHY2lPaUpJVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5LmV5SmxlSEFpT2pFME56a3lNVGc0TURZc0lrMXZaR1ZzSWpwN0lrTm9ZWEpoWTNSbGNuTlFaWEpFWVhraU9qVXdNREF3TENKVmMyVnlTV1FpT2pRMkxDSlZibWx4ZFdWSlpDSTZJbVk1TXpkaE9HRTNMV1psTVRFdE5HRTVNUzA0WXpJeExXTXdZamhsTnpVMk5XTm1aaUo5ZlEuaWRQOHRGZXpCYVlHSm45MHJlU3VPRmtWSE43cnROdXVram1BdzkzN3FQQQ=="%
By the way, it looks like explicitly defining an accurate Content-length: n header is required. In this case, there is no body, so a value of 0 does the trick.
I'm creating a REST interface (aren't we all), and I want to UPDATE a resource.
So, I think to use a PUT.
So, i read this.
My take away is that i PUT to a URL like this
/hc/api/v1/organizer/event/762d36c2-afc5-4c51-84eb-9b5b0ef2990c
with a payload, then a permanent redirect to the URL that it can GET an updated version of the resource.
In this case it happens to be the same URL, different action.
So my questions are:
Is my understanding of updating a resource correct in using a PUT, and is my understanding of the use of the PUT correct.
When a client gets a redirect does it do the same action on the redirected URL as it did on the original URL? If its "depends" is there a standard most clients follow?
I ask the 2nd question, because POSTMAN and my JQuery AJAX calls are choking. JQuery because of net::ERR_TOO_MANY_REDIRECTS. So is it redirecting and trying the PUT again, which it will get another REDIRECT?
curl blows up too but even though it says if it gets a 301 it will switch to a GET, it doesn't really seem to do that when i look at the output (below).
When curl follows a redirect and the request is not a plain GET (for example POST or PUT), it will do the following request with a GET if the HTTP response was 301, 302, or 303. If the response code was any other 3xx code, curl will re-send the following request using the same unmodified method.
CURL OUTPUT (edited for brevity) (also note how it says its going to switch to a GET [incorrectly from a POST], but then it seems to do a PUT anyway):
curl -X PUT -H "Authorization: Basic AUTHZ==" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -H "Postman-Token: e80657f0-a8f5-af77-1d9d-d7bc22ed0b30" -d '{ JSONDATA"}' http://localhost:8080/hc/api/v1/organizer/event/762d36c2-afc5-4c51-84eb-9b5b0ef2990c -v -L
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> PUT /hc/api/v1/organizer/event/762d36c2-afc5-4c51-84eb-9b5b0ef2990c HTTP/1.1
> User-Agent: curl/7.37.1
> Host: localhost:8080
> Accept: */*
> Authorization: Basic AUTHZ==
> Content-Type: application/json
> Cache-Control: no-cache
> Postman-Token: e80657f0-a8f5-af77-1d9d-d7bc22ed0b30
> Content-Length: 203
>
* upload completely sent off: 203 out of 203 bytes
< HTTP/1.1 301 Moved Permanently
< Connection: keep-alive
< X-Powered-By: Undertow/1
< Set-Cookie: rememberMe=deleteMe; Path=/hc; Max-Age=0; Expires=Fri, 20-Feb-2015 03:53:28 GMT
< Set-Cookie: JSESSIONID=uwI3_41LAa7vlvapTsrZdw10.macbook-air; path=/hc
* Server WildFly/8 is not blacklisted
< Server: WildFly/8
< Location: /hc/api/v1/organizer/event/762d36c2-afc5-4c51-84eb-9b5b0ef2990c
< Content-Length: 0
< Date: Sat, 21 Feb 2015 03:53:28 GMT
<
* Connection #0 to host localhost left intact
* Issue another request to this URL: 'http://localhost:8080/hc/api/v1/organizer/event/762d36c2-afc5-4c51-84eb-9b5b0ef2990c'
* Switch from POST to GET
* Found bundle for host localhost: 0x7f9e4b415430
* Re-using existing connection! (#0) with host localhost
* Connected to localhost (127.0.0.1) port 8080 (#0)
> PUT /hc/api/v1/organizer/event/762d36c2-afc5-4c51-84eb-9b5b0ef2990c HTTP/1.1
> User-Agent: curl/7.37.1
> Host: localhost:8080
> Accept: */*
> Authorization: Basic dGVzdHVzZXIxOlBhc3N3b3JkMQ==
> Content-Type: application/json
> Cache-Control: no-cache
> Postman-Token: e80657f0-a8f5-af77-1d9d-d7bc22ed0b30
>
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Set-Cookie: JSESSIONID=fDXxlH2xI-0-DEaC6Dj5EhD9.macbook-air; path=/hc
< Content-Type: text/html; charset=UTF-8
< Content-Length: 8593
< Date: Sat, 21 Feb 2015 03:53:28 GMT
<
...failure ensues... It actually does a PUT
thanks in advance.
I think you're reading too much into the 301 redirect section.
If you want to update a resource using PUT, return:
201: if the resource was created
200: with the updated resource
The 301 in question only applies if there actually is a redirect in question - like, if something can be identified by name, and you need to redirect it to a url that has the id or something. (Maybe you refactor and people are still consuming the old endpoint).
So, do you really need to redirect your PUT requests? Because you should be sending back the updated resource within the same loop using 200, like stated above, instead of "redirecting to GET".
EDIT: Fix some spelling.
I am unable to upload any tracks larger than about 7MB (413 Request Entity Too Large is returned). This functionality was previously working and the soundcloud api states that tracks can be upto 500MB.
Here is an example using curl with a successful upload(4.9MB) and an unsuccessful one(7.4MB)
I have provided dropbox links to the tracks(my own production, so no copyright issues!!!) if anyone wants to try to replicate. You will need to add your oauth_token.
successful upload = 4900kb_307sec_128kbps_44100hz.mp3
curl -i -X POST "https://api.soundcloud.com/tracks.json" \
-F 'oauth_token=********' \
-F 'track[asset_data]=#4900kb_307sec_128kbps_44100hz.mp3' \
-F 'track[title]=A 4.9MB track' \
-F 'track[sharing]=public'
HTTP/1.1 100 Continue
HTTP/1.1 201 Created
Access-Control-Allow-Headers: Accept, Authorization, Content-Type, Origin
Access-Control-Allow-Methods: GET, PUT, POST, DELETE
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Date
Age: 0
Cache-Control: no-cache
Content-Type: application/json; charset=utf-8
Date: Wed, 06 Nov 2013 18:22:57 GMT
Location: https://api.soundcloud.com/tracks/118866401
Server: nginx
Via: 1.1 varnish
X-Cache: MISS
X-Cacheable: NO:Cache-Control=no-cache
X-Runtime: 436
X-Varnish: 3652774389
Content-Length: 1623
unsuccessful upload = 7400kb_307sec_192kbps_44100hz.mp3
curl -i -X POST "https://api.soundcloud.com/tracks.json" \
-F 'oauth_token=********' \
-F 'track[asset_data]=#7400kb_307sec_192kbps_44100hz.mp3' \
-F 'track[title]=A 7.4MB track' \
-F 'track[sharing]=public'
HTTP/1.1 100 Continue
HTTP/1.1 413 Request Entity Too Large
Date: Wed, 06 Nov 2013 18:23:21 GMT
Server: ECS (lhr/4799)
Content-Length: 0
Connection: close
thanks
We have the same issue with soundcloud. Seems to be an issue in their nginx.conf (webserver
configuration).
Please contact Soundcloud support for developers.
Was an issue in SoundCloud API routing. Has been fixed now.
For details see comments at:
Soundcloud: increased 413 failures (Request Entity Too Large) on upload