I there, I am working on some automation of various configurations within incontrol2. I am running into a issue when editing captive portals.
When performing a PUT or DELETE request to https://api6.ic.peplink.com/rest/o/{{oid}}/n/{{nid}}/cp/{cpid} or a POST request to https://api6.ic.peplink.com/rest/o/{{oid}}/n/{{nid}}/cp. The following error is returned:
401
{
"error": "unauthorized",
"error_description": "Access denied for this resource, oauth access is denied"
}
The request is send with a authentication header containing a bearer token. With the same authentication various other resources can be accessed. For instance https://api6.ic.peplink.com/rest/o/{{oid}}/n/{{nid}}/outbound_policy works fine.
Is anyone else running into similar issues, or can someone at Peplink tell me more about this error and how I can provide the correct authentication.
Mind you that I am running this as an automation workflow, creating captive portals via the incontrol dashboard works as expected. But that is not the goal here, the goal is to automation various manual tasks in preparation of a bigger rollout of hardware.
You probably identified the API end point from the browser’s developer tool when accessing IC2 website. The endpoints you listed are only accessible through web sessions but not OAuth2. All available OAuth2-based API endpoints are published in the InControl API documentation.
BTW, the host name in the OAuth2-based API endpoints should always be api.ic.peplink.com.
1 Like
Thank you for your reply. As you probably know, the listed endpoints on the provided link only provide some basics, a lot of the endpoint I require are not listed. Like the captive portal, but also outbound_policy which I listed in my post. Even though the outbound_policy works perfectly fine with API token authentication.
I know these endpoints are not officially given out by Peplink for me to use, but this is a necessity to automate some of our deployment processes. I am aware that I wont get full support here, and that these endpoints that are normally only used from within the Incontrol2 dashboard and might be subject to change without notice.
However, I think this is some basic functionally that needs to be part of the product. I am not looking for a workaround here, I am looking for a solution.
outbound_policy is not listed, but it works just fine with API token authentication, why is this not the case for the captive portal endpoint? How should I authenticate for the captive portal endpoint? Are there more endpoints like this?
Mind you that there are plenty other endpoints that are not listed and work fine with token authentication. Like LAN network settings, starlink configurations, Route advertisements, outbound policies, etc.
I am rolling out about 80 new networks that are within their own groups, and these group configurations differ. We have automation in place for all other vendors we use, this should be basic practice within modern networking.
Internally a support ticket with Peplink was raised. The following is a brief summary of the comments we got back.
Basically, we do not support creating captive portals via API. This is not publicised in the document and not supported so any and all issues that arise from this are unfortunately within your own risk. The fact that you are getting an access denied message thus is intended behaviour and will not be fixed.
As a note same thing applies to all of the API calls that are not documented. If it works for you, that's great, but once again, keep in mind that you are doing these things at your own risk so if there are some issues from undocumented API calls, that is out of the scope of what we can help with.
1. Is there any plan for full official API access? The current API access is most likely as full as it will be. If there are other features that come to IC2, API documentation should be updated to reflect the new features.
2. What is the current decision process for deciding which parts of the API are given to end users? Usually, in the API we provide mostly GET requests (the official documentation) and some PUT/POST/DELETE calls that are tested and confirmed working. The undocumented API calls are left as working to allow for some flexibility, however since they are undocumented we do not support them officially.
3. Can we as an organization request more endpoints to be come available? Regarding feature requests, you can do that via Peplink forum or through ticketing system. Writing a forum post under Feature Requests is preferred though since it allows for us to gauge if the feature request is getting traction and how many community members are looking for said feature. I can forward feature requests to relevant team members as well, but this is less "official" and if the feature request is difficult to implement it might be outright rejected or placed in low priority with no ETA.
Because of this, a separate feature request will be raised requesting more complete API access, as current functionality is extremely limited compared to competitors.