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
Questions
Should you have any questions about getting up and running, please contact support@mashery.com.
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:
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!
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) |
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) |
