Project

Projects encompass everything that a cluster of gateways requires to run. Gateways, API Keys, and deployed environments can also be managed through the Project dashboard. As features advance, we’ll add more information here to better inform Project members.


Subscription

The Subscriptions page is where you manage access to your project. You can see and manage API keys (add, edit and remove one) but also plans (plans are not yet available). This is where you manage who can access your data.


Plan

Our vision is to allow you to create a plan with the best granularity that modern technologies have to offer. You’ll be able to create a plan that gives access to some fields while restricting access to others. Without creating a new API every time you want to offer more or less data access, you’ll be able to share exactly what you want with who you want.

For example, you could create a basic plan for 10$ per month that gives access to your product API without the prices of your products and then create a business plan for 200$ that requires manual approbation to gives access to the entire API (price included).

You could also decide that you want your business consumer to pay 0,01$ every time they request the price field. With a few clicks, you’ll be able to activate the field pricing and monetize any field you want.

Every plan can be customized on a per-customer basis so that when a partner asks you for more access, you don’t have to worry about giving too much access to other consumers on the same plan.

Moreover, choose what plans to expose in our marketplace, who can access the data, and how much they cost! Start with an existing community and open your data without any security constraints.


Temporary workflow

Because the marketplace and API creation are still in development, we provide only one way to give an API Key to a user.

  1. First, your consumer must give you his user’s id (he can obtain it on the profile page (https://wapixir.io/dashboard/profile).
  2. On the subscription page in a project, click on New and enter the user’s id in the field. Check the user. If the user’s id is valid, you should see his information (firstname, lastname and email)
  3. Finally, click on Add

Configuration

The configuration is what you deploy to a specific environment. In order to publish and apply changes, a new configuration must be created. Currently, it will automatically deploy it in the default environment called prod (see Environment below).

In the future, you’ll be able to choose which environment hosts which version.


Namespace

A namespace is a means to enable users to classify their data sources. For example, we could imagine that Wapitea-mart might want to organize their namespaces to reflect different types of content:

Wapitea-Mart (Project)

  • RetailStores (Namespace)
  • OnlineStores (Namespace)
  • PopupStores (Namespace)
  • Events (Namespace)

Environment

During the alpha, we will only support a default environment called prod. We are already working on features to expand this behavior. The functionality is mostly finished but still requires some work. If you really need this feature, send us an email and we’ll make sure to prioritize it accordingly.

Managing multiple environments is a feature that we believe any modern API manager absolutely should have. Following that thought, we want to offer users a very simple user experience where with a few clicks, you’ve deployed the version you want into the environment you want.

When you deploy a gateway, you will be able to set its environment. As soon as it starts up, it will contact the manager using a token (see below in gateway chapter) and an environment.


Gateway

We designed our API manager to be as flexible as possible. You can use our docker image of the to deploy the gateway anywhere you want (k8s, GCP, AWS, or on-premise), and pay as you go. Your data remains in your control within your infrastructure, so we’ll never have access to any of your information.

We highly recommend that you set up a log management solution such as the ELK stack (or any stack for your purpose). If you find that Wapixir is in need of development to better suit your needs, feel free to contact us so that we can take a look at solutions together.

Gateways are built on the Beam VM (erlang technology), which means they are highly available and fault-tolerant by design. Our choice in technology was made to offer the best solution and experience modern technology has to offer.

Gateways can be deployed easily by navigating to the Gateway view and selecting the Docker tab. Fill in the missing information for your configuration and copy/paste the docker run command from the browser to your terminal. Currently, gateways are automatically deployed to the prod environment. You’ll be able to define what environment to use for the gateway in the near future.

To debug misconfiguration, we recommend that you take a look at your docker logs. We have a feature planned to display errors in the manager, but currently don’t have a date for when it will be implemented. Do take note, however, that we’ll only expose errors in the Wapixir context and not yours as we want to provide you with the best data security.

Once your gateways are running, everything will work seamlessly so that every time you deploy a new configuration, gateways will recompile according to its runtime configuration. The only thing you have to worry about is to deploy new versions when we release them.

We’re working on a way to update gateways automatically when we release a new version. Of course, you’ll be able to opt-out of this option.

When a new configuration is deployed, any connection will be dropped; Gateways will take care of existing connections and continue to apply the old configuration until consumers receive their response.