Sub-account structure

The URL structure of your platform is the main driver for how your sub-accounts should be structured, and more specifically, what the site_uri field should look like.

See below the different types of site structures AFP supports:

Use case	URL structure	Value of site_uri field in API	Value of request_id field in API
Subdomains	Root: https://littlepig.example.com Content: https://littlepig.example.com/food.html	littlepig.example.com	littlepig (or an internal unique ID associated with the user)
Sub folders	Root: https://example.com/littlepig or https://example.com/sites/littlepig Content: https://example.com/littlepig/food.html or https://example.com/sites/littlepig/food.html	example.com/littlepig or example.com/sites/littlepig	littlepig (or an internal unique ID associated with the user)
Combination of subdomains and sub folders	Root: https://sites.example.com/sites/littlepig Content: https://sites.example.com/sites/littlepig/food.html	sites.example.com/sites/littlepig	littlepig (or an internal unique ID associated with the user)
Individual URLs	Root (or creator profile): https://example.com/user/littlepig Content: https://example.com/nf8ag4n	example.com/user/littlepig Important: for this use case, we additionally require the "Platform author" meta tag to be present on all pages.	littlepig (or an internal unique ID associated with the user)

How to create sub-accounts if your users have multiple properties on your platform

Sub-accounts are intended to be mapped to users. If a single user can own more than one property (i.e. a subdomain or folder, or profile pages) on your platform, the sub-account mapped to that user must contain all of the properties associated with that user.

The value for "request_id" in this scenario

If your platform allows multiple properties per user, we recommend using an internal unique identifier for the user in the request_id field. In the future, the get account API method will allow getting accounts based on the value of this field.