ActiveCollab has some very strong features in the UI related to resource management - capacity, scheduling, workload, calendars etc.
I would like to access these data set via the API, but nothing seems to be available per the documentation here: https://developers.activecollab.com/api-documentation/index.html (except Days-off)
Specifically, I'm looking to request daily capacity for all users.
No googling or dialogue with their support have been able to point me to an answer.
Related
Can Whatsapp Cloud API be used for business as a reseller?
like what is the difference between the new Whatsapp Cloud API and the API we get from Resellers?
Also, is there an API to automate the signup process?
Those Resellers you mention are often Business Solution Providers (BSPs), or BSP partners.
So that implies, in order to be WhatsApp Cloud API reseller, you will need to be either a BSP or BSP partner.
The Cloud API architecture significantly simplifies the BSP’s operational and infrastructure requirements to integrate with WhatsApp Business Platform.
See "What is the architecture of the Cloud API?", in Cloud API FAQs
As a BSP or its partner, a reselling program is available to you both for On-premises/Managed WhatsApp Business API and Cloud API. However, you need to take into account Cloud API is relatively new and all BSPs are currently adapting/expanding their current solutions to new service offered by Meta.
In other words, Cloud API is not yet available everywhere and current services offered by BSPs are more versatile and feature rich than Cloud API until this will eventually change.
The largest WhatsApp BSP is 360dialog, offering WhatsApp Business API integration Platform as a Service, and on-premises plans.
Since you asked about differences between Cloud API and BSPs, let me give a short comparison between Cloud API and 360dialog key differences, as an example:
Differences
360dialog
Meta Cloud API
Message Throughput (Per Second)
Flexible scalability setups for small to large businesses. Send up to 70 text messages per second for single-connect. Send up to 250 text messages per second for multi-connect.
Up to 80 messages per second of combined sending and receiving (inclusive of text and media messages). In the event of high system loads, a business may experience reduced message throughput. Starting in July 2022, support up to 250 messages per second of combined sending and receiving (inclusive of text and media messages), by request
SLA - Uptime
Standard and Premium support with different SLAs: >99%, >98%
Goals of 99.9% at GraphAPI.
SLA - Disaster Recovery
Average response time of 4h. Escalation Path to Meta team after 360dialog investigation.
No SLA
Sources:
Full comparison table of differences between On-premises and Cloud API solutions.
360dialog Pricing
So, as you might've noticed, with BSP will work more closely with you as a solution provider and will offer you more flexibility depending on the business scale.
WhatsApp Business API requires some developer effort, but there are also different WhatsApp API based solutions that make this whole process a lot easier.
One of them is get.chat WhatsApp Business Team Inbox & WhatsApp Integration API which will help you to integrate with WhatsApp much faster. Plus, it will enable access to non-technical people in your team/company, too!
I am a co-founder and CTO so I am open to answer any questions if you want to know more about our solution. Here is also a link to the docs if you're interested in learning more by yourself.
Further reading:
An easy guide about WhatsApp Business API by get.chat
Cloud API FAQs - offered by Meta directly
On-premises WhatsApp Business API FAQs - hosted by BSPs and resellers
now there are two types of Whatsapp Business API. The ones from the diferent Busniness Solution Providers (BSP) and the one from Meta (Whatsapp CloudAPI).
I think that untill now, each BSP has develped it´s own APIS starting off the one provided by Meta. So each BSP offeres his own APIs (endpoints, libraries..).
Meta has now published the API offered to the BSP and now every business has direct access to it. No more BSP are needed, unless you want and easy to use solution.
The main difference I see between BSP and Meta API is that BSP are easier to use. MetaAPI is a huge complex system.
Now you don't need to look at BSP, all you can do is set up, create a business account and developer effort to make things work according to your business desire, and create message templates.
please have a below link for further eloboration.
https://www.facebook.com/business/help/338665938087159
Kindly, can anyone differentiate between System api and Process api?
Please provide answer in Generic terms, as i am unable to find on internet.
A system api abstracts from an existing system. It talks to the system in the language of the system (e.g. SOAP, direct Java calls, SAP calls, etc.). To the outside world it offers a clean API (usually REST with http and json). When you do a good job implementing your system api, you can exchange your existing system with a different/new one without changing the api of your system api to the outside world: Just implement a new system api with different adapter logic.
A process api should talk REST on "both ends". It calls one or several system apis to do its job. The process api orchestrates different jobs.
When you need more information, do a search with "api led connectivity"
A System API is a layer you build on top of a system, which handles all system specific connection quirks and settings. It then exposes these resources and it's logic in a standard format (usualy REST but you're free to choose something else like SOAP) to the rest of your API's. Like Roger Butenuth states:
"When you do a good job implementing your system api, you can exchange
your existing system with a different/new one without changing the api
of your system api to the outside world: Just implement a new system
api with different adapter logic."
A process API is where you keep your logic and orchestration, it does not 'talk' to end systems directly but instead connects to system API's to get it's data.
A process API should idealy only talk REST on both sides and can aggegrate data from multiple systems.
An example of a complex process API would be an "items you've ordered" API which takes in a user id as it's input, then talks to the system API of a CRM system to get the id used by the "order history system API".
However this API might only return a list of orders without any article information besides an article id. So our Process API then enriches this list with Article information fetched from "article information system API" with the id from the list.
I know it's out of the scope of the question, but for the sake of completeness i'l shortly explain the third variant as well:
An Experience API can be seen as a doorway into your API network, every (type of) client has different information needs and can communicate in different protocols.
It is the Experience API's responsibility to provide ALL the information required by a client in a format they support.
This takes the responsibility away from a client to know where the information needs to be fetched from.
(Customer info from CRM, Order info from proprietary sys one, Article info from article DB)
This concept of design has as a bonus that if when for example, the mobile app your company is making, gets some new functionality which requires extra data.
You can update the "mobille app experience api", which would leave your "superexpensive IBM Experience api" unchanged. Cutting down on development costs as you don't need to implement any changes in your other api consumers which would be the case had you had only one api.
I think the main difference is where you are implementing business process and rules/logics.
System API, within the scope of your design, are atomic APIs which will be used to construct higher level API (experience APIs). Process API is the orchestration layer where you can use Mulesoft flows to implement business process or logic.
System APIs do the heavy lifting work of CRUD operations.
Process APIs focus on business logic
System API's are underlying all IT designs are center frameworks of records that are regularly not promptly accessible because of its many-sided quality and network concerns. APIs give a method for concealing that many-sided quality from the client while uncovering information and giving downstream protection from any interface changes or legitimization of those frameworks.
Process APIs exemplify the fundamental business forms that cooperate with source and target frameworks or channels through an arrangement of framework APIs. For instance, in a buy arrange process, there is some rationale that is regular crosswise over items, geologies and retail channels that can and ought to be refined into a solitary administration that would then be able to be called.
And you will get some more clarity from this article https://dzone.com/articles/api-the-backbone-of-the-software-industry-know-how
System API and Process API will be part of API led connectivity.
System API is like awrapper service to either a main data base or saas platform
Process API involves application logic to validate search or query parameters
Long time ago, I took and passed the Google Analytics IQ certification test. At the time, I don't believe there were such things as Core Reporting API, Management API, and Metadata API (and probably some other Google Analytics related API's that I don't know about). Now that I am going through the Google Analytics IQ certification training course again (provided by Google, presented by Justin Curtoni?? I believe that's his name), I found that they now have Core Reporting API, Management API, and Metadata API.
I am a computer programmer by trade; so, I have no problem with programming using these API's. However, what I don't understand is, what do these API's buy me that the Google Analytics UI cannot offer? There is no reason to write a program that utilizes these API's simply because I can do it. To me, the existing Google Analytics UI has a lot of tools, reports, and other features that quite extensive. I am hoping that some of you can help me see something that I am probably missing.
The APIs are primarily for programmatic access. For example, if you need to create 1000 accounts all with the same property/view structure and then maybe add a few view filters to each of those accounts, you'll probably want to use the Management API. Doing that by hand would be a nightmare.
The same thing is true for the reporting API. Maybe you want to set up task that runs every monday morning and reports on the previous weeks data. And maybe you want to display that data on an internal dashboard for your company using some fancy charting library. You'd have to use the API to get the data.
Dashboards (executive summaries; managers often want nice visualizations instead of boring drill-downs)
Custom reports for user groups that do not have a Google Account or are not supposed to have access to full reports (e.g. Affiliates)
advanced filtering and aggregation (GA report cannot do everything)
You can combine analytics data with external data (e.g. you are not allowed to store personally identifiable information within GA; but you might store a custom key that allows you to link analytics data to customer data from you CRM or fulfillment system)
Machine-to-machine communication; I once did tracking for an airline that needed trend data on what people where searching for and what they where actually booking; that data was used to allocate/withdraw resources from busy/lame flights, and part of this was done by hooking up GA to their backend system
Take a look at the GA Partner Page. I would say the primary reason is to "liberate" GA Data from outside of GA itself. As Eike mentions, you can create dashboards and combine this data with other sources for a complete "View" of your online presence.
HI I guess there is no definite answer. Here are some things you can do with the APIs:
Automating AdWords CRO based on keyword ad and campaign performance.
Scoring leads based on Analytics data (Engagement with different items) and external data from a CRM.
Collecting unsampled data using multiple daily queries
Filtering using several dimension.
Tracking conversions for periods longer than supported by AdWords.
Looking at a funnel via segments
Analyzing funnels with non-linear structures
Create more robust alerts
Export data to BigQuery and analyse it together with data from other systems.
Create Machine learning apps for behavioural customizing your site.
Create a dashboard with data from multiple views
Use product recommendation to implements "better together" in an online store.
Automate creation of accounts and properties + their integration in a Hosting provider's console.
Cheers!!
With regards of using the /threads object from Graph API I want to know if a public figure account has some limitation regarding the amount of received messages / day and to know if a Facebook application that reads them using /threads has limitation to access the entire list.
Suppose I develop an app used by a public figure that would receive 500k(or above) messages a day. Can I access all the messages (using a paging technique, of course)? Is there any chance to have the account removed or app disabled because of extensive usage of messages? If there is a need to pay for an account (and-or application) with such a usage, where do I find the pricing list?
Thank you.
I would like to know how to find badwith usage and number of instance for azure. Is these features available in azure api ?
Bandwidth usage no. It is only tracked in billing and that currently has no open API. You can track bandwidth usage yourself if you funnel every request thru programmable API that can capture the size of data they're pushing out. (Incoming data is now free).
Number of instances, yes. Two ways to do this:
1) If done from "outside" of your deployment, you can use Service Management API to navigate to a specific Deployment and call this method: http://msdn.microsoft.com/en-us/library/ee460804.aspx
2) If done inside a role, you can use RoleEnvironment.Roles["role-name"].Instances.Count