Getting Started

Click a link in the table below to view the corresponding section:

Documentation
Questions
Examples
The Process
What We Need from You and Why
What We Need for the Mashery PRO Solution

 

Documentation

You can find documentation about administering your Mashery-powered portal at http://mashery.mashery.com/docs/Provider

Back to top

Questions

Should you have any questions about getting up and running, please contact support@mashery.com.

Back to top

Examples

For a good, broad sample of the different ways our customers have put together their developer portals and have built-out their documentation, you can visit the following sites:

Back to top

The Process

The process will start with a Mashery implementation expert contacting you.

Once we have provisioned your Mashery-powered portal you can immediately begin entering your content and configuring the portal for the functionality you require. In parallel with this, Mashery will begin creating the stylesheet that will make the portal conform to your branding. Any content you have entered will not be affected by the styling of the portal. We will be asking you to supply us with an example page(s) for us to base the styling on (see below).

Your Mashery-powered developer portal will be provisioned on Mashery servers. The URL on our end will be
"your company name".mashery.com. Later in the process, we will ask you to CNAME developer."your company name".com to this URL.

The administrator login/pwd for your new Mashery-powered developer portal will be "your company name"admin/changemenow e.g. if your comapny name is "dacompany", then you would log on using
username = dacompanyadmin
password = changemenow
When you log on for the first time, be sure to change your password to one known only by you.

Once logged on, you should now consult the documentation to understand how to configure the portal and begin the process of entering content. Please don't pull your hair out trying to get things looking perfect - we'll work with you to make sure the content is ultimately displayed to your satisfaction. Don't hesitate to ask us questions. We've been through the process many times and will be able to save you time if you find something is not intuitive. Your questions also enable us to improve our service so we want to hear them!

Back to top

What We Need from You and Why

As we go through the implementation process together, we will be asking you for the following pieces of information

What A link to the page or pages on which you want us to base the developer site skin
Why Mashery needs to "skin" your Mashery-powered developer portal to your look and feel
Example developer.ean.com developer.espn.com
Timing You probably won't want your developer portal to be public until this is in place
Notes Usually made to look and feel like your home page theme




What A CNAME record in your DNS pointing developer."your company name".com (or whatever other URL you want to direct people to the developer site) to "your company name".mashery.com.
Why So your Mashery-powered developer portal will look like it is on your servers. We recommend the URL developer."your company name".com but it's up to you what you use as long as you CNAME it to us correctly
Example developer.shopping.com, developer.trulia.com
Timing Developer portal cannot be accessed via your URL until this happens
Notes (none)




What The API terms of service that you want your developers to accept before they are granted access to your API
Why Legal protection of usage of your API
Example http://developer.trulia.com/page/read/Tou
Timing You probably want this in place before you allow people to access your API
Notes (none)




What A noreply@"your company name".com e-mail address added to your mail server if it does not already exist
Why When a new developer registers for access to your API via the Mashery-powered developer portal, the credentials are dispatched to them via a confirmation email. The confirmation email, by default, comes from noreply@"your company name".com. This email address must be in your mail server to ensure that confirmation e-mails are sent successfully
Example (none)
Timing Needs to be in place before credentials are provisioned via a registration email
Notes (none)




What Business contact numbers/e-mail, including roles/responsibilities for this project
Technical contact numbers/e-mail, including roles/responsibilities for this project
Why So we know who to interact with at your end
Example The Mashery Solution includes constant monitoring of the availability of your API. If and when we detect an outage we need to know who on your end should be alerted
Timing As soon as possible as we go down the path to implementation
Notes (none)

 

Back to top

What We Need for the Mashery Solution

What Key provisioning customization
Why The type of credentials used to access your API and the mechanism used to hand out those credentials need to be agreed upon and set up. The are many possibilities here. See the Solution Overview for more details
Example See the Solution Overview for more details
Timing Cannot provision keys until this is decided
Notes Lite customers get blind copied on the default credentials provisioned by the Mashery-powered developer portal




What A list of existing API users, including each associated API key and any relevant user info
Why If you have developers using an existing API, we will import that information into your Mashery-powered portal. This means there will be no interruption of service and will also enable you to see all of your developers going forward in your Mashery administrative dashboard.
Example Many possibilities depending on the the key provisioning mechanism chosen
Timing Most likely before you go live with your Mashery-powered developer portal
Notes (none)




What A sample, valid API call that we can use to test the proxy, and the expected response from that call
Why For us to test that the proxy is working correctly before going live to the outside world
Example Particular to your API
Timing Cannot go live without this
Notes (none)




What Your private API URL that we will point our proxy to in order to direct valid calls to your API
Why Our proxy has to know where to re-direct developer calls
Example CNAME addition (similar to re-direct of the portal URL - see above) i.e. proxy is in middle so must know where calls are coming from and where they are going
Timing Proxy setup only. Developer portal can proceed without this
Notes (none)




What A CNAME record in your DNS pointing api."your company name".com (or whatever other URL you want to have people program their apps to call) to "your company name".api.mashery.com.
Why So our proxy can intercept calls to your API and allow us to do our Mashery magic! Related to the item above this one
Example Particular to your setup
Timing Cannot go live without this
Notes (notes)




What Default API query rate per second (if you want this enforced)
Why Each API has an associated default query rate per second
Example 5000 calls in total per second (i.e. across all users of the API)
Timing Default is 5000. Can be changed at any time through the administrative dashboard
Notes (none)

 

Back to top