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 = changemenowWhen 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!

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

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

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

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