Mashery Support Portals Developer Blog

RSS Feed

New Feature: Executive Summary Reporting API Methods

Mashery is pleased to announce the availability of new Reporting API methods that allow access to the data behind the Executive Summary report in the API Control Center. The Executive Summary is a 1-stop shop for API Metrics designed for sharing with executive leadership and for broadcasting widely to a general audience. The visually intuitive report delivers a high-level view across your API Program and includes new metrics and analytics to drive new business strategies and initiatives. The Executive Summary takes advantage of the latest data visualization techniques to deliver a "showcase-ready" dashboard with specially crafted data-driven narratives across three perspectives, Management metrics, Technical metrics, and Developer/Partner metrics. Now, with this release, customers can access this data and pull into their own visualizations; for example, why not create a custom dashboard that is thrown up on a nice big TV in your office, displaying some of the important metrics surfaced by the Executive Summary feature?

Screenshot of Executive Summary


Screenshot of API Methods in IO Docs

Check out the new methods in the V2 IO Docs!

Planned Java Upgrade Notification

We are going through a planned JRE upgrade to the latest Java version 1.8.
If you are using SSL to communicate between Mashery and your API back-end systems , there will be some older ciphers that may not be supported with this upgrade . To avoid any API call failures related to usage of such unsupported ciphers in your API back-end systems,  please ensure your systems are migrated off those ciphers. In addition, we recommend you make some test calls against a Mashery test environment that will be made available with the upgraded JRE.


Supported ciphers


Unsupported ciphers



If you have any further questions please contact Mashery Support at

Administration Tool SAML SSO

We are thrilled to announce, with today's release, that TIBCO Mashery has provided its customers the capability to have their administration users login into the TIBCO Mashery administrative web applications with their enterprise credentials using SAML Single Sign On (SSO). For API providers, sometimes having admins create separate and independent user accounts in the TIBCO Mashery system is counterintuitive to their centralized ID Management and security policies. And it generally is not very efficient for users either: admins have to remember different user credentials from their current corporate ones. SAML SSO for the administration dashboards is part of TIBCO Mashery’s broader vision to allow us and our customers to:

  • Scale and optimize their organizations daily API management with quick and efficient user approval and provisioning. As a part of Single sign on process, provisioning over SAML allows our customers to create on-demand accounts. We have now simplified scenarios where users need to be dynamically provisioned, by combining the provisioning and single sign-on processes into a single message.
  • Increase security by allowing authentication against customer’s ID management system. With this feature, we simply check users' corporate credentials using their employer’s directory, instead of our own directory and eliminate the need for separate Mashery credentials.
  • Increase user adoption: users only need to memorize a single password to access both their enterprise’s site and Mashery. Users are more likely to use TIBCO Mashery on a regular basis.
  • Reduce support costs and inefficiency. Now, customers don’t have to wait for Mashery Admins to approve accounts individually and/or remove users after they have left an organization.

Screenshot of Admin SAML SSO Enabled for API Program Login

Screenshot of admin SAML SSO

To understand more about how this feature works and how your API program might benefit from this feature, please contact your TIBCO Mashery CPSM or Support for information.

New Feature: Executive Summary

TIBCO Mashery is pleased to announce the availability of a new reporting feature, Executive Summary, for those customers currently using the new API Control Center. The Executive Summary is a 1-stop shop for API Metrics designed for sharing with executive leadership and for broadcasting widely to a general audience. The visually intuitive report delivers a high-level view across your API Program and includes new metrics and analytics to drive new business strategies and initiatives. The Executive Summary takes advantage of the latest data visualization techniques to deliver a "showcase-ready" dashboard with specially crafted data-driven narratives across three perspectives, Management metrics, Technical metrics, and Developer/Partner metrics.

A sample screenshot of the Executive Summary in action can be seen below.

To understand more about how this feature works and how your API program might benefit from this feature, please contact your TIBCO Mashery CPSM or Support for information.

Updated Control Center User Experience

The user experience for the TIBCO Mashery API Control Center has changed a bit with last night's release (2/17/2015). After getting feedback on how navigation was working and with an eye towards other future enhancements, the location of the "New" buttons, on "List" pages, has been changed, and replaced by an icon, as well as an update to the "View" pages for API Definitions, Endpoints, Packages and Plans. Examples of the changes can be seen below.

Updated "List" Page with "New" button location


Screen shot of new "View" page with updated actions locations and icons.

SSL v3 Vulnerability Update

Mashery addressed the SSLv3 vulnerability aka Poodle in our environment within few hours of learning about it on the afternoon of October 14th 2014. After carefully reviewing the likelihood and impact of this vulnerability, we determined the risk to be High, especially as “Poodle” became a widely known vulnerability that could potentially expose our customers’ data. We decided to disable SSLv3 immediately with an option to rollback on a customer case-by-case basis.

Prior to disabling SSLv3, we informed our customers about our decision and made that change (i.e., disabling SSLv3) during our weekly maintenance window (11 PST 11/14/14) on the same day. We also recommended our customers to use TLS 1.0 or above as per the industry best practice. Follow up communications were sent to our customers to keep them abreast on the status of the change.

We did not come across any significant interruptions due to disabling SSLv3 in our own, or our customers’, operations. We made every effort to address customer issues as early as possible. Only a very small number of customers reported issues caused by the necessary change.

As always, customers’ information security has always been one of our top priorities and we will continue to do our part to safeguard customer data.

Please contact customer support at, TIBCO Mashery Support Portal, or call our toll free number: 888-667-1588. You can also follow our updates on our Twitter stream, @MasheryOps.

For more information about this vulnerability, please refer to

Advisories CVE-2014-6271 and CVE-2014-7169 for GNU Bash

A security advisory was released on 09/24/2014 related to a vulnerability, now informally being referred to as Shellshock, that exists in GNU Bash.  For more information about this vulnerability, please refer to CVE-2014-6271 and CVE-2014-7169.  An incident response is in effect and immediate actions have been taken by TIBCO Mashery to address this vulnerability.  We will update you with more information as it becomes available.  Please contact with questions or concerns.

Mashery understands the impact and is working towards building and deploying the patch for Mashery Local 2.2 customers by end of next week. Also Mashery Local is less vulnerable as it sits behind the firewall.

More on CORS

We added a bunch of important improvements to Mashery Traffic Manager recently that really rounds off our support for a very important industry standard CORS. Hope you find them useful !

  • If Allow requests from any domain is set to No on the Dashboard then:
    • The API administrator can specify a comma separated "List of domains allowed". The requests made from domains that are not in the list are denied.
    • To allow for more flexibility, API administrator can also select if "Sub-domain matching allowed" is Yes.  By default, exact domain matching process is followed. 
      • In case of an exact domain match, for e.g. if, is specified in the “List of domains allowed”, only requests for are allowed.
      • In case of a sub-domain match, for example, if is specified in the “List of domains allowed” on the Dashboard, requests coming from, and are accepted as valid and allowed through
      • Note that in either of the above cases,,, and are not considered identical and are never matched
  • CORS specification does not allow any custom header to be processed by the browser client application except if the server explicitly white-lists those headers via Access-Control-Expose-Headers. With the "List of headers to expose" field, API administrator can white-list the headers  that Traffic Manager will add to Access-Control-Expose-Header in the response.
  • API administrator can specify a comma separated "List of headers allowed". These are used to validate against values in Access-Control-Request_Header and determine if the request can be allowed through or not. If allowed, corresponding headers are added to Access-Control-Allow-Header back in the response. If this field is left empty, any incoming header is allowed – this is to maintain backward compatibility
  • API administrator can specify whether cookies are allowed for the CORS requests or not. By default, cookies are not allowed. If cookies are allowed, Access-Control-Allow-Credentials is set to true on the preflight response and CORS response.
  • To facilitate debugging scenarios for CORS request and response, any selected Mashery specific debug headers are white-listed via Access-Control-Expose-Headers so that the client application can process the response appropriately. Specifically if Include X-Mashery-Responder Header in Response, and Include X-Mashery-Message-ID Header in Response are selected on the end-point settings in the dashboard, these will be added to Access-Control-Expose-Headers list
  • Even in the case of error responses, CORS specific headers are added in the response. This allows the client application to read and process the right error message   
  • Even if pre-flight request fails, it is returned with a 200 code but with the right error message  This will ensure that the client application can process and display the appropriate error message on the browser which facilitates better debugging.

Rate limit consumption via debug headers

We launched a useful little feature recently that allows monitoring of rate limit consumption.  This is a feature that needs to be be toggled on via a UI option to be available. When this feature is toggled on, all responses returned from that end-point will automatically include a bunch of Mashery generated headers that display information such as allotted QPS, allotted quota, current QPS, current quota as well as time duration left to quota reset. Useful for e.g. if a developer runs out of allotted daily quota and needs to know when the next call can be made against that end-point.

For e.g. with this option enabled, if a developer is making a call using a package key for a package plan that has method level limits specified, below are some headers that would be included into the response by Mashery

Here’s the screenshot of where you would enable this option via Endpoint -> Properties page ( Include rate limit data in response headers)



New Feature: Enhanced Cache Reporting and API Distribution Network

We are pleased to announce the general availability of enhanced Cache Reporting, the latest addition to the Reporting & Analytics provided within the API administration dashboard.

API administrators can now drill-down deep into their API programs and visualize the percentage of API responses that are being delivered from the Mashery cache feature or from their backend infrastructures.

Now, API administrators can proactively identify opportunities to unload non-transactional API traffic from consuming their backend capacity and instead leverage TIBCO Mashery’s globally distributed API distribution network. Customers delivering static data or rich-media content like videos, music, articles, etc…, who have optimally configured their use of the Mashery cache feature would see improvements to their API response times and, for any mobile-deployed products, a seemingly “faster” end-user application experience as data is transferred in less time.

The new reports provide a "birds-eye view" across Packages, Plans, API’s, Endpoints, Methods and developers. Each drill-down perspective contains a pair of reports for an overall assessment and a time-trended assessment of how the Mashery cache feature is being utilized. A key benefit of this deep visibility into cache utilization is the potential for our customers to influence internal discussions on how to improve the backend infrastructure with respect to the indicated traffic trends for APIs, endpoints, and methods.

When filtered, the report data tables transition smoothly to become an interactive data visualization for further inspection and insight generation.

The new reports are available for all customers who have the cache feature enabled and can be found within the Reports tab of the Administration dashboard at the following location: For a selected Package or Service > System Status > Cache.

Please see the screenshots below depicting this exciting new feature in action!



[ Page 1 of 9 | Next ]