question

We are using are Account Level Id but this returns just the supervisor extn in the API results (which never answers a call). What we need is the hunt group stats which is available via  https://service.ringcentral.co.uk/settings/calls.html#detailed and chossing the Hunt Group ext. If we try to use the hunt group extn "1" in the API we get  a Page 400

I don't quite understand the issue. Could you please create a new thread and describe it in detail? In particular, are you trying to get call logs for all the extensions or just for hunt group extension?

Thanks it is now under 
Hunt Group Results

That route should be available if you have authenticated using an Admin-level user account.

I would recommend using a Subscription or  Webhooks + JIT API requests to fetch Message-Store and Call-Log resources (due to the rate limits associated with each of these API resources). You do not 'have' to use this approach, but it is recommended.

Thanks for your quick answer we are definitely using an admin level account. Perhaps the problem is just syntax we are substituting
username=44139279****&extension=301  which is our admin phone number and extn with
username=44139279****&extension=1 which is the hunt group extn

An alternative would be to use the 'phoneNumber' property (of either Call-Log or Message-Store) to filter the results (in addition to the other query paramters) for a specific phoneNumber (which could be a Group number IIRC).

I am already sending a phone number as part of the query (the account number) see above. Apart from that I just send the date parameters further filtering will jsut reduce that ?

You're using the phone number and extension (but that doesn't necessarily mean you are authenticated as that particular user's extension/phoneNumber).

That is why I suggested this might be an approach.

You are not required to use an administrative account, but if you want your development team to be able to build a solution which has administrative capabilities such as requesting all call logs for all extensions, then this is what must be done. It is entirely dependent upon your use case(s).

You're required to have an admin account to view all logs across all extensions, which means if you want to do any sort of custom reporting on calls across the entire organization that you have to give a developer an API key with administrative access. More secure providers provide you with roles for accounts to limit them to at least be complete read-only accounts that can access all of that stuff. Having to give your developers an API key with full administrative access is nuts.

What you have described appears to be an internal business issue between you and your development team and doesn't have any relevance upon RingCentral's decision on how we provide our business services via the API.

There are ways to work around this situation if it is a requirement for how you operate with your developers:

1. Build a micro-service which can only be accessed from within your firewall which allows you to store your user credentials, and your developers to make an authenticated GET request to fetch an access_token on your behalf (this would allow you to keep control of your RingCentral account, while also giving your developers the tools they need to achieve your goals without sharing your actual credentials).

2. If you're an administrator, you could create the application and API Keys, and use the API Explorer to fetch a valid access_token, then give that token to your development team. Then just have them use refreshFlow to update the token.

While I understand that different businesses have different needs and requirements. Modifying our Platform's business logic to suit this use case is not pragmatic and will not be prioritized. A change of that size could potentially impact the thousands of other companies whom have already successfully developed solutions using our existing API and Platform.

How is it an "internal business issue" between me and my development team? Do you typically give internal development teams, which do not normally have administrative access to RingCentral, access to API keys with administrative access? We're a network security company, this is how things get compromised. You're not offering this service in a secure way, which is, well, bad.

I've made this conversation private.

I understand your security concerns. The reason I said it was an internal business issue is because our API doesn't stop you from achieving your goal of retrieving account-level call log data (which means this is your decision, not ours to make). If your organization chooses to have an increased-level of security that is perfectly acceptable, but saying our API is "bad" or "nuts" because we do not meet your particular requirements is counter-productive. You are the first to have something negative to say about this, and we have over 3000 companies and developers who have registered and developed with our Platform.

Does that mean our Platform and API are perfect...absolutely not. Which is why the "BETA" flag for our platform is still conspicuously placed. Things may change (or need to change).

CallLog API resouces in RingCentral are ReadOnly:  https://developers.ringcentral.com/api-docs/latest/index.html#!#RefCallLogInfo.html. There are no PUT, POST, DELETE routes exposed in basic API plans.

I provided a couple of alternatives in my earlier post which might help address your security concern. Other solutions exist as well, depending upon your development approach and use case requirements.

Your team could build strictly off of our API documentation and using their own accounts.
Your team could implement 3-Legged OAuth and you could authenticate without ever sharing your account.
You could extract an example of what a complete, account-level call log response would look like, and let them develop from that data.

There are dozens of ways to solve your requirements. We may release an updated or refactored Roles & Permissions system in the future, or if there is enough demand from other customers to deliver the requirements you have detailed...we might roll this very feature out to our developers.

At this time we do not have any immediate plans for shipping a feature for this use case.