Update reference-spec.md

Add testing/variables articles

CODE_OF_CONDUCT.md

@@ -0,0 +1,46 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at robbins@stoplight.io. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

TOC.md

@@ -1,4 +1,12 @@
-* Platform
+---
+title: Stoplight Help
+description: 'Bout time.
+theme: ./theme.css
+javascript: ./global.js
+nav: [['Platform'], [], ['Editor']]
+---
+
+* ![Platform](./logo.png "Platform")
   * Getting Started
     * [What is Stoplight?](./articles/getting-started/what-is-stoplight.md)
     * Getting started for new users
@@ -129,9 +137,6 @@
     * Pages
     * Subpages
     * Blocks
-      * Overview
-      * Text
-      * ...
     * Referencing / Embedding Other Data Sources
       * Overview
       * OpenAPI Specifications

articles/accounts/changing-your-email.md

@@ -0,0 +1,13 @@
+# Change your Email Address
+
+![](/assets/gifs/account-info.gif)
+
+## What 
+Changing your email address is easy as pie 
+
+## How 
+1. Click on your **username** in the top right 
+2. Click on the **Account** button.
+3. In the **Basic Info** section, replace the email listed with one you would like to change to 
+4. Click **Save** and you’re all done 
+

articles/accounts/changing-your-username.md

@@ -0,0 +1,12 @@
+# Change Your Username 
+
+![](../../assets/gifs/account-info.gif)
+
+## What 
+You can change your username at any time 
+
+## How 
+1. Click on your current **username** in the top right 
+2. Click on **Account** 
+3. Under **Basic Info** input a new username 
+4. Click **Save** 

articles/accounts/deactivate-account.md

@@ -0,0 +1,8 @@
+# Deactivate Your Stoplight Account 
+
+## What
+* We're sorry to see you leave. Come back soon! 
+
+## How
+1. Email [support@stoplight.io](mailto:support@stoplight.io) with your deactivation request 
+2. We'll take care of the rest 

articles/accounts/edit-profile.md

@@ -0,0 +1,22 @@
+# Edit your Profile 
+
+![](../../assets/gifs/account-info.gif)
+
+## What 
+* In your profile you can edit things like: 
+    * Basic Info 
+        * Username 
+        * Name
+        * Email
+    * Upload a profile image 
+    * Change Password 
+ 
+##  How
+1. Select your **Username** in the top right corner
+2. Click **Account**
+3. Make your edits in **Basic Info** then click **Save** 
+    * You can also click **Reset** if you would like to start from scratch 
+4. Upload a profile image 
+5. Make your edits in Change Password then click **Change Password** 
+    * Password must be at least 6 characters 
+ 

articles/accounts/manage-password.md

@@ -0,0 +1,14 @@
+# Manage Your Password 
+
+![](../../assets/gifs/account-info.gif)
+
+## What 
+* If you’ve forgotten the password you use to sign in to Stoplight; you can easily reset it at any time
+
+## What
+1. At the login page select **Forgot Password?**
+2. Input your email in the space provided 
+3. Click **Send Email Link** 
+4. An email will be sent with a link to your email address
+5. Click on the link and you will be sent to an email reset page 
+6. Choose a new password and Voila 

articles/accounts/sign-in.md

@@ -0,0 +1,25 @@
+# Sign In To Stoplight 
+
+## What
+* There are two separate options for creating your snazzy new Stoplight account: 
+    * Login with GitHub 
+    * Create a new account 
+  
+## How
+
+### Login  with Github
+
+1. Click **Login with Github** 
+2. A window will popup asking you to authorize access to your Github account 
+3. Click **Authorize stoplightio**
+
+### To Create a New Account
+
+1. Click on **Join**
+2. Fill in your **Name** 
+3. Create a **Username** 
+4. Input the **Email** you want associated with this account 
+5. Create a **Password**
+    * Password must be more than 6 characters 
+6. Click **Join Stoplight**
+

articles/accounts/sign-out.md

@@ -0,0 +1,11 @@
+# Sign Out of Stoplight 
+
+![](../../assets/gifs/sign-out.gif)
+
+## What 
+* By default, Stoplight remains open. If you wish to sign out follow these quick and easy steps 
+
+## How
+1. Click on your **username** in the top right corner 
+2. In the dropdown menu select **Sign Out** 
+3. All set, come back soon! 

articles/desktop/overview.md

@@ -0,0 +1,33 @@
+# Web & Desktop App
+
+
+Stoplight has a desktop app! Download the appropriate version [here](https://stoplight.io/download) .
+
+
+## Web or Local?
+
+
+The main difference between the Stoplight desktop app and the web app is that the desktop app can store requests and test data offline. The desktop app can also connect with APIs that are behind firewalls or otherwise not available on the public internet (localhost as well).
+
+
+## Local Prism
+
+
+When you start the Stoplight desktop app, it will start an instance of Prism on http://localhost:4010. The desktop Prism instance is identical to the downloadable Prism binary run manually from your terminal. When you run local tests in the desktop app, it automatically calls a local Prism instance with the correct arguments and spec files.
+
+
+## Local Save
+
+
+* The Stoplight desktop app can read/write specification files on your local file system. This is perfect for generating specification outside of Stoplight (like from code), want to use version control systems like Git, or want to use your favorite IDE to work on a spec. 
+* This feature is **NOT** available in the web app 
+
+
+
+
+ the web app 
+
+
+<!--stackedit_data:
+eyJoaXN0b3J5IjpbMTU3NDc5MjY0XX0=
+-->

articles/editor/editor-configuration.md

@@ -0,0 +1,35 @@
+# Configuration with the `.stoplight.yml` File
+
+This document describes the usage of `.stoplight.yml`, the file that is used by the Stoplight editor to manage its configuration.
+
+It is placed in the root of your project and allows you to configure editor settings and environments that will apply to **all** users of the project. This allows you to share commonly-used settings between members of your team directly.
+
+You can make changes to the `.stoplight.yml` file by opening it:
+
+![](../../assets/images/editor-configuration.png)
+
+### Editor Configuration
+
+- **defaultFile**: The `defaultFile` setting allows you to control which file is displayed to read-only users when they navigate to the project. This can be useful to show them a particular markdown or hub on first load.
+
+### Environments
+
+![](../../assets/images/editor-configuration2.png)
+
+Environments make it easy to auto-populate variables (hostnames, ports, passwords, etc.) used by specifications and scenarios. Read more about them [here](../testing/variables-environment.md).
+
+The environments and variables defined in the `.stoplight.yml` are shared amongst all users, which makes this a good place to define common or shared variables, such as the url host for a particular API + environment. 
+
+There are three environments included with a new project:
+
+* __Default__ - The __Default__ environment is used by the Stoplight editor when first logging in and if no other environment has been selected. This is commonly used for variables needed for development and prototyping.
+* __Staging__ - The __Staging__ environment is automatically created for the storing of"staging" or "pre-production" variables and settings.
+* __Production__ - The __Production__ environment is automatically created for the storing of production variables and settings.
+
+These environments can be customized by editing the `environments` key of the `.stoplight.yml` file. To add a new environment, simply add a new key to the `environments` property, and set the value to an empty object or an object with default variables to share amongst your team.
+
+***
+
+**Related**
+
+* [Testing Environment Variables](../testing/variables-environment.md)

articles/editor/environments.md

@@ -0,0 +1,51 @@
+# Environments
+
+<!--(FIXME - SHOW CLICKING BETWEEN DIFFERENT ENVIRONMENTS)-->
+
+An environment is simply a container for data, represented as a list of key-value pairs (behind the scenes, this is a JSON object). Every Stoplight project has one or more environments associated with it. The data stored in an environment can be used in many places within the Stoplight editor.
+
+Environments, and their default data, are defined in the [Stoplight configuration file](./editor-configuration.md#environments).
+
+- __Do__ create an environment for each development environment associated with the project. For example, `development`, `staging`, and `production`.
+- __Don't__ create environments for individual users. Instead, use private variables (below) to customize existing environments.
+- __Do__ use environment default data to store shared information like hostnames, ports, passwords, etc.
+- __Don't__ use environments to store fixture/seed/temporary data.
+
+<!--(FIXME - SHOW SCREENSHOT OF THE ENVIRONMENTS WINDOW)-->
+
+For more information on environment variables and how they can be used during API testing, please
+see [here](../testing/variables-environment.md).
+
+## Private Variables
+
+Private Variables are _only_ stored locally on your system,
+and are never sent to Stoplight or the rest of your team. Private variables
+should be reserved for secrets specific to you, such as user-specific passwords,
+API keys, and other pieces of sensitive and/or individually specific data.
+
+Edit private variables by clicking on the environment button in the top right of the Stoplight editor.
+
+> Since private variables are only stored on your computer, make sure they are
+  backed up in a secure location.
+
+## Resolved Variables
+
+Resolved Variables shows a read-only view of the variables that are currently
+exposed to your editor. They are based on:
+
+* The currently selected (active) environment
+* The active environment's default variables, as defined in the stoplight configuration file
+* The active environment's private variables, as defined by you
+
+Private variables are merged over default variables that share the same name. This makes it easy
+for individual team members to customize and extend environments without affecting the rest of the team.
+
+For more information on updating and customizing environment variables, please
+see [here](./editor-configuration.md#environments).
+
+***
+
+**Results**
+
+* [Using Environment Variables in Testing](../testing/variables-environment.md)
+* [Configuration with the `.stoplight.yml` File](./editor-configuration.md#environments)

articles/editor/file-validation.md

@@ -0,0 +1,27 @@
+# File Validation
+
+![](../../assets/gifs/file-validation-OpenAPI-spec.gif)
+
+File validation is the process of checking a file's syntax and structure to make sure it meets specific requirements. Stoplight's validation ensures file edits are in the correct format. This is especially helpful while editing structured file formats (e.g. OpenAPI documents) so that any errors can be resolved quickly and efficiently.
+
+File validation is run after every file edit to make sure no errors were introduced. A notification will appear if validation errors were introduced so that they can be resolved before attempting to save. If a validation error is detected, an alert will appear with an explanation of the issue and where it occurred.
+
+![](../../assets/images/file-validation-error-overview.png)
+
+Validation failures come in two levels:
+
+* __Warnings__ - A warning is generated if the validation process found a non-critical issue that did not interrupt the processing of the document. As an example, inclusion of non-standard fields in an OpenAPI document will display as a warning.
+
+* __Errors__ - An error is generated if the validation process found a critical issue that prevented the processing of the document. As an example, not including the correct fields in an OpenAPI document will display as an error.
+
+Different types of file validations are used throughout the Stoplight platform. At a high level, file validations aim to identify the following two groups of errors:
+
+* __Syntax__ - Most files stored in Stoplight are either JSON or YAML format, so they must always adhere to the JSON/YAML formatting standards. If anything typed into the editor does not meet the format criteria, it will be rejected with a notification pointing to where the syntax error occurred. _Syntax errors will prevent the file from being saved until all errors are resolved._
+
+* __Correctness__ - Certain files stored within Stoplight must adhere to high-level specifications to ensure they are able to be read and processed correctly. The OAS/Swagger specification is one such standard. It is critical that every OAS document stored in Stoplight meet these standards. If an error is detected in any document, either an error or warning will be generated with a description of the issue.
+
+***
+
+**Related**
+
+* [OpenAPI Validation](../modeling/openapi-validation.md)

articles/editor/view-history-changes.md

@@ -0,0 +1 @@
+

articles/editor/visual-code-view.md

@@ -0,0 +1,7 @@
+# Visual & Code Views
+
+![](../../assets/gifs/editor-visual-toggle.gif)
+
+Stoplight NEXT now has a toggle for switching between our visual editor and our code editor. If you prefer working with code, need to paste in some OAS, or just want to make changes manually, switch over to the code editor.  This new feature is included in all our editors including Hubs, Modeling, and Scenarios. 
+
+<callout> New Feature! Any changes made in the code editor will automatically populate the visual editor. </>

articles/editor/working-with-files.md

@@ -1 +1,24 @@
+# Working with Files 
 
+![](../../assets/gifs/fileexplorer.gif)
+
+As part of our effort to make the Stoplight platform more flexible and familiar we added a file explorer to Stoplight NEXT. You can now see all your files sorted by filetype in one central location within Projects. File types include: 
+
+* .hub (Hub/Docs Files)
+* .oas2 (Modeling Files)
+* .scenarios (Scenario/Testing FIles)
+* .prism (Prism Files) 
+* .md (Markdown Files) 
+
+## File Explorer 
+
+Within the file explorer you can:
+ 
+* **Search for Files**
+	* Search for files using the **search bar** at the top of the file explorer 
+* **Create Files** 
+	* Hover to the right of the filetype headers and click the **+** to create a new file 
+* **Export Files** 
+	* Hover to the right of a file and click the **arrow** to export files into OAS
+* **Delete Files** 
+	* Hover to the right of a file and click the **trash can** to delete files

articles/getting-started/faq.md

@@ -0,0 +1,51 @@
+# FAQs
+
+## General
+
+**Is Stoplight v2 being discontinued?**
+
+Stoplight Classic (v2) will persist, but new feature development will only occur on Stoplight v3. Major bugs in Stoplight v2 will continue to be addressed. We encourage all our Stoplight Classic (v2) users to move onto our new platform. Read more about migrating from v2 to v3 [here](LINK).
+
+**Can I save my files locally?**
+
+Yes, but only on the desktop app. Click [here](LINK) to learn more about the Stoplight desktop app.
+
+**Is there a way to manage multiple APIs in a single Project**
+
+Yes. In Stoplight v3 you can manage unlimited APIs in a single Project. To learn more click [here](LINK).
+
+**What are the differences between Stoplight Classic (v2) and Stoplight v3?**
+
+Stoplight Classic is our original platform. Stoplight v3 is the next generation of platform, including all the features and tools from Stoplight Classic and much more. To learn more, click [here](LINK).
+
+**Can I transfer Account ownership?**
+
+Yes, you can [transfer ownership of an Organization](https://next.stoplight.io/stoplight/stoplight-next-docs/blob/master/Stoplight%20Platform.hub.yml?edit=%23%2Fpages%2F~1%2Fdata%2Fchildren%2F2%2Fdata%2Fchildren%2F5) or [make changes to your personal account](https://next.stoplight.io/stoplight/stoplight-next-docs/blob/master/Stoplight%20Platform.hub.yml?edit=%23%2Fpages%2F~1%2Fdata%2Fchildren%2F0%2Fdata%2Fchildren%2F1)
+
+**Is there a way to edit my OpenAPI (Swagger) directly?**
+
+Yes. In Stoplight v3 you can switch between the GUI editor and the source code via a TAB in the editor.For more information click [here](LINK).
+
+**Does Stoplight offer monitoring solutions?**
+
+Not at the moment, however, scheduling scenarios + alerting (monitoring) is on our roadmap.
+
+**Does Stoplight support SSO?**
+
+Yes. The business and enterprise plans support SSO. For more information, click [here](LINK).
+
+**I am looking for a secure solution for hosting my API and restricting access, what do you recommend for hosting?**
+
+Stoplight offers an on-premise installation option that will meet most security needs. For more information, click [here](LINK).
+
+**Does Stoplight support OpenAPI 3?**
+
+Currently we support OpenAPI 2 (Swagger 2). OpenAPI 3 support on our short term roadmap.
+
+**My sign-up token has expired, how do I generate a new one?**
+
+On the login page, go to forgot password and reset it using your email. This will renew your token.
+
+**Can I remove the Stoplight branding from my API docs?**
+
+Yes! In Stoplight v3 all paid users have access to the underlying CSS, and can customize it to remove or change any of the visual elements on the page. Click [here](LINK) for more information on themeing.

articles/getting-started/new-user-introduction.md

@@ -0,0 +1,24 @@
+# Welcome to Stoplight NEXT! 
+
+![](../../assets/images/stoplight-crew.jpg)
+
+Now that you have the basics on what the [Stoplight NEXT Platform](../what-is-stoplight.md) is, we can go over how to get started. 
+
+First things first, are you using it for Personal Projects or as part of an Organization?
+
+## Personal Projects 
+1. Create an Account (link)
+2. Create a Project (link) 
+
+## Organization 
+1. Create an Account (link)
+2. Create an Organization (link) 
+3. Invite Members (link) 
+4. Accept an Organization Invite 
+5. Create a Project (link) 
+
+## Web App or Download 
+* You can log in to the Web App at [next.stoplight.io](http://next.stoplight.io) or 
+* You can download the platform here (link) 
+
+If you have any questions you can reach out to us through Intercom or email us at [support@stoplight.io](support@stoplight.io) otherwise... **Full Steam Ahead!**

articles/getting-started/organization-owner-introduction.md

@@ -0,0 +1,37 @@
+# Organization Owner Introduction 
+
+![](/assets/gifs/org-create.gif)
+
+## Welcome to Stoplight NEXT!
+
+If you are trying to create a new Organization then you are in the right place. Stoplight NEXT was designed with large scale collaboration and governance as a central principle. The following guide will take you through the process of creating and populating an Organization, and offer an overview of the governance tools within Stoplight NEXT. 
+
+## Organization 
+Organizations function as a shared space for you and your co-workers. Members of an Organization have access to a centralized Activity Feed, Project Repository, and an Issues (link) discussion tool. Organization Owners can also assign varying levels of Permissions to other members of the Organization.  
+ 
+* Create an Organization (link)
+* Invite People to Organization (link) 
+* Remove People from your Organization (link) 
+* Member Roles and Permissions (link)
+* Customize your Organization (link) 
+* Transfer Primary Ownership (link) 
+* Delete an Organization (link)
+
+## Teams 
+If you are managing a large Organization with multiple teams you can use Teams to group Organization members together. 
+
+* Create a Team (link)
+* Add People to a Team (link)
+* Remove People from a Team (link)
+* Member Roles and Permissions (link) 
+* Customize a Team (link) 
+* Transfer Primary Ownership (link) 
+* Delete a Team (link) 
+
+## Projects 
+Projects are the workspaces you can create for your Organization. 
+
+* Creating a Project (link) 
+* Invite People & Teams to a Project (link)
+* Change a Project Member’s Role (link) 
+* Make Your Project Private/Public (link) 

articles/getting-started/what-is-stoplight.md

@@ -1 +1,36 @@
-# What is Stoplight?
+# The Stoplight Platform 
+The Stoplight platform provides a suite of products that cover the entire pre-production API lifecycle. Here is an overview of the platform:
+
+![](../../assets/images/platform-overview.png) 
+
+Stoplight promotes a design-first philosophy. Developing good design-first practices at your organization will minimize future cost, speed up your time to market, and lead to more consistent, higher quality APIs.
+
+## API Modeling & Design
+At Stoplight, everything starts with design. Our visual designer makes it easy for anybody in your organization to model and document APIs, no matter the complexity.
+
+Whether you have an existing OpenAPI (Swagger) or are creating a new API design from scratch, we've got you covered.
+
+![](../../assets/images/modeling-editor.png)
+
+## API Testing
+Once you have your API design / documentation, how do you make sure that it remains accurate over time? Stoplight contract testing, powered by Prism, makes it trivial to create a full suite of tests that apply your API documentation (your contract) to your API. Run these tests from the Stoplight app, and standalone in your CI process or elsewhere.
+
+![](../../assets/images/scenarios-editor.png)
+
+## Hosted Documentation 
+
+You have your API designed and documented privately in the Stoplight app, and now you want to share all or part of it with 3rd parties (developers, customers, clients, etc). Stoplight makes it easy to publish your documentation to the world, with a single click.
+
+
+![](../../assets/images/HubsPreview.png)
+
+## Mock Server
+Stoplight provides a complete mock server for every API described in the app. Run tests against this mock server, build consumers (like mobile apps, SDKS, etc) before the final API is ready, and more.
+
+Spinning up your own mock server is as simple as:
+
+# install prism on macOS
+curl https://raw.githubusercontent.com/stoplightio/prism/master/install.sh | sh
+
+# run a fake petstore api on http://localhost:4010
+prism run --mock --list --spec http://petstore.swagger.io/v2/swagger.json

articles/help.md

@@ -0,0 +1,5 @@
+# Contact Us
+
+Having trouble finding what you are looking for? Need some additional support? We’ve got you covered. Shoot us a message and we will get back to you as soon as possible. 
+
+Email us at [support@stoplight.io](mailto:support@stoplight.io) or message us in Intercom. 

articles/hubs/blocks.md

@@ -0,0 +1,33 @@
+# Blocks 
+
+![](../../assets/gifs/Blocks.gif)
+
+## What
+Blocks are the micro-level building blocks of Hubs. They house multiple forms of content and allow for simple restructuring and modification. 
+
+<callout> Hovering over a Block reveals additional tooling including: Preview, Cut, Copy, Reference External Source, and Delete </>
+
+## Block Types 
+### Text Block 
+* A markup editor for adding any textual elements to your Hub 
+### JSON Schema
+* A block for describing the structure of a JSON object 
+### HTTP Request Maker 
+* A block for making HTTP requests 
+### Code
+* A block for inserting code snippets 
+### Image 
+* A block for inserting images
+### Tabs 
+* An upper level block for organizing text within tabs 
+### Callout 
+* A text block with color for emphasis 
+### Hero 
+* A large stylized text block with additional functionality typically found on landing pages 
+### Bar List 
+* A navigational block composed of bars with buttons 
+### Card List 
+* A navigational block composed of cards with text, buttons, and optional images
+### HTML 
+* Include arbitrary HTML in your hubs when the other base block types don't quite do the trick
+

articles/hubs/hubs-introduction.md

@@ -0,0 +1 @@
+

articles/hubs/managing-headers-footers.md

@@ -0,0 +1,32 @@
+
+# Managing Headers and Footers 
+
+![](../../assets/gifs/headers-footers.gif)
+
+## What 
+You can customize the headers and footers of your Hub to add additional navigation to your documentation. You can modify a header and footer: 
+
+- **Location on Page**: Drag and drop along the header and footer to the desired location 
+- **Type**: Page, External Link, Image 
+- **Title**: What text is displayed on page
+- **Path to Page**: Specify path to page  
+- **Image URL**: If you want to display an image instead of text for the link input image URL 
+
+
+## How 
+
+### Modify Existing Header and Footer
+
+1. Select the Hub you wish to modify
+2. Click on the **Editing toggle** 
+3. By default, there will already be three headers (Home, API Reference, Help) and a footer (Home) 
+    1. Hover over one of the headers or footers and click on the **gear icon** to modify 
+    2. Drag the header or footer to another location to change its location 
+
+
+### Create New Header and Footer 
+
+1. Select the Hub you wish to modify 
+2. Click on the **Editing toggle**
+3. Hover over the left or right edge of the header or footer 
+    1. Click on the **+** button 

articles/hubs/pages.md

@@ -0,0 +1,30 @@
+# Pages 
+
+![](../../assets/gifs/create-pages.gif)
+
+## What
+Pages are the macro level building blocks of a Hub. They function as the canvas on which all other Hubs objects reside. They are commonly used as a way to separate information based on the broadest topics. 
+
+### Hubs Architecture from Top Down 
+
+- Pages 
+    - Subpages 
+        - Blocks
+    - Header and Footer 
+    - Blocks 
+
+## How 
+
+### Create a New Page
+
+1. Select the Hub you wish to modify 
+2. Click on **Toggle Editor** 
+3. Select **+** Page in the editor toolbar 
+    1. Input a **Page Title** 
+    2. Input a **Page Route** (optional) 
+    3. **Power the Page** with an External Data Source (optional) 
+
+<callout> Did you know? After creating a new page; a header link will automatically be generated </> 
+
+<callout> To add content to a page you must add a subpage or a content block </>   
+

articles/hubs/publishing.md

@@ -0,0 +1 @@
+

articles/hubs/ref-other-sources-hubs.md

@@ -0,0 +1,29 @@
+# Reference Other Sources
+
+![](../../assets/gifs/ref-other-sources-hubs.gif)
+
+## What
+Hubs allows you to reference other sources to automatically populate your Hub with content. We call this “powering” a building block. You can power a building block with a file from the current file, a file from the current project, a file from another project, or a file from an external source. 
+
+### What Can I Power
+
+- Pages 
+- Subpages 
+- Text Blocks 
+
+## How
+
+### Power a Subpage 
+
+1. Select the Hub you wish to modify 
+2. Select (or create a new) **Subpage** 
+3. Click on the **gear icon** in the center of the editor toolbar (If new, this window automatically opens)  
+    1. Select **Power this Subpage with an External Data Source**
+    2. Select the data source from the drop-down menu 
+    3. Input the specific data source or select from the drop-down menu
+    4. Input an inner data source (optional)  
+4. Click **Confirm**  
+
+<!-- theme: info -->
+>Try it Out! Power a Subpage with an API Spec from the same project.
+

articles/hubs/routing.md

@@ -0,0 +1,37 @@
+
+# Routing 
+
+![](../../assets/gifs/routing-hubs.gif)
+
+## What 
+Stoplight’s Hubs features an easy to use routing system to make sure your docs have identifiable and friendly URL’s. The routing system allows customization of the following objects: 
+
+- Your Hub 
+- Pages within a Hub (link) 
+- Subpages within a Hub (link) 
+- Headers + Footers (link)
+- Links 
+
+<callout>Tips for Friendly URL’s 
+
+Friendly URLs are links that are easily readable, rememberable, and relevant to the content.
+Take a look at the URL for this page. Instead of something like https://help.stoplight.io/docs/fnIenof/123, it is https://help.stoplight.io/docs/hosted-documentation/create-friendly-urls, which is much nicer. </>
+
+## How 
+
+### Pages & Subpages 
+
+1. Select the Hub you wish to modify 
+2. Add a new page or subpage (link) 
+   a. Select a page title to auto-fill the Page Route or 
+   b. Input a custom page route 
+3. Select an existing page or subpage 
+4. Select the gear icon at the top of the Hub in the center of the page or subpage you wish to modify  
+   a. Input a new URL under Page Route  
+
+### Headers & Footers 
+
+1. Select the Hub you wish to modify 
+2. Add a new header or footer (link) or
+3. Hover over an existing header or footer and click the gear icon 
+    a. Input a Path to Page or image URL  

articles/hubs/subpages.md

@@ -0,0 +1,30 @@
+# Subpages 
+
+![](../../assets/gifs/create-subpages.gif)
+
+## What
+Subpages are the second tier macro building blocks of Hubs. They function as a canvas for blocks. They are commonly used to house content based on a specific topic.  Subpages can have more subpages nested underneath them, which gives you lots of flexibility to organize your Hub as you see fit. If a subpage has subpages nested inside of it, it will be displayed as a collapsible group in the left sidebar.
+
+### Hubs Architecture Top Down
+- Pages 
+    - Subpages 
+        - Blocks
+    - Header and Footer 
+    - Blocks  
+
+## How 
+
+### Create a New Subpage 
+
+1. Select the Hub you wish to modify 
+2. Click on **Toggle Editor** 
+3. Select **+ Subpage** in the editor toolbar
+    1. Input a **Subpage Name** 
+    2. Modify the **Subpage Route** (optional) 
+    3. Give the Subpage a **Sidebar Token** (optional) 
+    4. **Power the Subpage** with an External Data Source (optional) 
+
+<callout> Subpages populate the navigational sidebar of a page. </>
+
+<callout> Just like pages, subpages can have blocks. Any blocks added to a subpage will be displayed when a reader navigates to that subpage in your hub</>
+

articles/hubs/themes.md

@@ -0,0 +1 @@
+

articles/issues/attaching-issues-to-files.md

@@ -0,0 +1 @@
+

articles/issues/closing-issues.md

@@ -0,0 +1 @@
+

articles/issues/creating-issues.md

@@ -0,0 +1 @@
+

articles/issues/replying-to-issues.md

@@ -0,0 +1 @@
+

articles/modeling/api-models.md

@@ -0,0 +1,37 @@
+# API Models
+An API model is a blueprint that identifies the requirements and proposed solution for an API development project. A well crafted API model indicates you understand the problem you are trying to solve. The following steps can help you get started with creating an excellent API model.
+
+## Identify Needs  
+During interactive sessions with stakeholders, outline all the requirements you want your API to meet . Some important questions to ask: 
+- What goal(s) do we want to achieve with the API?
+- Who are the principal users that will consume or interact with the API?
+- What activities will the users execute?
+- How can we group the activities into steps?
+- What are the API methods that are required for these steps? (Place the methods into common resource groups.)
+- What resources will the API expose? 
+- What permissions will we need? 
+This process may need to be repeated until the API development team is sure that all requirements are covered.
+
+## Build a Common Vocabulary 
+Vocabulary is used in your API artifacts such as your data fields, resource names, identifiers, and documentation. Creating a standard vocabulary helps you:
+- Communicate well with different audiences. 
+- Establish a standard or style guide  that can be adopted by members of the API development team.
+- Easily update your documentation.
+
+## Identify Resource Relationships 
+If your resources contain references to other resources or contain child resources, it is important to understand and define the types of relationships between resources because this will help you to show the link between the resources to the API user making the API more readable. Relationships can be:
+- **Dependent**: the resource cannot exist without a parent resource.
+- **Independent**: the resource can stand on its own and can reference another resource but does not need another resource to exist or function.
+- **Associative**: the resources are independent but the relationship includes or needs further properties to describe it.
+
+## Create a Test Plan
+Ensuring that your API meets predefined criteria requires testing. Design test plans early. Feasible tests you can execute include:
+- **Functional Testing**:  Test the API calls to ensure that it delivers or behaves as expected.  For example, you can test to see that the API delivers the expected data based on your model.
+- **Mocking** (service simulation): Mocking allows you to execute tests on an API deployment without calling it through a defined API key.  Effective API tools will allow you to test your API before implementation.
+- **Load Testing**: How will your API perform when deployed on a production server? A load test is one way to simulate the effect of traffic on your servers and observe the performance of your API when it is available to users. Doing a load test will help you understand your API threshold and if the users exceed the threshold.
+
+## Additional Notes
+- Create tests that match your use case. 
+- Discuss security issues during your modelling meetings with your team.
+- Ensure the test case is executed to see if the security issues are addressed before deployment. Click here to know more about security schemes and how to secure your API using best practices. 
+

articles/modeling/api-operations.md

@@ -0,0 +1,90 @@
+# API Operations
+## Introduction
+API operations describe the way you define how an API is exposed to a user. Properly defined operations are fundamental to the API development life cycle and the outcome is a final product that is easy to understand and use. Creating a properly designed RESTful API requires research, analysis, and planning. It is the API developer’s responsibility to ensure that the API design, resources, and connected operations are easy to understand by consumers. The following characteristics are true of well-designed APIs: 
+
+- Comprehensive, yet succinct 
+- Understandable and easy to use
+- Supports delta (incremental) development
+- Expedites and simplifies the API documentation process 
+
+## Key Terms
+- A **resource** is an entity or object that has data linked to it, relationships to other objects or entities, and a set of methods that operate on it to access, use, or manipulate the associated data. When resources are grouped together, it is called a collection. 
+- A **Uniform Resource Locator (URL)** is used to indicate and identify the location of an API resource and perform some actions to it. Note that the base URL is the constant part of this location. 
+- **GET** method requests data from a resource and the body of the response message holds the information requested.  
+- **PUT** method requests the server to update the resource or create it (if it does not exist) and the body of the request message indicates the resource to be updated or created.
+- **PATCH** method performs a partial update on a resource and the body of the request message indicates the change to be applied.  This can occasionally be more efficient than PUT because the client forwards changes required and not the entire details about the resource. 
+- **POST** creates a new resource and the body of the request message indicates the details of the new resource to be created. This method can be used to activate operations that will not create a resource.
+- **DELETE** method requests that the specified resource be removed.
+
+## Best Practices
+
+### Resource URL should be based on nouns and not verbs
+
+For example, to retrieve pet details for a pet store which has different kinds of pets:
+
+- /pets (Good) 
+- /getAllPets (Bad)
+
+<!-- theme: info -->
+> A good resource URL contains resources (nouns) and not actions or verbs. Ensure that the resource is in the plural form at the API endpoint.
+
+### Use HTTP methods to operate on resources
+
+To add, delete, or update information, use the HTTP methods GET, POST, DELETE, PUT, and PATCH (also known as verbs). For example:
+
+- GET /pets (returns the list of all pets)
+- GET /pets/5 (returns details of pet 5)
+
+<!-- theme: info -->
+> A successful GET method normally returns a HTTP status code of 200 (OK) and 404 (Not found) if the resource cannot be located.
+
+| GET                                   | PUT/PATCH                                     | POST                                | DELETE                                      | Resource               |
+|---------------------------------------|-----------------------------------------------|-------------------------------------|---------------------------------------------|------------------------|
+| Return list of all pets               | Update all pets                               | Add a new pet                       | Remove all pets                             | path/pets              |
+| Return details of treatment for pet 5 | Update all treatment for pet 5                | Add new treatment details for pet 5 | Remove all treatments associated with pet 5 | path/pets/5/treatments |
+| Returns details for pet 5             | Updates details for pet 5 assuming it exists  | Error (Not permitted)               | Deletes pet 5 details                       | path/pets/5            |
+
+### Make use of a Query String (?) for complex parameter optional parameters
+When you need to add more complexity and dynamics to the request, add parameters to the query string. For example:
+
+- GET /pets?type=feline&age=5 (Good)
+- getFelinePets (Bad)
+
+### Utilize HTTP Status Codes 
+A user should know the status of request made through an API. This might include failed, passed, or invalid responses. The table below summarizes the codes.
+
+| 2xx Success                                                             | 3xx Redirect          | 4xx Client Error | 5xx Server Error          |
+|-------------------------------------------------------------------------|-----------------------|------------------|---------------------------|
+| 200 Ok (Success for GET, PUT, or POST)                                  | 301 Moved Permanently | 400 Bad Request  | 550 Internal Server Error |
+| 201 Created                                                             | 304 Not Modified      | 401 Unauthorized |                           |
+| 204 No Content (Request successfully processed but returns not content) |                       | 403 Forbidden    |                           |
+|                                                                         |                       | 404 Not Found    |                           |
+
+- Be wary of using too many status codes and confusing the API user.
+- It is good to provide an additional description of the status code in the body of the HTTP Response. For example:
+    - Request: method GET /pets?type=feline
+    - Response: 
+```   
+   //This is an invalid request.
+    {
+    "message": "Invalid Pet Type please enter a valid pet category",
+    }
+```
+### Executing search, sort, filter and pagination operations 
+- When you need to perform these actions, you can append the query parameters to the GET method and the API endpoint. For example, to carry out a **search** operation for a particular pet:
+    - GET /pets?search=Blaze (This will search for a pet named Blaze)
+- **Pagination** helps you to manage the amount of resources you return and it is advisable to use the parameters offset and limit as shown in the example below:
+    - GET /pets?offset=10&limit=20 (Return pets between 10 to 20)
+- To **sort** the list of resources we can use multiple sort parameters in the query string. For example:
+     - GET /pets?sort=age_desc (Would sort the age in descending order.)
+- For **filtering** we can use one or more parameters in the query string. For example: 
+    - GET /pets?type=canine&age=7 
+
+<!-- theme: info -->
+>If too many query parameters are used in GET methods and the URL becomes too long, the server may return a ‘414 URL too long’ HTTP status. Parameters might be passed to the request body of a POST request as a solution to this challenge.
+
+### Versioning 
+It is good practice to version an API to describe the available features and resources it exposes. When this is properly done, the application consuming the API can submit explicit requests to a specific version of a feature or resource. For example, you can specify the version of the resource by means of a parameter within the query string affixed to the HTTP request: http://api.yourdomain.com/v2/pets/10/
+
+    
+

articles/modeling/build-api-library.md

@@ -0,0 +1 @@
+

articles/modeling/crud-builder.md

@@ -0,0 +1 @@
+

articles/modeling/duplication-refs.md

@@ -0,0 +1,129 @@
+# Preventing Duplications and Simplifying OAS Files 
+
+## What 
+- API resources often have or share similar features 
+- Duplicating features increase the size and complexity of your API
+- Reusable definitions make it easier to read, understand, and update your OAS files
+- Similar features can be created as reusable definitions and utilized with references
+- These definitions can be hosted on the same server as your OAS file or on a different server 
+- You can reference a definition hosted at any location or server 
+- Apart from defining reusable definitions, you can also define reusable responses and parameters. You can store your reusable definitions, responses, and parameters in a common library. 
+
+<!-- theme: info --> 
+>Key Terms: A definition is a named schema object. A reference is a path to a declaration within an OAS file.
+
+## How to Reference a Definition 
+To invoke a reference to a definition, use the **$ref** keyword. For example:
+```
+#/definitions/Pets ($ref: 'reference to definition')
+```
+
+## URL, Remote, and Local References 
+
+### General Syntax for URL Reference
+- Reference a complete document or resource located on a different server: 
+```
+$ref: 'http://url_resource_path'
+```
+- Reference a particular section of a resource stored on a different server: 
+```
+$ref: 'http://url_resource_path/document_name.json#section'
+```
+
+### General Syntax for Remote Reference
+- Reference a complete document or resource located on the same server and location: 
+```
+$ref:'document_name.json'
+```
+- Reference a particular section of a resource stored on a different server: 
+```
+$ref: 'document_name.json#section'
+```
+### General Syntax for Local Reference
+- Reference a resource found in the root of the current document and the definitions:
+```
+$ref: '#/definitions/section'
+```
+
+## Best Practices 
+- Only use $ref in locations specifed by the OpenAPI Specification 
+- Always enclose the value of your local reference in quotes (when using YAML syntax) to ensure it is not treated as a comment. For example:
+
+Good
+```
+"#/definitions/todo-partial"
+```
+Bad 
+```
+#/definitions/todo-partial
+```
+
+## Examples 
+- Assuming you have the following schema object named **Todo Partial** and you want to use it inside another definition: 
+
+```
+{
+  "title": "Todo Partial",
+  "type": "object",
+  "properties": {
+    "name": {
+      "type": "string" 
+    },
+    "completed": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "name",
+    "completed"
+  ]
+}
+```
+- To refer to that object, you need to add $ref with the corresponding path to your response: 
+
+```
+{
+  "title": "Todo Full",
+  "allOf": [
+    {
+      "$ref": "#/definitions/todo-partial" (Reference)
+    },
+    {
+      "type": "object",
+      "properties": {
+        "id": {
+          "type": "integer",
+          "minimum": 0,
+          "maximum": 1000000
+        },
+        "completed_at": {
+          "type": [
+            "string",
+            "null"
+          ],
+          "format": "date-time"
+        },
+        "created_at": {
+          "type": "string",
+          "format": "date-time"
+        },
+        "updated_at": {
+          "type": "string",
+          "format": "date-time"
+        },
+        "user": {
+          "$ref: "https://exporter.stoplight.io/4568/master/common.oas2.yml#/definitions/user" (Reference)
+        }
+      },
+      "required": [
+        "id",
+        "user"
+      ]
+    }
+  ]
+}
+    
+

articles/modeling/generating-schemas.md

@@ -0,0 +1,61 @@
+# Generating Schema 
+
+## What 
+- A schema is metadata that defines the structure, properties, and relationships between data. It also defines the rules that must be adhered to and is usually in the form of a document. 
+- A structured approach is always recommended for handling and manipulating data. 
+- The "$ref" keyword is used to reference a schema. 
+
+## Why 
+- A schema definition makes the process of handling data more structured.
+- The process of validation and handling user input errors can be imprioved through the use of schemas. 
+- Schemas encourage the 'single source of truth' (single place to update a definition) concept which, among other things, makes it easier to create and maintain endpoints. 
+
+## Best Practices 
+- It is advisable to always use a schema when you define and implement your API.
+- Use schemas to rapidly extract titles, descriptions, and samples for easy API documentation. 
+
+## JSON Schema 
+- JSON (Javascript Object Notation) is a popular, human readable data format that is easy to parse at the server or client side. 
+- JSON Schema is a standard that contains information about the properties of a JSON object that can be used by an API. It also helps validate the structure of JSON data. 
+    -The properties include: name, title, type etc. 
+- JSON Schema Specification is divided into three parts: 
+  - **JSON Schema Core**: describes the basic foundation of JSON Schema
+  - **JSON Schema Validation**: describes methods that define validation constraints. It also describes a set of keywords that can be used to specify validations. 
+  - **JSON Hyper-Schema**: an extension of the JSON Schema Specification that defines hyperlink, images, and hypermedia-related keywords. 
+
+## Example 
+Assume you have an API that requires data provided in the format below: 
+
+```
+{
+  pets: [
+    {id:1 petName: "Blaze", petType: "Canine", age: 2},
+    {id: 2, petName: "Felicia", petType: "Feline", age: 1}
+    {id: 2, petName: "Bolt", petType: "Canine", age: 3}
+    
+  ]
+}
+```
+As seen above, each object in the pets array contains the following properties: id, petName, and petType. You can create a schema definition to validate the data and ensure it is in the expected format. The schema definition is outlined below: 
+
+```
+{
+  "type":"object",
+  "properties": {
+    "pets": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "properties": {
+          "id": {"type": "number"},
+          "petName": {"type": "string", "required": true},
+          "petType": {"type": "number", "required": true},
+          "age": {"type": "number"}
+        }
+      }
+    }
+  }
+}
+```
+### Related Articles 
+- [JSON Schema](http://json-schema.org/specification.html) 

articles/modeling/how-to-create-models.md

@@ -0,0 +1,85 @@
+# Models
+
+## What 
+A model contains common reusable information that can be referenced in your endpoint definitions or other models in your API design. The resources or endpoints in your API project might contain duplicate structures and response objects. Models reduce this duplication by helping you extract and define common resources making your project easier to maintain. 
+
+## Best Practices 
+
+### Avoid Cluttered APIs
+When you have several endpoints with the same structure, objects, and properties, your API design is untidy. Ensure that you extract reusable artifacts and build them as pragmatic models referenced by other resources within your API project. 
+
+### Use a Design First Approach
+A design first approach helps create neat and consistent models. It will take longer, but it ensures you built an effective API that is easy to understand and maintain. 
+
+## How to Create Models using the Stoplight Modeling Editor
+1. Create a new API project (link on how to create a new  project goes here)
+2. For this example we will be referring to endpoints created for a fictional Pet Store as listed below
+- GET  /pets (return all pets)
+- GET /pets{petid}  (return pet with  a specified id)
+- POST / pets  (enter pet information)
+- PUT  /pets{petid}  (update pet with a specified id)
+- DELETE /pets{petid} (delete pet with a specified id)
+3. The  GET  /pets method has an array of objects in the Response body with the following properties:
+
+```
+{ 
+    id, (string),
+    name, (string),
+    date _created (string, date format),
+    date_updated (string, date format),
+    approved (Boolean),
+    approved_by (string)
+}
+```
+
+4. The  GET  /pets {petid} method duplicates the objects above  with the same properties:
+
+```
+{ 
+    id, (string),
+    name, (string),
+    date _created (string, date format),
+    date_updated (string, date format),
+    approved (Boolean),
+    approved_by (string)
+}
+```
+
+5. The PUT / pets{petid}  method duplicates the object above in the Response body with a slight difference in the Request body which has the objects and properties below:
+ 
+ ```
+{ 
+    id, string,
+    approved boolean,
+    approved_by string
+}
+```
+
+<!-- theme:  info  -->
+>Duplication of Objects: If you are required to make changes you would have to update this information in three or more endpoints. Creating a model solves this issue.
+
+6. To create a model click on the + sign next to the Model section.
+
+![](../../assets/images/create-model.png)
+
+7. Enter the details for the key, title, and description fields
+
+![](../../assets/images/editor-details.png)
+
+8. Click on the Editor Tab to create the object and specify the properties you want in the model (You can also copy and paste the JSON Schema from an endpoint into the Raw Schema section of the model)
+
+![](../../assets/images/create-object.png)
+
+![](../../assets/images/model-design.png)
+
+9. Click the Save button to save the changes you have made in the editor 
+10. Select the GET  /pets {petid} (or any endpoint)  and navigate to Responses→ Editor 
+11. To reference the model in your endpoint, click on the object and select $ref as the array item type. Select the model you created from the drop down list
+
+![](../../assets/images/ref-model.png)
+
+12. Select the Viewer section to see the changes you have made
+
+![](../../assets/images/viewer-ref-model.png)
+
+13. All changes made to the properties of the object in the model are now automatically updated in all endpoints that make a reference to the model

articles/modeling/json-introduction.md

@@ -0,0 +1,25 @@
+# Introduction to Objects in API Document Structure 
+
+- An OpenAPI document is a document that describes an API and conforms to the OpenAPI Specification. These documents can be in YAML or JSON format. 
+- Your OpenAPI document can be a single document or a combination of several associated resources which use the $ref syntax to reference the interrelated resources. 
+
+## Primitive Data Objects Supported in an OpenAPI Document
+
+- integer (int32 and int64)
+- number (float and double) 
+- string 
+- byte
+- binary 
+- boolean 
+- date
+- dateTime
+- password 
+
+## Additional OpenAPI Objects 
+
+- **Info Object**: describes the API's title, description (optional), and version metadata. It also supports other details such as contact information, license, and terms of service. 
+- **Server Object**: identifies the API server and base URL. You can identify a single server or multiple servers and describe them using a description field. All API paths are relative to the URL of the server, for example, "/pets" when fully dilineated, may describe "http://api.hostname.com/pets." 
+- **Paths Object**: outlines relative paths to individual endpoints within your API and the operations or HTTP methods supported by the endpoints. For example, "GET/pets" can be used to return a list of pets. 
+- **Parameter Object**: describes a single operation parameter. Operations can have parameters passed through by several means such as: URL path, query string, cookies, and headers. Parameters can be marked as mandatory or optional, you can also describe the format, data type, and indicate its depreciation status. 
+- **Request body object**: describes body content and media type. It is often used with insert and update operations (POST, PUT, PATCH).
+- **Response object**: describes the expected response which can be referenced using the $ref syntax or described within the document. It associates an HTTP response code to the expected response. Examples of HTTP status codes incldue the 200-OK or 404-Not Found codes. [Click here for more information on HTTP Response codes](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes).

articles/modeling/modeling-introduction.md

@@ -0,0 +1 @@
+

articles/modeling/object-inheritance.md

@@ -0,0 +1,38 @@
+# Object Inheritance 
+
+## What 
+- A **model** contains common resuable information that can be referenced in your endpoint definitions or other models in your API design. 
+- When a model derives its properties from another model, the event is called **inheritance**. 
+- The model which contains the common set of properties and fields becomes a parent to other models, and it is called the **base type**.
+- The model which inherits the common set of properties and fields is known as the **derived type**.
+- If a base type inherits its properties from another model, the derived type automatically inherits the same properties indicating that inheritance is **transitive**. 
+- OpenAPI Specification v2 uses the **allOf** syntax to declare inheritance. 
+- **allOf** obtains a collection of object definitions validated independently but, collectively make up a single object. 
+
+## Why 
+- Inheritance makes your API design more compact. It helps avoid duplication of common properties and fields. 
+
+## Best Practices 
+
+<!-- theme: info --> 
+> Avoid using contradictory declarations such as declaring properties with the samer name but dissimilar data type in your base model and derived model. 
+
+### Example 
+
+```
+{
+  Vehicle: 
+    type: object
+    properties: 
+      brand: 
+        type: string 
+  Sedan: 
+    allOf: # (This keyword combines the Vehicle model and the Sedan model) 
+      $ref: '#/definitions/Vehicle'
+      type: object
+      properties: 
+        isNew:
+          type: boolean
+}
+```
+

articles/modeling/open-ended-objects.md

@@ -0,0 +1 @@
+

articles/modeling/openapi-validation.md

@@ -0,0 +1,38 @@
+# OpenAPI Validation
+
+![](../../assets/gifs/file-validation-oas-spec.gif)
+
+## What
+OpenAPI validation is the process of verifying the underlying OpenAPI file syntax by making sure it conforms to the [OpenAPI Specification requirements](https://github.com/OAI/OpenAPI-Specification#the-openapi-specification) provided by the [OpenAPI Initiative](https://www.openapis.org/). Stoplight immediately validates any changes done to a spec to ensure they are in the correct format prior to being saved.
+
+<!-- theme: info -->
+> Stoplight currently supports the OpenAPI v2 specification. We are working on support for OpenAPI v3, and should have more information in the coming months.
+
+## Why 
+- Validation promotes data integrity in your data store. For example, a user making updates during a PUT operation might omit data for an important property and overwrite valid data, compromising data integrity. 
+- Validations indicates that you are engaging in good design practice and your API design is consistent. 
+
+## Best Practices 
+- All requests made to an API should be validated before processing
+- Mark all mandatory properties as **Required** to ensure that the value of the property is provided 
+- Assign a default value to optional properties or parameters with missing values. The server will use the default value when a value is missing or not provided 
+- You can use the keyword **ReadOnly** to designate a property that can be sent in a response and should not be sent in a request
+
+<!-- theme: info -->
+> Using a default value is not recommended when a property or parameter is mandatory
+
+- An API can comsume different media types, the accepted media type can be specified using the **consume** keyword at the operational level or root level to define acceptable media types. For example: 
+
+```
+consumes: 
+multipart/form-data
+or
+consumes:
+application/json
+```
+- An HTTP response containing a user friendly error description is useful when validation fails
+***
+
+**Related**
+
+* [File Validation](../editor/file-validation.md)

articles/modeling/reference-spec.md

@@ -0,0 +1,43 @@
+# Referencing Another API Specification
+
+<!-- REFBUILDER GIF/VIDEO-->
+
+## What
+
+Referencing another specification allows for cleaner and more organized code. Some use cases are as follows:
+
+* Generate API documentaion in Hubs
+* Deduplicate common structures like responses or shared parameters in Modeling
+* Test a connected API specification in Scenarios
+* Setup a mock server for an API in Prism
+
+## How
+
+1.  Choose the **source**
+
+    * This File
+
+    * This Project
+
+      * Select a **file**
+
+    * Shared/Common
+
+    * External URL
+
+      * Enter a valid **URL** to an existing specification
+
+2.  Select a **target**, if required
+
+3.  Confirm your choice. (Only required if there is a confirm button)
+
+4.  View the referenced specification by clicking the book icon
+
+---
+**Related Links**
+
+* [Reference other Sources](../hubs/ref-other-sources-hubs.md)
+* [Creating Models](../modeling/how-to-create-models.md#How-to-Create-Models-using-the-Stoplight-Modeling-Editor)
+* [Shared Parameters and Responses](../modeling/shared-params-responses.md)
+* [Contract Testing](../testing/contract-testing.md#connecting-the-spec)
+* [Setting Up a Prism Mock Server](../prism/mocking.md)

articles/modeling/security-schemes.md

@@ -0,0 +1,54 @@
+# API Security Schemes
+API security schemes protect your API resources by authenticating apps or users that consume your API. There are a number of standard authentication protocols you can pick from and each has their own strengths and weaknesses. To help you get started, the section below outlines some common schemes in use.
+
+## Authentication Schemes
+### Basic API Authentication
+- Easy to implement
+- Entails sending encoded username and password details
+- Usually bundled with standard framework or language library
+- Used with HTTPS, TLS or SSL
+- Can be combined with other security methods
+- **Note**: this method is susceptible to hijacks and man-in-the-middle attacks
+
+### OAuth1.0 (Digest Scheme)
+- Popular, tested, secure, signature driven, protocol
+- Uses cryptographic signature, which is a mix of token secret, nonce, and other request based information.
+- Can be used with or without SSL
+
+### OAuth2 (Bearer Token Scheme)
+- The current OAuth2 specification eliminates need for cryptographic signatures, passwords, and usernames.
+- OAuth2 works with authentication scenarios called flows, these flows include:
+    - Authorization Code flow
+    - Implicit flow
+    - Resource Owner Password flow
+    - Client Credentials flow
+- The OAuth 2.0 server will distribute access tokens that a client application will use to access protected resources.
+- [Additional Information on OAuth2.0](https://tools.ietf.org/html/rfc6749)
+
+### OpenID Connect Discovery
+- OpenID Connect Discovery (OIDC) is based on the OAuth 2.0 protocol.
+- Uses a sign-in flow that permits user authentication and information access by a client app.
+- The user information is encoded via a secure JSON Web Token (JWT). 
+- [Additional Information on OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html) 
+
+## Best Practices 
+### Implementing IDs
+Unique User IDs should be distinctive but not easy to decipher. 
+- Example: using ‘a12bc3’ is weak when compared to an ID that reads ‘09dgf659sjf038eyr3367dhrt34j5’. Avoid using auto increment for your Unique User IDs to reduce the likelihood of a security breach. 
+### Sensitive Information in HTTP Request 
+Ensure that your API will not expose important information such as password, API keys, and security tokens in the URL. For example, this URL is bad because it contains an API key: 
+- /baseurl/<uid>q=?apiKey=2123223223 
+### API Keys 
+Reduce the likelihood of exposing your API keys by keeping them in a file or storage mechanism that is accessible by the owner. 
+- **Note**: API Keys can be duplicated or lost so it is important to use other security measures apart from API keys. Consider encryption to make your API keys more secure. 
+  
+### Validation 
+It is beneficial to validate your inputs and access to resources using robust parsers. Parsing requests can help verify the validity of user requests. API designers can perform an implicit input validation to ensure the user inputs data with permitted characters, right syntax and character length. Using regular expressions can also help validate string inputs. If a request exceeds the defined limit, you can return a ‘413 Request Entity Too Large’ response code. 
+
+### Audit log 
+Create audit logs before and after security related events. You can also log validation errors to detect patterns or potential attacks.
+### HTTP Status Codes 
+Use status codes and proper error handling techniques for incoming requests to identify probable security risks.
+- [Additional Information on HTTP Status and Error Codes](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes)
+
+

articles/modeling/sending-http-requests.md

@@ -0,0 +1 @@
+

articles/modeling/shared-params-responses.md

@@ -0,0 +1 @@
+

articles/organizations/create-org.md

@@ -0,0 +1,18 @@
+# Create An Organization 
+
+![](../../assets/gifs/org-create.gif)
+
+## What 
+* Organizations are great for grouping people, data, and billing together in one convenient location 
+
+## Who 
+* Only the Billing **Owner** or Organization **Administrator** can create Organizations 
+
+## How 
+1. Click on **+ New**  to the right of Organizations 
+2. Fill in **Name** 
+    * We recommend using your company’s name
+3. Choose the path for your Organization (optional)    
+4. Add member by email (optional) 
+    * Input email accounts to add other members to your organization 
+        * You can also do this later 

articles/organizations/customize-org.md

@@ -0,0 +1,22 @@
+# Customize Your Organization 
+
+![](../../assets/gifs/org-settings.gif)
+
+## What 
+* Want to modify your Organization? In Stoplight you can modify your Organization's: 
+    * Name 
+    * Org Path 
+    * Add a Description 
+    * Add an Org Image 
+    
+## Who 
+* Only an Organization **Owner** or **Administrator** can modify Organizations  
+
+## How
+1. From the homepage, select the **Organization** you would like to modify 
+2. Select the **Settings** tab 
+3. Input a **Name** 
+4. Input a **Path** 
+5. Input a quick sentence about your organization 
+6. Select an **image** file for your Org 
+

articles/organizations/delete-org.md

@@ -0,0 +1,15 @@
+# Delete an Organization 
+
+![](../../assets/gifs/org-settings.gif)
+
+## What 
+* Deleting an organization is easy peasy, but once you delete an Org, there is no going back. Please be certain. 
+## Who 
+* Only the Organization’s **Owner** 
+## How
+1. From the homepage, select the **Organization** you would like to delete 
+2. Select the **Settings** tab 
+3. Scroll to the bottom of the page to the **Danger Zone**
+4. Click on **Delete this Org**
+5. Confirm the deletion by clicking okay on the proceeding popup 
+6. Wipe the tears from your eyes and say goodbye 

articles/organizations/managing-people.md

@@ -1 +1,17 @@
+# Invite People to an Organization
 
+![](../../assets/gifs/people-invite.gif)
+
+## What 
+* Adding people to your Organization is the first step towards collaboration within Stoplight
+
+## Who 
+* Only an Organization **Owner** or **Administrator** can invite people to an Organization 
+
+## How
+1. From the Stoplight homepage, select the **Organization** you would like to invite people to 
+2. Select the **People** tab from the tabs bar 
+3. Click **Invite Member** 
+4. In the popup that appears input email addresses or usernames 
+5. Hit **enter** to add them to your list 
+6. Once completed, click the **Invite** button 

articles/organizations/mention-people.md

@@ -0,0 +1 @@
+

articles/organizations/remove-people.md

@@ -0,0 +1,17 @@
+# Remove People From Your Organization 
+
+![](../../assets/gifs/org-member-remove.gif)
+
+## What 
+* Removing a person for your organization is as easy as 123...4...5...6
+
+## Who 
+* Only an Organization **Owner** or  **Administrator** can modify
+
+## How 
+1. From the homepage, select the **Organization** you would like to modify 
+2. Select the **People** tab from the tab bar 
+3. Find the person you would like to remove from the list 
+4. To the right of the person’s name, click on the **dropdown arrow** to the left of the person’s role 
+5. In the dropdown menu that appears, select **Remove Member** 
+6. Click **Okay** in the popup prompt 

articles/organizations/roles.md

@@ -0,0 +1,23 @@
+# Organization Member Roles and Permissions 
+
+![](/assets/gifs/people-invite.gif)
+
+## What 
+* Roles and Permissions for members of Organizations can be managed and modified within Stoplight to control access to the Organization's functions and features 
+    * There are 3 Roles: 
+        * **Owner** 
+            * Owners can update the org, its connections, and its members 
+            * Has access to Billing and Organization Settings
+        * **Administrator** 
+            * Admins can update the org, its connections, and its members 
+        * **Member** 
+            * Members can update the org and its connections. They can view its members 
+
+## Who
+* Only an Organization **Owner** or **Administrator** can modify roles and permissions 
+## How 
+1. From the homepage, select the **Organization** you would like to modify 
+2. Select the **People** tab from the tab bar 
+3. Find the person you would like modify 
+4. To the right of their name click on the **down carrot** button to the left of the person’s role 
+5. In the dropdown menu select the desired role with accompanying permissions 

articles/organizations/transferring-ownership.md

@@ -0,0 +1,17 @@
+# Transfer Primary Ownership of Your Organization
+
+![](/assets/gifs/org-transfer.gif)
+ 
+## What 
+* You can promote another Member of your Organization to the role of Owner
+    * You can only transfer ownership to a Member of the Organization
+## Who 
+* Only the Organization **Owner** can transfer ownership of an Organization 
+## How
+1. From the homepage select the **Organization** you wish to modify 
+2. Select **People** from the tabs bar 
+3. Find the Member you would like to modify from the list 
+4. To the right of the Member’s name, click on the **down carrot** next to the Member’s current role 
+5. From the dropdown menu that expands, select **Owner** 
+6. You will then be asked to confirm your selection in a popup window
+7. Click **Ok** 

articles/prism/overview.md

@@ -0,0 +1,62 @@
+# Prism Introduction 
+
+Prism is a performant, dependency free server, built specifically to work with web APIs. 
+
+### Features 
+- Act as a mock server, routing incoming requests to example repsonses, or dynamically generating examples on the fly. 
+- Act as a transformation layer, manipulating incoming requests and outgoing responses. 
+- Act as a validation layer, validating incoming requests and outgoing responses. 
+- Contract test your APIs, given an OAS(Swagger 2) file. 
+- Log all or a subset of traffic to configurable locations. 
+- Extend existing APIs with new endpoints or capabilites. 
+- Act as a system-wide proxy, blocking traffic to particular websites or endpoints. 
+
+### Simplicity Redefined 
+Run it anywhere. It runs on OS X, Windows, and Linux, with no external dependencies. It is a single, self-contained binary file, that you can easily run from your terminal with a single command.  
+
+## Getting Started 
+
+#### macOS and Linux 
+
+```# Install Prism 
+curl https://raw.githubusercontent.com/stoplightio/prism/master.install.sh | sh
+```
+
+#### Windows 
+Download the appropriate binary from [here](https://github.com/stoplightio/prism/releases). Unzip the binary file, then navigate in your terminal to the folder where you extracted Prism. 
+
+### Run a Simple Mock Server 
+Prism understands OAS(Swagger 2), so let's get started by spinning up a quick mock server for the popular Petstore API. To do this, run the following command in your terminal: 
+
+```# os x / linux
+prism run --mock --list --spec http://petstore.swagger.io/v2/swagger.json
+
+# windows 
+path/to/prism.exe run --mock --list --spec http://petstore.swagger.io/v2/swagger.json
+```
+
+Here, you are using the "run" command to run a server based on the spec file passed in via the --spec argument. The spec location can be the filepath to a file on your computer, or the URL to a publicly hosted file. The --mock argument tells Prism to mock all incoming requests, instead of forwarding them to the API host described in the spec file. The --list argument is a convenience, and tells Prism to print out the endpoints in the spec on startup. 
+
+Prism starts on port 4010 by default - try visiting ```http://localhost:4010/v2/pet/findByStatus``` in your browser. This is one of the endpoints described in the petstore spec you passed in. You'll notice that it returns an error about a required query string parameter "status". This is the automatic request validation at work! The swagger spec specifies that a query string parameter names "status" is required for this endpoint so Prism simulates a 400 response for you. Reload the page with a query string parameter, and you will see the dynamically generated mock response ```http://localhost:4010/v2/pet/findByStatus?status=available```.
+
+Tada! With a single command you have started a validating, dynamically mocking version of the Swagger petstore API. 
+
+### Run some Contract Tests
+
+Prism consumes OAS(Swagger 2) files. OAS provides the contract for your API. If your OAS file contains the x-tests extension (generated automatically if you use the Stoplight app to manage your OAS and tests) then you can run tests with Prism.
+
+Check out [this specification](https://goo.gl/jniYmw). If you scroll past all the regular OAS properties, you will notice a ```x-tests``` extension near the bottom of the file. Inside of that property, we have a few test cases defined. This OAS file, along with its tests, is managed in the Stoplight app (we export our API from within the app to produce this file). 
+
+#### To Run the Contract Tests 
+```
+# os x / linux 
+prism test --spec https://goo.gl/jniYmw
+
+# windows
+path/to/prism.exe test --spec https://goo.gl/jniYmw
+```
+
+You should see some nice output to your terminal detailing the tests and assertions that are run. These tests take our OAS contract and apply it to your API. They act as a sort of sync manager. 
+
+<!-- theme: info -->
+> If a test fails, it means one of two things - your API is broken or, our OAS contract is out of date / incorrect 

articles/prism/run-prism-local.md

@@ -0,0 +1 @@
+

articles/prism/specification.md

@@ -0,0 +1 @@
+

articles/prism/validation.md

@@ -0,0 +1,4 @@
+
+<!--stackedit_data:
+eyJoaXN0b3J5IjpbLTE5Mzc0MDU2MjJdfQ==
+-->

articles/projects/change-member-role.md

@@ -0,0 +1,30 @@
+# Change a Project Member's Role
+
+![](/assets/gifs/project-member-invite.gif)
+ 
+## What 
+* You can invite people to a Project to grant them read or read/write permissions 
+* There are three tiers of read/write permissions 
+    * **Admin Access**: Upper level permissions that allow you to:
+        * Read/Write
+        * Invite and Manage Members and Teams
+        * Manage Project Settings
+        * Delete the project 
+    * **Write Access**: Mid-level permissions that allow you to: 
+        * Read/Write 
+    * **Read Access**: Low-level permissions that allow you to: 
+        * Read
+      
+   
+## 	 Who 
+* Only the Organization **Owner** and Org and/or Project **Administrators** can modify member roles
+
+## How
+1. From the Stoplight homepage select the **Project** you wish to modify 
+2. By deafult, all members of the Organization the Project is associated with will have Read permission 
+3. To invite a single member, select the **Member icon** from the far left sidebar
+    * Input their username in the search bar at the top of the Member sidebar
+    * Once located, press enter 
+4. To invite a team, select the **Team icon** from the far left sidebar
+    * Input the Team name in the search bar at the top of the Team sidebar 
+    * Once located, press enter 

articles/projects/create-project.md

@@ -0,0 +1,34 @@
+# Creating a Project  
+
+![](../../assets/gifs/project-create-personal.gif)
+
+## What 
+Projects are the workspace of the Stoplight Platform. Projects contain: 
+* File Explorer 
+* Project Governance 
+* Documentation Editor (Hubs)
+* Modeling Editor 
+* Testing (Scenarios) 
+* Mocking (Prism) 
+* Markdown Editor 
+
+<callout>Single Point of Truth All editors are now contained within a Project </>
+
+## Who 
+Individual users can create Personal Projects. Organizations can create Org Projects. 
+
+## How 
+
+### Personal Project
+1. From the homepage select the **Personal Project** tab 
+
+### Organization Project 
+1. From the homepage select the **Organization** you want to create a Project within
+	* By default you will land on Organization Projects 
+
+### Create a Project
+2. Input a **Project Name**
+3. Input a custom **Project Path** (optional)
+4. Input a **Project Description** (optional)
+5. Select **Public** or **Private** 
+6. Select **Create Project** once complete 

articles/projects/invite-people-team.md

@@ -0,0 +1,31 @@
+# Invite People & Teams to a Project
+
+![](../../assets/gifs/project-member-invite.gif)
+ 
+## What 
+* You can invite people to a Project to grant them read or read/write permissions 
+* There are three tiers of read/write permissions 
+    * **Admin Access**: Upper level permissions that allow you to:
+        * Read/Write
+        * Invite and Manage Members and Teams
+        * Manage Project Settings
+        * Delete the project 
+    * **Write Access**: Mid-level permissions that allow you to: 
+        * Read/Write 
+    * **Read Access**: Low-level permissions that allow you to: 
+        * Read
+      
+<callout>You can only invite people and Teams to a Project associated with an Organization</>
+   
+## 	 Who 
+* Only the Organization **Owner** and Org and/or Project **Administrators** have invite privileges 
+
+## How
+1. From your Organization's homepage, select the **Project** you wish to modify 
+2. By deafult, all members of the Organization the Project is associated with will have Read permission 
+3. To invite a single member, select the **Member icon** from the far left sidebar
+    * Input their username in the search bar at the top of the Member sidebar
+    * Once located, press enter 
+4. To invite a team, select the **Team icon** from the far left sidebar
+    * Input the Team name in the search bar at the top of the Team sidebar 
+    * Once located, press enter 

articles/projects/visibility.md

@@ -1 +1,14 @@
-## Making Your Project Private/Public
+## Making Your Project Private & Public
+
+![](../../assets/gifs/project-privacy.gif)
+
+## What 
+* You can choose to make your Project Public or Private 
+    * **Private**: Only designated collaborators will be able to read it. Additionally, connections from ALL dependent entities outside of this Organization will be removed 
+    * **Public**: Anyone can read it 
+## Who
+* Only the Organization **Owner** and Org and/or Project **Administrator** can modify
+## How
+1. Select the **Project** you wish to modify 
+2. Select the **gear icon** on the left hand sidebar 
+3. Under **Danger Zone** Select **Public** or **Private** 

articles/teams/add-people.md

@@ -0,0 +1,21 @@
+# Add People to a Team 
+
+![](../../assets/gifs/team-member-remove.gif)
+
+## What 
+
+* Adding people to a team lets you collaborate on projects while allowing an additional level of control over permissions.
+
+## Who 
+
+* Team **Owners**, **Administrators**, and **Members** can add people to a team 
+
+## How
+
+1. From the homepage select the **Organization** associated with the team 
+2. Select **Teams** on the tab bar
+3. Select the team that you would like to add people to.
+4. Click the **Invite Members** button
+5. Input the person’s email or Stoplight username in the textarea and press enter 
+    * Note: you can add more than one person at a time
+6. Once completed, click on the **Invite** button

articles/teams/create-team.md

@@ -0,0 +1,21 @@
+# Create a Team 
+
+![](../../assets/gifs/team-create.gif)
+
+## What 
+* Teams makes it easier for Organization Members to collaborate and allows additional control over permissions 
+
+## Who
+* Only an Organization **Owner** or **Administrator** can create a Team
+
+## How
+1. From the homepage, select the **Organization** you would like to make a team for 
+2. Select the **Teams** tab from the tabs bar 
+3. Create Your First Team 
+    * Input a **Team Name**(A department, project group, etc.)  
+    * Input a **Description** (What does this team do?) 
+    * Input **Members** (email or username)
+        * Send email notifications to invited members? (optional) 
+        * If the invited member does not already have a Stoplight account, an email will be sent with instructions on how to complete the account creation process 
+4. Click **Create Team** once finished 
+

articles/teams/customize-team.md

@@ -0,0 +1,21 @@
+# Customize a Team 
+
+![](../../assets/gifs/teamcustom.gif)
+
+## What 
+
+* You can customize the Team Name, Path, and Team Description 
+
+## Who 
+
+* Only Team **Owner** or **Administrator** can customize a Team
+
+## How
+
+1. From the homepage select the **Organization** associated with the Team you wish to modify 
+2. Select **Teams** from the tab bar 
+3. From the Teams homepage select the Team you wish to customize
+      * Then select **Team Settings** from the tab bar 
+          * Input a new Team Name in the textarea under **Team Name**
+          * Input a new Team URL in the textarea under **Path**
+          * Input a new Team Description in the textarea under **Description**   

articles/teams/delete-team.md

@@ -0,0 +1,14 @@
+# Delete a Team 
+
+![](../../assets/gifs/teamcustom.gif)
+
+## What 
+* Want to disband your team? Here's how: 
+## Who 
+* Only the Organization **Owner** or a Team **Owner** or **Administrator** can delete a team 
+## How 
+1. Select the **Organization** associated with the team you wish to modify 
+2. Select **Teams** from the tab bar 
+3. Click on the **red X icon** located to the right of the team you wish to delete 
+4. A popup will appear asking if you are sure you want to delete this team 
+5. Click **Ok** 

articles/teams/member-roles.md

@@ -0,0 +1,24 @@
+# Team Member Roles and Permissions
+
+![](/assets/gifs/team-member-remove.gif)
+
+ ## What 
+* Roles and Permissions for Team members can be managed and modified within Stoplight to control access to the Team’s functions and features 
+    * There are 3 Roles: 
+        * **Owner** 
+            * Owners can update the Team, its connections, and its collaborators. They can also update the team's settings and delete the team.
+        * **Administrator** 
+            * Admins can update the Team, its connections, and its collaborators. 
+        * **Member** 
+            * Members can view and create projects. They can view the Team's members.
+           
+## Who
+* Only the Team **Owner** or **Administrator** can modify Roles and Permissions 
+
+## How 
+1. From the homepage, select the **Organization** associated with the Team you would like to modify 
+2. Select the **Teams** tab from the tab bar 
+3. Select the Team you would like modify 
+4. To the right of the member’s name click on the **down carrot** button to the left of the person’s role 
+5. In the dropdown menu select the desired role with accompanying permissions 
+

articles/teams/remove-people.md

@@ -0,0 +1,22 @@
+# Remove People from a Team
+
+![](../../assets/gifs/team-member-remove.gif)
+ 
+## What 
+
+* Want to bench a member of your team? Here's how: 
+
+## Who 
+
+* Only the Team **Owner** or **Administrator** can remove people from a Team 
+
+## How 
+
+1. From the homepage select the **Organization** associated with the Team you wish to modify
+2. Select **Teams** from the tab bar 
+3. Select the Team you wish to modify from the list 
+4. Find the member of the team you wish to remove 
+5. To the right the member’s name click the **down carrot** 
+6. In the dropdown menu select **Remove Member** 
+7. A popup window will ask you to confirm your removal 
+    * Click Ok  

articles/teams/transfer-ownership.md

@@ -0,0 +1,16 @@
+# Transfer Primary Ownership of a Team 
+
+![](../../assets/gifs/team-transfer.gif)
+
+## What 
+* You can transfer Ownership of a Team to another member of the Team 
+## Who 
+* Only the Team **Owner** can transfer Ownership of a Team
+## How 
+1. From the homepage select the **Organization** that is associated with the Team you wish to modify 
+2. Select **Teams** from the tab bar 
+3. Select the Team you wish to modify 
+4. Find the Member of the Team you wish to transfer ownership to 
+5. Click on the **down carrot** to the right of the Member’s name 
+6. Select **Owner** from the dropdown menu 
+7. Click **Ok** in the proceeding popup 

articles/testing/adding-validations.md

@@ -0,0 +1 @@
+

articles/testing/continuous-integration-travis.md

@@ -0,0 +1 @@
+

articles/testing/continuous-integration.md

@@ -0,0 +1 @@
+

articles/testing/contract-testing.md

@@ -0,0 +1,37 @@
+# Contract Testing
+
+Scenarios makes it easy to incorporate your OAS / Swagger API specification into your testing process. A few benefits to doing this include:
+
+- **DRY**: Don't re-create test assertions that check for what is already described in your API contract.
+- **Governance**: Quickly figure out if the API that was created actually conforms to the API design that was initially agreed upon.
+- **Sync Manager**: Your API spec is the single point of truth that describes your API. From it, you might generate documentation, sdks, mock servers, etc. Incorporating your spec into your tests makes sure that your API spec accurately represents your API over time.
+
+<!-- theme: info -->
+> If you don't have an API specification yet, you can create one using the Stoplight modeling tool!
+
+## Connecting The Spec
+
+The first thing you need to do to get started with contract testing is connect your API spec to the Scenarios Collection.
+
+1. Create a new (or open an existing) **Scenario file** in the Stoplight editor
+2. Select **Swagger/OAS Coverage** in the Scenarios menu to the left
+3. Open **Contract Test Settings**
+4. Click **+ Add Spec**
+5. Select a file from either **This Project** or an **External URL**
+6. You are all set! You can now test against an API spec. 
+
+## Using the Coverage Report
+
+The coverage report gives you a quick overview of which parts of the connected specs are covered by test assertions in the current Scenario Collection.
+
+You can use the coverage report to quickly stub out a new scenario. Just click the status codes in the table matrix for the steps you want to add to your scenario (in order). Once you've added all the steps, click the "Create Scenario" button in the top right. This will create a scenario with as much setup as possible, using the connected spec for data. It will set your request body, set variables in a sensible way, automatically setup contract tests, and more.
+
+You will likely need to tweak the resulting scenario a little bit, but this process will usually get you most of the way to a complete scenario, with contract test assertions in place!
+
+## Automatic Contract Test Assertion
+
+After linking your spec to the Scenario Collection, contract test assertions will be automatically added for step assertions.
+
+Stoplight will look through your API specification for a operation that matches the step's HTTP method + URL, and use the response status code returned from the API to look up the JSON schema. In the example below, we are testing the 200 response schema in our API spec for the GET /todos/{todoId} endpoint.
+
+When this step is run, the HTTP response structure will be validated against the matched JSON schema from our API spec, and any errors will be added to the test results.

articles/testing/leverage-openapi.md

@@ -0,0 +1 @@
+

articles/testing/overview.md

@@ -0,0 +1 @@
+

articles/testing/pass-data-steps.md

@@ -0,0 +1 @@
+

articles/testing/ref-other-scenarios.md

@@ -0,0 +1 @@
+

articles/testing/run-test-stoplight.md

@@ -0,0 +1 @@
+

articles/testing/run-test-terminal.md

@@ -0,0 +1,80 @@
+# Running a Scenario from Terminal
+
+It is very easy to run scenario collections, or individual scenarios, on your own computer, completely outside of the Scenarios app.
+
+First, install Prism, our command line tool for running scenarios.
+
+*On macOs or Linux:*
+```
+curl https://raw.githubusercontent.com/stoplightio/prism/2.x/install.sh | sh
+```
+
+*On Windows:*
+```
+Download from https://github.com/stoplightio/prism/tree/2.x
+```
+
+After installing, you should be able to run `prism -h` (or `prism.exe -h` in Windows) and see some help text. 
+
+The Scenario app has a convenient display that gives you the exact command required to run the collection or scenario that you are viewing, taking into account your current environment variables. If you have the Scenario editor connected to a local file on your computer, it will use the path to that file, otherwise it will use the Scenario SRN (unique identifier).
+
+<!-- theme: warning -->
+> Keep in mind that if you are storing your Scenarios on Stoplight's servers, and running them from the command line, you must save them in the Stoplight app before running! This is because Prism will make a call to the Stoplight API to fetch your Scenario JSON, which it will then run from your computer.
+
+See below for a screenshot of the "Run From Terminal" command generator. The command in this box will update live in response to environment, user, and scenario changes.
+
+![](http://i.imgur.com/mqpNanE.png)
+
+## Running Local Files
+
+The `prism conduct` command accepts a filepath. So, if you are working with [local scenario collection](#docTextSection:Ap4Z2B7RgbbLFLjJD) .json files, you can run them with something like:
+
+```bash
+prism conduct /path/to/collection.json
+```
+
+## Including Specs For Contract Testing
+
+If you are using [contract testing](#docTextSection:tFWniZdshJYLLtKms), you will need to include the filepath to the API specification as part of the command. This is what that looks like:
+
+```bash
+prism conduct myOrg/scenarios/myScenarios --spec /path/to/my/swagger.json
+```
+
+## Continuous integration
+
+Most CI products (Circle CI, Travis, Jenkins, Codship, etc) generally function in the same way: setup environment, invoke commands to run tests. With Scenarios + Prism, the process is similar. Install Prism, and then configure the CI process to run the appropriate Prism command. We've included instructions for Circle CI below, but these concepts should loosely apply to other CI products.
+
+#### Circle CI
+
+Integrating [Prism](http://stoplight.io/platform/prism) into Circle CI is easy. All you need to do is install Prism and overide the test command.
+
+To install Prism just add a dependency to your circle config.
+
+
+``` yaml
+dependencies:
+  pre:
+    - curl https://raw.githubusercontent.com/stoplightio/prism/2.x/install.sh | sh
+```
+
+
+Then override the default test command for circle in your config.
+
+
+``` yaml
+test:
+  override:
+    - prism conduct orgId/scenarios/scenarioId
+```
+
+When running `prism conduct` you can:
+
+- Use the Scenario SRN, as displayed above.
+- Include the Scenario JSON on your CI server, and pass in its absolute file path
+- Pass in the absolute URL to the scenario JSON served up via HTTP.
+
+<!-- theme: warning -->
+> Don't forget to pass in any required environment values with the --env command line flag (or you can provide the filepath to a json file with your environment variables)!
+
+For convenience, you can find the full command to run your scenario collection or individual scenario in the Stoplight app.

articles/testing/run-test-url.md

@@ -0,0 +1 @@
+

articles/testing/scenario-spec.md

@@ -0,0 +1 @@
+

articles/testing/scenarios-introduction.md

@@ -0,0 +1,17 @@
+Stoplight Scenarios is a powerful (but accessible!) tool that takes the pain out of API testing. It is a standalone product, available on [the web](https://scenarios.stoplight.io), and as a [desktop app](https://download-next.stoplight.io).
+
+We generally recommend the desktop app when possible. It works with local servers, behind firewalls, and exchanges information with tools on your computer like Git or your favorite IDE. You can switch seamlessly between the desktop app and the web app.
+
+We engineered Scenarios from the ground up to be:
+
+- **Powerful** Easily assert, capture, transform, and validate your API Spec (Swagger) against your actual API. And if that isn’t enough, Prism has a powerful javascript runtime.
+
+- **Portable** Scenarios are described in plain JSON with a well thought out, robust specification. Use our visual editor to quickly generate and manage this JSON. They can be run from our visual tooling, or completely outside of Stoplight, on your own machines or on your continuous integration server.
+
+- **Flexible** Your APIs, your tests, your way. Scenarios only test what you want them to. They have no opinion about your architecture (Monolithic vs Microservices), company structure (in house vs distributed), development lifecycle (production vs TDD), and your environment (development vs staging vs production).
+
+- **Fast** Time can’t be slowed down, and we can’t give it back to you. Creating tests should be quick, and waiting for you tests to run shouldn’t feel like watching water boil. Scenarios are run concurrently for maximum speed - run hundreds of API requests and test assertions in seconds.
+
+### Editor UI Overview
+
+![](https://cdn.stoplight.io/help-portal/scenarios/scenario-editor-callout.png)

articles/testing/scripting.md

@@ -0,0 +1 @@
+

articles/testing/send-http-requests.md

@@ -0,0 +1,50 @@
+# Overview of Testing with HTTP Requests 
+
+## What are HTTP methods? 
+
+- Hypertext Transfer Protocol (HTTP) is a set of rules that define how information is requested, transmitted, and formatted between a client and a server. HTTP methods (verbs) are used to implement create, read, update, and delete operations on identified resources. 
+- HTTP methods are classified as safe, non-safe methods, idempotent or non-idempotent methods. Safe methods do not change the state of a resource. Idempotent methods, if executed severally, deliver consistent outcomes. An example of idempotency is outlined below:
+
+### Example 
+- petAge = 2 # will always return 2 even when the statement is executed over and over again. This statement is idempotent. 
+- petAge++ # will return different results based on the number of executions. This statement is non-idempotent. 
+
+## Methods
+- The **GET** method retrieves data and resource representation. It does not change the state of a resource and several executions produce the same results. Thus, it is a safe and idempotent method. When a GET method is successful, it should return a 200 (OK) HTTP status code with the content in the response body and a 404 (NOT FOUND) code if the resource is not available. 
+- The **POST** method creates new resources. The POST method is not safe and is non-idempotent as the execution of similar POST requests will create two different resources with similar details. It is suggested for non-idempotent resource requests. 
+- The **PATCH** method makes partial updates to a resource and it is non-idempotent. 
+- The **PUT** method updates a resource or creates a new resource if it does not exist. It is ideal for the complete update of a resource. The PUT method is idempotent but not safe. 
+- The **DELETE** method deletes a resource. It is idempotent but not safe. 
+
+### Summary 
+The GET method is the only safe method, as it does not change the state of a resource. GET, PUT, and DELETE methods are idempotent while the POST and PATCH methods are non-idempotent. 
+
+## Testing with HTTP Requests 
+- Testing using HTTP Requests demonstrates whether or not an API will perform as expected when it is deployed to a production server and integrated with existing platforms. 
+
+<!-- theme: info -->
+> HTTP Request Tests should include checks to the response code, message, and body.
+
+- Apart from verifying the functionality of essential features, HTTP Request Tests **save time and cost**.
+
+## Testing with HTTP Requests: Best Practices 
+
+### GET
+- Test the GET method to confirm it returns the correct data.
+- Test a valid GET request to ensure it returns a 200 (OK) status code or 404 (NOT FOUND) if invalid 
+- Ensure you test every endpoint fetching data within your API before deployment to a production server. 
+
+### POST
+- Test the POST method to confirm it creates a resource and returns a 200(OK) code and/or 201(CREATED) code if valid. If invalid, look for a 4xx error status code. 
+- You can use the GET method to see the outcome of the POST operation. 
+
+### PUT & PATCH
+- The PUT and PATCH update methods should be tested to ensure that a 200(OK) status code or 204(NO CONTENT) is returned for a successful transaction. If unsuccessful, look for a 4xx error status code. 
+
+### DELETE
+- Test the DELETE request to certify it returns a 4xx error code if a DELETE operation is executed against an invalid or non-existent resource. 
+- Test the DELETE request to confirm it returns a 200(OK) for a successful operation. 
+- Tests for the DELETE method **must not** be done with data residing on a production or live data store. 
+
+<!-- theme: info -->
+> Testing is a critical stage of the API development life cycle and the type of tests executed will depend on the complexity of the API, time, budget, etc. It is vital to conduct robust tests to reveal any inconsistencies or defects in the API before it is shipped to a production server or interfaced with other platforms.  

articles/testing/variables-context.md

@@ -0,0 +1,101 @@
+# Using Context Variables
+
+<!--(FIXME - SHOW WRITING VARIABLE TO CONTEXT IN STEP)-->
+
+Context variables allow you to dynamically store and share data between steps in a scenario. Contrary to environment variables, context variables are _not_ saved once a test has completed. Therefore, context variables are only suitable for temporary data. 
+
+Context variables are scoped to the scenario, _not_ the collection. This means that two scenarios can both read/write the same context variable `myVar`, and not conflict with each other. Environment variables, on the other hand, are shared amongst all scenarios, and are scoped to the collection.
+
+At the start of a test run, the context object is empty. Good examples of data to store in a context would be things like ID's, usernames, and randomly generated tokens.
+
+## Use Case
+
+Context variables make it possible to chain related steps together. For example, say we have the following set of actions to perform:
+
+1. Create User, `POST /users`. Returns a new user object, with an `id` property.
+2. Get User, `GET /users/{$.ctx.userId}`.
+3. Delete User, `DELETE /users/{$.ctx.userId}`.
+
+Somehow we need to use the `id` property for the user created in step #1 to build the request in steps #2 and #3. This is a great case for context variables, since the data is temporary (the new user's id changes every test run, and is only needed in this single scenario).
+
+To accomplish this, we would capture/set the `$.ctx.userId` property to `output.id` in step #1, and then use that variable to create the request urls in #2 and #3 (shown above).
+
+## Setting Context Variables
+
+### With Captures
+
+<!--(FIXME - SHOW USING THE CAPTURE MENU IN A SCENARIO STEP)-->
+
+The capture UI in the step editor makes it easy to set `$.ctx` values. You can use values from the step output or input, including headers, response bodies, etc.
+
+<!-- theme: info --> 
+> Multiple captures can be applied to the same step, to set multiple `$.ctx` values.
+
+### With Scripting
+
+<!--(FIXME - SHOW SCREENSHOT OF SCRIPT IN STEP)-->
+
+Scripting allows you to use more complicated logic in a scenario step. Scripts
+are executed either before or after a step request finishes. Scripts are plain
+Javascript and give you direct access to the scenario context through the global
+`$.ctx` object.
+
+For example, if we wanted to set the `userId` property as described in the use case above, we would add an after script to the first step with the code:
+
+```javascript
+// store the step output body's 'id' property in the context, for use in subsequent steps
+$.ctx.set('userId', output.body.get('id'));
+```
+
+Where the `$.ctx.set(x, y)` function adds the data referenced in the second
+argument (`y`) to the context under the string value of the first argument
+(`x`). 
+
+Here is another example that just sets `myVariable` to the hardcoded value `123`:
+
+```javascript
+$.ctx.set('myVariable', 123);
+```
+
+## Using Context Variables
+
+<!--(FIXME - SHOW USING A CONTEXT VARIABLE IN A SCENARIO STEP)-->
+
+To use a context variable in a scenario, use the following syntax:
+
+```
+{$.ctx.myVariable}
+```
+
+Where:
+
+* `{...}` - Braces signify that this is a variable.
+* `$` - The "single dollar sign" syntax is a reference to the current scenario's
+  runtime scope. Again, context variables are scoped to the individual scenario, not the global collection!
+* `ctx` - This is the actual context object onto which values are stored and retrieved.
+* `myVariable` - This is the name of the variable being referenced within the context.
+
+When the scenario or step is run, all context variables will
+automatically be populated based on the contents of the `$.ctx` at
+runtime.
+
+### In Scripts
+
+Similar to the example above, when referencing a context variable in a step
+script, use the following syntax:
+
+```javascript
+$.ctx.get('myVariable');
+```
+
+Where the braces (`{}`) are absent, and we are using the `get()` method for
+retrieving the context variable under the `myVariable` key.
+
+***
+
+**Related**
+
+* [Environment Overview](../editor/environments.md)
+* [Environment Configuration](../editor/editor-configuration.md)
+* [Variables Overview](./variables-overview.md)
+* [Context Variables](./variables-context.md)

articles/testing/variables-environment.md

@@ -0,0 +1,93 @@
+# Using Environment Variables
+
+<!--(FIXME - SHOW CLICKING THROUGH ENVIRONMENTS IN UI)-->
+
+> If you have not already done so, we recommend reviewing the
+[Environments](../editor/environments.md) article before continuing.
+
+Environment variables in Stoplight allow you to dynamically retrieve information
+in a scenario from the active environment. This makes it possible to
+switch between different environments with ease, having variables automatically
+populate based on the current environment.
+
+## Setting Environment Variables
+
+### With the Editor Configuration
+
+For information on managing project environments, please review the [environment](../editor/environments.md) article.
+
+### With Captures
+
+Captures make it easy to "capture" values from your step request or result, and save them back to an environment variable for later use. Simply switch to the `captures` tab in the scenario step, and choose $$.env as the target property.
+
+Say you have a scenario step that sends an HTTP request to authenticate a new user. The response from that request includes an apiKey that you want to use for other requests. You can easily save that apiKey to an environment variable, for later re-use, by adding a capture in the form `$$.env.apiKey = output.body.apiKey`. After running the step, check your current environment variables and note the newly added apiKey!
+
+> Environment variables set via captures are only added to the user's private
+  variables, and are not sent to Stoplight. See the [Environment
+  section](../editor/environments.md) for more information.
+
+### With Scripting
+
+Scripting allows you to use more complicated logic in a scenario step. Scripts
+are executed either before or after a step finishes. Scripts are plain
+Javascript and give you direct access to the scenario environment through a
+global `$$.env` object.
+
+To add variables to the environment, use the following syntax:
+
+```javascript
+// store the step output (response) body's 'username' property in the environment
+$$.env.set('username', output.body.get('username'));
+```
+
+Where the `$$.env.set(x, y)` function adds the data referenced in the second
+argument (`y`) to the environment under the string value of the first argument
+(`x`).
+
+> Environment variables set via script are only added to the user's private
+  variables, and are not sent to Stoplight. See the [Environment
+  section](../editor/environments.md) for more information.
+
+## Using Environment Variables
+
+<!--(FIXME - SHOW USING A VARIABLE IN A SCENARIO STEP)-->
+
+Use an environment variable in a scenario with the following syntax:
+
+```
+{$$.env.myVariable}
+```
+
+Where:
+
+* `{...}` - Braces signify that this is a variable.
+* `$$` - The "double dollar sign" syntax is a reference to the global
+  scope.
+* `env` - The `env` property holds the active environment's data.
+* `myVariable` - This is the variable being referenced, which comes from the
+  active environment's resolved variables. Substitute your own variable name when using
+  this in your scenarios.
+
+When the scenario or step is run, any environment variables will
+automatically be populated based on the editor's active environment.
+
+### In Scripts
+
+Similar to the example above, when referencing an environment variable in a step
+script, use the following syntax:
+
+```javascript
+$$.env.get('myVariable');
+```
+
+Where the braces (`{}`) are absent, and we are using the `get()` method for
+retrieving the environment variable under the `myVariable` key.
+
+***
+
+**Related**
+
+* [Environment Overview](../editor/environments.md)
+* [Environment Configuration](../editor/editor-configuration.md)
+* [Variables Overview](./variables-overview.md)
+* [Context Variables](./variables-context.md)

articles/testing/variables-overview.md

@@ -0,0 +1,30 @@
+# Variables Overview
+
+Variables in Stoplight provide a powerful and intuitive way to dynamically set, 
+update, and retrieve information at any step in a Scenario.
+
+Variables are stored in an [environment](../editor/environments.md). You can define one or more environments,
+each with their own variables. This makes it easy to quickly swap out sets of 
+variables during testing.
+
+There are a variety of circumstances where you might consider using variables instead of hardcoding the value, for example:
+
+- __hostnames__: Instead of hard-coding a particular server location, use a variable
+so that the host can quickly be changed to test multiple server locations (development versus production, for example).
+- __api keys__
+- __usernames and passwords__
+- __ports__
+- __path parameters__: Instead of defining a request `GET /users/123`, you can define a request `GET /users/{$$.ctx.userId}`.
+
+There are two scopes for variables, which affect how and when they can be used.
+
+* __Environment Variables__ - Environment variables are scoped to the project, and are shared amongst all steps in your test run. They are persisted between test runs, and are great for data that does not change often (hostnames, ports, etc). See [here](./variables-environment.md) for more information on how to use environment variables.
+
+* __Context Variables__ - Context variables are scoped to the scenario, and are reset on every test run. They are useful to persist test and application state between scenario steps. Context variables are great for temporary information that is only relevant to the current test run. For example, you might store a newly created `userId` returned in your first step, to be used in the second step. This `userId` changes on every test run, which makes it a good context variable candidate. See [here](./variables-context.md) for more information on how to use context variables.
+
+***
+
+**Related**
+
+* [Environment Variables](./variables-environment.md)
+* [Context Variables](./variables-context.md)