New article
Recently updated
Testing API Connection
This article documents how to test the Huddle API connection using Postman on a simple basis to get the auth token. Note that you need to have setup a ClientId for access with Support to get this. Your account must also include this facility for this to be setup.
It is broken down in the to methods for this:
- Client Credentials
- Auth Code
- Troubleshooting
- Further Reading
1. Client Credentials
Using Postman
For this Client Creds method, you can use the Postman application to test this. You can create a new collection and add a new request to it, like this:
On the request, set it to POST and to https://login.huddle.net/token if you are on the Global server. If you are on our FedRAMP server, you should be using https://login.huddle.com/token. You can tell which server you are using by if your Huddle address ends with .net for Global or .com for FedRAMP.
Go to the Body part and you need to populate this with:
- client_id: What was confirmed as the ClientId by Support
- client_secret: What was confirmed as the client secret by Support. This should be kept safe.
- grant_type: client_credentials
- redirect_uri: What was defined for this when Support set this up. This needs to be confirmed with Support as it is possible to leave this empty (NULL) but this may be problematic to use. If not confirmed, it will default to NULL. We can update this in Support, if need be, but the default value we recommend, if you do not know what this should be, is: urn:ietf:wg:oauth:2.0:oob
If you then send that in Postman, you will receive an access token, as shown:
The access token is then used in the headers of your next request, as per the guide on Home · Huddle/huddle-apis Wiki · GitHub
Note that if your environment has an enforced proxy this may error. In that situation, you would need to check the Settings > Proxy tab and set it to use the System proxy. If that doesn't work then you may need to speak to those responsible for your environment for how to configure this to get through the proxy.
Using Curl
The method for doing this with Curl uses this syntax (remember to change .net to .com if connecting to the FedRAMP server):
curl -X POST "https://login.huddle.net/token" -H "Content-Type: multipart/form-data" -F "client_id=CLENTID" -F "client_secret=CLIENTSECRET" -F "grant_type=client_credentials" -F "redirect_uri=REDIRECTURL"Note that if your environment has an enforced proxy this may error. In that situation, you would need to use something like this where http://127.0.0.1:900 is your proxy address and the assumption is that it is using the Windows authentication:
curl -v -x http://127.0.0.1:9000 --proxy-negotiate -U : -X POST "https://login.huddle.net/token" -H "Content-Type: multipart/form-data" -F "client_id=CLENTID" -F "client_secret=CLIENTSECRET" -F "grant_type=client_credentials" -F "redirect_uri=REDIRECTURL"If that doesn't work then you may need to speak to those responsible for your environment for how to use this to get through the proxy.
2. Authorization Code
For the Auth Code method, this is a two step process. This can be tested, first using a browser, by navigating to the following, replacing CLIENTID and REDIRECTURI accordingly. If using our FedRAMP server instead of our Global server, replace '.net' with '.com'
https://login.huddle.net/request?response_type=code&client_id=CLIENTID&redirect_uri=REDIRECTURI
This will prompt you to login to Huddle as user. After logging in, you be presented with an access code.
Next you would use the access code gained here in the application you are using to do the next part.
Using Postman
On the request, set it to POST and to https://login.huddle.net/token if you are on the Global server. If you are on our FedRAMP server, you should be using https://login.huddle.com/token. You can tell which server you are using by if your Huddle address ends with .net for Global or .com for FedRAMP.
Go to the Body part and you need to populate this with:
- client_id: What was confirmed as the ClientId by Support
- grant_type: authorization_code
- redirect_uri: What was defined for this when Support set this up. This needs to be confirmed with Support as it is possible to leave this empty (NULL) but this may be problematic to use. If not confirmed, it will default to NULL. We can update this in Support, if need be, but the default value we recommend, if you do not know what this should be, is: urn:ietf:wg:oauth:2.0:oob
- code: The access code received in the previous part
If you then send that in Postman, you will receive an access token, as shown:
The access token is then used in the headers of your next request, as per the guide on Home · Huddle/huddle-apis Wiki · GitHub
Note that if your environment has an enforced proxy this may error. In that situation, you would need to check the Settings > Proxy tab and set it to use the System proxy. If that doesn't work then you may need to speak to those responsible for your environment for how to configure this to get through the proxy.
Using Curl
The method for doing this with Curl uses this syntax (remember to change .net to .com if connecting to the FedRAMP server):
curl -X POST "https://login.huddle.net/token" -H "Content-Type: multipart/form-data" -F "client_id=CLIENTID" -F "grant_type=authorization_code" -F "redirect_uri=REDIRECTURI" -F "code=ACCESSCODE"Note that if your environment has an enforced proxy this may error. In that situation, you would need to use something like this where http://127.0.0.1:900 is your proxy address and the assumption is that it is using the Windows authentication:
curl -v -x http://127.0.0.1:9000 --proxy-negotiate -U : -X POST "https://login.huddle.net/token" -H "Content-Type: multipart/form-data" -F "client_id=CLIENTID" -F "grant_type=authorization_code" -F "redirect_uri=REDIRECTURI" -F "code=ACCESSCODE"If that doesn't work then you may need to speak to those responsible for your environment for how to use this to get through the proxy.
3. Troubleshooting
Possible errors you might receive and their resolutions:
- The client is forbidden.
For the Auth Code method, this suggests the ClientId hasn't been added and approved to every company for every account holding a workspace that the user trying to login to the API is a member of a team in. This would need to be raised to Support to see if it is possible to add the ClientId to all the companies involved. - (56) CONNET tunnel failed, response 407 or just a 407 response
This has been seen where a proxy on the client's network side, is blocking the connection so extra work will need to be done to get your request through the proxy. Some possible ways through a proxy are documented above too.