Application setup

Introduction

Application setup takes 2 steps: - setting up general parameters: name, description, visibility... - setting up pricings capabilities: base license, usage-based (API endpoints, counters...)

All can be done within 5 minutes!

General settings

Name (internal)

For internal use only and immutable. A good choice would be app.yourdomain.com

Label

Application public name. It can be changed afterward (for a rebranding for instance)

Online

Put your app live. By default an app is offline. Once you have verified all configuration you can set it online. Should you want to stop new user on-boarding for your app, you just have to switch it offline here.

Private

When an app is online, it is shown on apifew's boutique: it is a public app. But you can choose to make it private: app description and pricings will only be available with an URL.

Apifew API secret key

It is the key you need to include in header 'Apifew-Key' when your back-end needs to request apifew's API.

Test mode

Test mode allows all interactions with your app with triggering live transaction (ie payment).
If an app is in test, it is automatically switched to private.

Delete

All configuration regarding an app will be delete.
Only possible for apps without active end-user (ie. active license).

Support

This minimal information will be provided to your users in emails.

API routes & endpoints

If your application offers an API, its endpoints (route + method) need to be defined here.
Later, when defining a pricing plan, each endpoint will be linked to a given endpoint subpricing.

Description

Information defined in this page is optional, but it should be used if you want to: - insert apifew's cardboxes describing your pricing plans on your website
- create automatically a comparaison table between different pricing plans (visible features)
- use assigned licenses as a way to grant authorizations to end-users
- describe the application in apifew's boutique
- give minimal due-diligence informations to potential subscribers

Description

Tagline

Short (only few words) sentence to wake your audience up!

Description

Information that will be shown on fastonboarding or on boutique.

Keywords / Tags

Sector

Features

Features are more structured description parameters.
They have two functions: create a common ground at app level for pricing comparaison, and define authorization scopes.

Descriptive features

Best is to imagine a comparative table for an app with 3 pricings.
We would declare 4 features, set them as visible, and for each choose an internal name, a label and a value type as show in the following table.
Then, later when defining each pricing, we would will the respective values shown here in Pricing1, Pricing2 and Pricing3 columns.

*fields are not shown to end-users
note that features are alphabetically ordered on internal name, so it's a good practice to prefix with number.

Authorization features

Features are also a way to define authorization scopes for each pricings.
By default features are visible, that means that they are included on pages where pricing plans are described.
But it is also possible switch off this parameter (uncheck visible) and make features information only available thru back-end API calls.
Additionnaly, it is possible to adjust features available for a given license (more details).

Subpricings

Subpricings are specific pricings applied to end-user usage: API requests, custom counters...

Endpoints subpricing

An endpoints subpricing allows to define buckets (for each currency) that will be applied to specific endpoints. It allows to define overruns, soft limits, hard limits depending on 3 variables: qty min, qty max and cost. see examples

Counters subpricing

Counters allow to gain in flexibility for usage-based invoicing. see examples

Pricing plans

A pricing plan can be viewed as a license schema: it defined a license charateristics and its related pricing.

private

If private, this pricing plan will not be available on fastonboarding nor boutique pages. But it is available via the direct url or via apifew's API.

online

If offline, no new purchase is available for this pricing plan. Licenses already sold will still remain active until expiry (if applicable).

frequency

A license can be perpetual (no time limit) or periodic (monthly or yearly). On the latter case, rolls are automatic.

migration

Each time a pricing plan is modified, its version number is increased by 1. It allows to change a pricing but leave current license owner with their current conditions (aka grand-father clause). If automigration is set, there is no such clause: at license expiry the new pricing will be applied (your users will automatically receive an email to inform them about such migration).

pricing

If an application is non-free, pricing buckets can be defined to setup volume discount. flat fee is mostly applicable for perpetual licenses subscription is applicable for periodic licenses, but a flat fee can also be set for the first period

trial & discount

A trial period can be set, in days. It is a good and widespread marketing practice to boost adoption. Switch from trial to normal license is automatic. Few days before the end of the trial, users will receive and email inform them the trial will soon be over, and invite them to setup a payment method.

A discount setup will soon be available.

endpoints

If an API is available, for each endpoints defined in General settings you can assign a specific subpricing.

counters

Custom counters can be defined and a corresponding subpricing assigned to it.
It allows to implement usage-based payment schemes.

Email templates

This area sets the template for emails received by end-users following various events (user creation, new license...) Default templates are defined but you can fine-tuned your communication by modifing such templates.

It is possible to provide variable names (between []) to be automatically replaced by given value when message is sent:

[APP_LABEL]

Application label (application public name as defined in General settings)

[APP_CUSTOMERS_EMAIL]

Customers support email

[APP_URL_DOCS]

Webpage URL for documentation

[LICENSE_LABEL]

License label

[LICENSE_OWNER]

License owner's email

[LICENSE_USER]

License user's email

[LICENSE_KEY]

License user's key

[OWNER_MAIL_KEY]

Token needed to validate email (when user will setup/change his password)

[ENROLL_DT]

License start date (equivalent to trial start date if applicable)

[TRIAL_END_DT]

Trial period end date

[LICENSE_END_DT]

License subscription expiry date

[USER_NAME_FIRST]

User's first name (defaults to email if first name not available)

Multi-language

All application information can be setup in different languages. If a language is setup and matches end-user prefered language, it will be selected, otherwise English is default language.

Alert & reports

SSL cerficates

Just add domain or subdomain to have information and alerts related to certificate expiry.

Uptime hooks

Define API routes to check your application uptime. An expected response can be defined to fine-tune the check. Currently request use only POST method.

Results are available in Monitoring section.