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.