I'm working on a solution for a client integrating Orders and Inventory between Ebay and Big Commerce. I'm setup in the Developer environments for both sites, however I'm having some issues with the API configuration and Calls. I'm looking for assistance from anyone with API experience specifically in either of these environments. I have the MBS ebay Webservice.fmp12 configured, however neither this or the Development Toolbox environment in Ebay functions properly.
Break down the problem do that we can help. There will be an error report. It will have some info and the error will be caused by something: data, auth, or whatever. Tell us what that error is.
Thanks for the feedback, good suggestion. I am using Christian Schmit of MBS ebay Webservice DB as a starting point. I can Log on to the sandbox account, however when I attempt to GET CODE (Step2)
(Refresh Code) I don't receive a response with the code. There is no debug log for this step.
The script is looking for a response code using a pattern count style search for "eBay Login Accepted". I use the inspector and don't see the search text nor the code.
When I try to Refresh (Step 3) I get the error, I've attached a debug log for this.
Any help would be most appreciated
MBS Plugin 13.1.0.07 with CURL 7.88.1 in FileMaker Pro Advanced 19.6 on macOS.
Trying 209.140.129.47:443...
Connected to api.sandbox.ebay.com (209.140.129.47) port 443 (#0)
ALPN: offers http/1.1
TLSv1.3 (OUT), TLS handshake, Client hello (1):
TLSv1.3 (IN), TLS handshake, Server hello (2):
TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
TLSv1.3 (IN), TLS handshake, Certificate (11):
TLSv1.3 (IN), TLS handshake, CERT verify (15):
TLSv1.3 (IN), TLS handshake, Finished (20):
TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
TLSv1.3 (OUT), TLS handshake, Finished (20):
SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
ALPN: server did not agree on a protocol. Uses default.
Server certificate:
subject: C=US; ST=California; O=eBay, Inc.; CN=open.api.sandbox.ebay.com
start date: Aug 31 00:00:00 2022 GMT
expire date: Aug 31 23:59:59 2023 GMT
issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Organization Validation Secure Server CA
SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
using HTTP/1.x
Server auth using Basic with user 'redacted'
POST /identity/v1/oauth2/token HTTP/1.1
Host: api.sandbox.ebay.com
Authorization: Basic R29yZG9uQmEtSGVyb091dGQtU0JYLWUyZTRlMGIxNi0wYmU3ZWQxYzpTQlgtMmU0ZTBiMTY4MWU4LTZhZWYtNDcxNS1iMjIwLWZlY2U=
Accept: */*
Content-Length: 89
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=&redirect_uri=Christian_Schmi-Christia-MBSTes-kbrjfkryTLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
old SSL session ID is stale, removing
HTTP/1.1 400 Bad Request
rlogid: t6ldssk%28ciuoopu0asu%60pkal%3C%3Dosuhbpro.233g1%2Bsfvu7371-186c78a5620-0xf1
x-ebay-c-version: 1.0.0
x-ebay-client-tls-version: TLSv1.3
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
set-cookie: ebay=%5Esbf%3D%23%5E;Domain=.ebay.com;Path=/
set-cookie: dp1=bu1p/QEBfX0BAX19AQA**67cc8651^;Domain=.ebay.com;Expires=Sat, 08-Mar-2025 18:02:57 GMT;Path=/
content-type: application/json
content-length: 128
date: Thu, 09 Mar 2023 18:02:57 GMT
server: ebay-proxy-server
x-envoy-upstream-service-time: 7
x-ebay-pop-id: UFES2-LVSAZ01-apisandbox
{"error":"invalid_grant","error_description":"the provided authorization grant code is invalid or was issued to another client"}Connection #0 to host api.sandbox.ebay.com left intact
By just looking at the names of the keys of the key-value pairs in the above content, I see that no value is being transmitted for the "code" key, and the value included for the "redirect_uri" key does not appear to be a URL.
This makes me wonder if one or more values that are being fed into the code have been transposed, or lost. This could happen if the code was being fed some variables from a script or calculation, and the wrong variable was supplied in one or more locations. This could also happen if this code is being invoked based on values that have been entered as field data in some record, and the data entry mistakenly wound up with some wrong value(s) in some field(s).
I would suggest looking for any ways in which something like the above might have happened, i.e. where some of the values that feed into this have been transposed or otherwise handled incorrectly.
I'll note, however, that I am not at all familiar with this particular service -- I have no expertise specific to it. I am just calling out things which are catching my eye as things that don't look quite right in a general sense.
The names of the data is quite confusing:
I get the Client ID and Secret Key, but then I get ACCESS TOKENS and USER TOKENS and Code.
I've done a good amount of api work mostly with Google, so I get the idea. The message "was issued to another client" stem from the URL OPENING a Browser rather than a web viewer.
Upon review I did not that Christians example file has a .php script file to GET the code. This explains why the script doesn't work. I would ask where this script file should be placed, in either a server hosted environment of standalone file. I am hosting the file on Ubuntu Server 19.6x.
Hi @BoloMan28 , as @steve_ssh mentioned, it looks like your auth code is blank, and the redirect uri is not a valid URL.
You can get the correct redirect_uri in your ebay developer account at eBay Developers Program Registration | eBay, then click User Tokens under the key you created. From there you can copy the correct redirect_uri.
Click see all to copy the full url. It should look something like this:
Log out of eBay and delete cookies/site data (or use a different browser) and paste in this URL. Log in with your eBay account and you should get a code parameter back in the redirect URL. This is the code you need to include in the request from FMP for an access token.
FYI- the auth code is only good for a few minutes, so be ready to use it to request an access token as soon as you get it back.
When you request an access token, you'll also get back a refresh token that can be used to generate a new access token, so you only have to do the browser login once. Then the refresh tokens will work for 18 months before you need to login again and generate a new code.
I have done api calls before mostly with Google apis, so I get the idea how the authentication works.
Q1 - Regarding the the "code" is this the same as DevId? I don't see any details of this is any of the documentation.
Q2 - The Filemaker file is hosted remotely on my server (FMS 19.6 Ubuntu 20) and the MBS example came with a small .php script, presumably to tie into the script to "Get Code". Where should this file reside on the server, http root? I wasnt eve sure the .php file would still work as I realize FMS has dropped native support for .php. As a work around I have been looking into the response html for the code.
I'm not sure on how to implement the php file, but you don't need it in this case. Just open the auth url in the browser, login, and then copy the code from the new url after successful login. It will be URL encoded, so decode it and use this value in the body the request from FMP to get an access token.
You only have to do this browser login once to get the auth code, and then you can do the rest in FMP and continue refreshing the token without needing to login through the browser again. This is how eBay's engineers advised me on building an integration a few years ago because we didn't need to auth in different users and upload from different accounts.
However, if you want to build your integration to support different ebay developer accounts and client IDs, then the php script or other browser handoff would be more appropriate. But for a single account, I wouldn't worry about trying to program a way to catch the auth code. Just do that part in the browser, then paste the decoded version of the auth code into your FMP script and run it within the 5 min window before it expires.
One other tip- request the access token from Postman first, and get that working before trying in FMP. The cUrl request formatting is such a pain to get right, so it's hard to know if the problem is your formatting or the code itself. Once you know you have it right in Postman, then replicate that in FMP.