{"_id":"5703c7f2903e330e002d8716","parentDoc":null,"version":{"_id":"5703c7f2903e330e002d8703","__v":4,"hasDoc":true,"hasReference":true,"project":"56682f6c1fb5701900f893a0","createdAt":"2016-04-05T14:13:06.422Z","releaseDate":"2016-04-05T14:13:06.422Z","categories":["5703c7f2903e330e002d8704","5703c7f2903e330e002d8705","5703c7f2903e330e002d8706","5703c7f2903e330e002d8707","5703c7f2903e330e002d8708","5703c7f2903e330e002d8709","5703c7f2903e330e002d870a","5703c7f2903e330e002d870b","5703c7f2903e330e002d870c","573d96148ca48f320093ed5b","573dd2e38cf1492400bba6e0","57a9cc1f5b1ace0e00de743e"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"2.0.0","version":"2"},"__v":1,"user":"56684a10ee1dbf0d008f621d","category":{"_id":"5703c7f2903e330e002d8707","project":"56682f6c1fb5701900f893a0","version":"5703c7f2903e330e002d8703","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-12-15T15:54:21.948Z","from_sync":false,"order":3,"slug":"enterprise-documentation","title":"Enterprise Documentation"},"project":"56682f6c1fb5701900f893a0","updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-01-21T12:18:17.439Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":2,"body":"[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Brands\"\n}\n[/block]\nA brand represents the configuration of a partner within the BaseKit application. Users created within a specific brand will belong to that brand, and are securely partitioned from all other brands.\n\nYou will be provided with a brand reference. This is a unique number that is used to identify your brand. This may be required for some API calls and will always be a parameter named brandRef. Your API credentials are locked to your brand, so you can’t access users in other brands, and other brands can’t access your users.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"body\": \"Users are sometimes referred to as 'account holders' and the two terms may be used interchangeably.\",\n  \"title\": \"Note\"\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Packages\"\n}\n[/block]\nAll users have a package that represents the features and capabilities that are available for them to use within their account. For example, a package may designate the number of sites they are allowed to create, the templates they are allowed to access, the storage limit they have available, etc.\n\n* A typical brand will have one free package and three premium packages. These packages may only be used by users within the corresponding brand.\n* The free package will typically be designated as the brand’s default package. The default package is automatically assigned to new users created within this brand.\n* Users can only have one package at any given time. If a new package is given to the user then the existing package is automatically expired.\n* All packages have a billing period that indicates how regularly the user has decided to pay for their subscription. Typically this will be either monthly or annually.\n\n**Package models**\n\nEvery partner integration will choose one of the following package models. Which one to choose will depend on the marketing and commercialisation strategy for the project. It is recommended that all partners implement the Freemium model, which has been shown to give the best results.\n\n**Trial**\n\nA trial package provides users with access to a complete set of features for a limited period of time. The period of time is set as a number of days and is typically between 7 and 30 days.\n\nEach trial package will mirror a paid package, with the only difference being that it is time limited. If the user decides to upgrade, they will move to the corresponding paid version of the package.\n\nIf the user does not subscribe to a paid package during the trial period, they will be moved back to the brand’s default package. This will usually mean that they lose some of the premium features that they have had access to during the trial. For example, they may no longer be able to publish their site without paying for the service.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Billing cycles\"\n}\n[/block]\nEvery paid package is assigned to a billing cycle that represents how frequently the user is making subscription payments for the service.\n\nThe frequency is specified as a number of months. For example, a billing frequency of 3 means that the package subscription payment is made by the user every 3 months. The typical billing frequencies are 1 for monthly and 12 for annual, but any number may be used.\n\nIt is critical that you indicate the correct billing frequency in all API calls. This is used to tell the provisioning engine how to update the user’s package, and also used to synchronise billing reports.","excerpt":"","slug":"brands-and-packages","type":"basic","title":"Brands and Packages"}

Brands and Packages


[block:api-header] { "type": "basic", "title": "Brands" } [/block] A brand represents the configuration of a partner within the BaseKit application. Users created within a specific brand will belong to that brand, and are securely partitioned from all other brands. You will be provided with a brand reference. This is a unique number that is used to identify your brand. This may be required for some API calls and will always be a parameter named brandRef. Your API credentials are locked to your brand, so you can’t access users in other brands, and other brands can’t access your users. [block:callout] { "type": "info", "body": "Users are sometimes referred to as 'account holders' and the two terms may be used interchangeably.", "title": "Note" } [/block] [block:api-header] { "type": "basic", "title": "Packages" } [/block] All users have a package that represents the features and capabilities that are available for them to use within their account. For example, a package may designate the number of sites they are allowed to create, the templates they are allowed to access, the storage limit they have available, etc. * A typical brand will have one free package and three premium packages. These packages may only be used by users within the corresponding brand. * The free package will typically be designated as the brand’s default package. The default package is automatically assigned to new users created within this brand. * Users can only have one package at any given time. If a new package is given to the user then the existing package is automatically expired. * All packages have a billing period that indicates how regularly the user has decided to pay for their subscription. Typically this will be either monthly or annually. **Package models** Every partner integration will choose one of the following package models. Which one to choose will depend on the marketing and commercialisation strategy for the project. It is recommended that all partners implement the Freemium model, which has been shown to give the best results. **Trial** A trial package provides users with access to a complete set of features for a limited period of time. The period of time is set as a number of days and is typically between 7 and 30 days. Each trial package will mirror a paid package, with the only difference being that it is time limited. If the user decides to upgrade, they will move to the corresponding paid version of the package. If the user does not subscribe to a paid package during the trial period, they will be moved back to the brand’s default package. This will usually mean that they lose some of the premium features that they have had access to during the trial. For example, they may no longer be able to publish their site without paying for the service. [block:api-header] { "type": "basic", "title": "Billing cycles" } [/block] Every paid package is assigned to a billing cycle that represents how frequently the user is making subscription payments for the service. The frequency is specified as a number of months. For example, a billing frequency of 3 means that the package subscription payment is made by the user every 3 months. The typical billing frequencies are 1 for monthly and 12 for annual, but any number may be used. It is critical that you indicate the correct billing frequency in all API calls. This is used to tell the provisioning engine how to update the user’s package, and also used to synchronise billing reports.