Prepare your website integration
Give your integration owner one brief that connects your publication, readers, articles and access goals. Start after you have confirmed the basic setup prerequisites.
The publisher supplies the intended experience and agreed content-access decisions. The integration owner works out how the website will identify the reader and article, request an access decision and deliver the permitted content.
Build the brief together
Record these details before implementation:
- Publication and site: the intended Wallkit publication, website address, CMS or publishing system, and which site the work covers.
- Reader sign-in: how readers sign in today, whether accounts already exist, and who owns that setup. The owner needs this context to choose the matching identity flow.
- Content identity: which stable article identifier the website will supply, plus the categories, tags and authors needed by the agreed access rules. Ask the owner to explain how these map from the CMS.
- Plans and access goals: the agreed Plans, subscription choices and which content each should make available. Include the intended experience for a guest and a signed-in reader.
- Owners and expected result: who approves publication decisions, who implements the integration, and what readers should see when access is allowed or denied.
If a detail is undecided, name the person who must resolve it. A clear question is more useful than an assumed setting.
City Journal example brief
Copy this structure and replace the fictional details with your agreed setup:
Publication: City Journal
Website: https://example.com
Publishing system: Our current CMS; the web team will name its version and confirm the integration path before implementation.
Reader sign-in: Existing email/password accounts on the website. The web team owns sign-in and will agree how these readers are identified in Wallkit.
Content: Keep the CMS article ID stable. The web team will confirm its mapping to Wallkit. Send the agreed news/reporting categories and article tags and authors consistently.
Access goal: Short news updates for guests; reporting for readers with a subscription to the Reporting Plan. The publisher will approve the matching Plan rules and monthly/annual choices.
Publisher decision owner: City Journal publishing lead.
Implementation owner: City Journal web team.
Reader result: Allowed readers see the permitted article. Denied readers see an access message and the agreed sign-in or subscription route. The web team must protect restricted article content as well as manage the page display.
Open question: Confirm the invitation destination and how our site handles an invited reader before using invitation links.
This is a handoff example. The integration owner must confirm the technical path for your actual site and sign-in setup.
Share the matching technical guides
| Work to discuss with the owner | Developer Central guide |
|---|---|
| Identify an article, register it when needed, check access and handle allowed or denied content. | Register content, check access, and show or lock it |
| Connect an ordinary member sign-in to an article access decision. | From ordinary sign-in to article access |
| Choose a guide for the publication's existing identity or integration setup. | Getting started: Choose a path |
Signing in identifies a reader; the article still needs its own access decision. The owner also needs to handle protected delivery, so restricted article content is available only when permitted.
Your next step
Review the brief with the integration owner and resolve the open decisions. Keep publication settings, Plans and access rules and content classification aligned with that brief as the work proceeds.