Wallkit at a glance
Wallkit connects your publication, its readers and the rules for access to content. Here is how those pieces fit together.
Follow one publisher example
Imagine a publisher called City Journal. Its website is the publication people read. In Wallkit, that publication's configured context is a resource: its content, subscriptions and settings belong to that resource.
City Journal creates a Plan for its reporting. The Plan groups subscriptions and carries access rules. It has two subscriptions for readers to choose from: monthly and annual.
Alex is a reader with a record in City Journal's audience. When Alex has the monthly subscription, Alex's membership links that reader to that subscription.
City Journal also has content records for its articles. To decide whether Alex can read a particular article, the application uses Wallkit's content-access decision, based on the access rules and reader context.
Keep the relationships clear
| Piece | In the City Journal example |
|---|---|
| Publication / resource | The website being managed and its Wallkit configuration. |
| Reader | Alex's identity in the publication's audience. |
| Plan | The group of subscriptions and its access rules. |
| Subscription | The monthly or annual option. |
| Membership | Alex's relationship with the monthly subscription. |
| Content record | The article being identified. |
| Content access | The decision about whether Alex can read that article. |
A transaction records payment activity separately. A reader record or a recorded payment does not, on its own, mean every article is accessible.
What to do next
Use Find your way around Wallkit to locate the area for your task. If you are preparing a new setup, read Before you set up your publication.
For implementation details, use the Developer Central business map and content-access guide.