The short version
A draft is not yet a published page. Wrytze connects brand-aware drafting, human editorial review and a content interface that another website can render in its own design.
Conceptual brand illustration
Product, owner and current status
A Datahase-owned product with a public web-app entry point and developer documentation. The API changelog records its v1.0.0 release in February 2026. This study reviews public product and API documentation; it does not report an authenticated editor session or API integration test.
Public sources checked on
The everyday problem
For a content team, writing is one part of the job. Someone must decide whether a draft is suitable, resolve edits, choose a publication time and ensure the external website receives the right content. A generation button alone does not describe that complete workflow.
The Wrytze homepage describes website context, topic selection, draft generation, block editing, team approval and scheduling or immediate publication. The developer documentation then describes fetching published posts. This study follows that boundary between the editorial workspace and the consuming site, without treating generated text as verified research or claiming search-ranking improvements.
Who does what
- The editor shapes the draft
- The editor connects website context, chooses a topic and uses the block editor to revise the result. Generation supplies material for inspection, not an exemption from checking factual claims, source support or publication rights.
- The reviewer makes a publication decision
- The homepage describes review requests, comments, approval, due dates and reminders. This is a documented review checkpoint, not evidence that every published post received a particular level of human scrutiny.
- The website developer renders published content
- An external site uses the REST API or TypeScript SDK to retrieve content. The developer owns presentation, safe rendering, pagination, errors and application-side caching; the API does not automatically implement those choices for every consumer.
An illustrative workflow
Connect context and select a topic
Add the website so the product can analyze brand context, then select a topic. The resulting draft still needs an editor to check meaning, accuracy and fit for the intended audience.
Edit and request review
Revise the draft in blocks and submit it for team review. Comments and approval belong before the decision to schedule or publish; a generated draft is not presented here as an automatically approved article.
Publish for a specific website
Schedule publication or publish directly through the documented workflow. Keep the target website explicit, because the API documentation says slugs are unique within a website rather than globally.
Fetch the summary, then the article
The consuming site lists published posts with pagination and filters, then fetches a detail record when it needs full HTML. The renderer applies its own page structure, metadata and handling for unavailable content.
Three product decisions
- Keep a human checkpoint between generation and publication
- The homepage pairs AI drafting with block editing and team approval. Our architectural reading is that these are distinct responsibilities: a usable draft and an authorized publication are different states. The public material documents the workflow, but does not establish approval quality, throughput or measured time savings.
- Separate browsing data from article content
- The Blogs reference says list responses omit contentHtml, while ID and slug detail responses include it. This gives a consumer a concrete distinction between a card/list model and a full article model. Reduced payloads are a plausible rationale, not a documented benchmark or a claim about why the original implementation was chosen.
- Keep organization authority separate from website selection
- Authentication docs describe organization-scoped API keys. A key can read published content across that organization’s websites, while website_id selects a website and is required for slug lookup. A website filter is therefore not described here as a separate authorization credential or a guarantee of isolation within an organization.
What the product does
The public API exposes published-blog lists and detail lookup by ID or website-specific slug. Lists support page/limit, category, tag, title search and website filters. A consuming site needs to follow pagination rather than assume the first response is the entire catalog. The detail response provides full HTML plus publication and presentation fields.
The SDK page describes a TypeScript client built on native fetch, structured WrytzeError responses and a RateLimitError with retryAfter. Those are documented integration behaviors. They do not mean a renderer can ignore missing content, invalid credentials or rate limits, and this study makes no successful authenticated-call claim.
Cache freshness is part of the publishing handoff
The February 2026 changelog records Redis caching through Upstash, with five-minute list and fifteen-minute single-resource lifetimes. These are documented API cache settings, not measured end-to-end freshness on a website. A consuming framework or CDN can add another cache layer.
Our integration analysis is to test an edit, publication and unavailable post across both list and detail views, with explicit expectations for each layer. Different lifetimes can leave a card and article temporarily reflecting different observations. That is a validation question, not a report of a bug or a tested invalidation guarantee.
Implementation boundaries worth preserving
The authentication page says API keys belong on the server and gives access to the organization’s published content. A consumer should not place a key in browser code merely because the output is public. Access scope, safe HTML handling and secret management need an application-specific review.
This walkthrough does not infer undocumented write endpoints, webhook behavior, approval enforcement internals or enterprise security certification. Public React component counts differ between documentation pages, so no count is used. Architectural interpretations above are labeled analysis rather than statements of original developer intent.
Scope and boundaries
Wrytze’s public site offers a web product and its docs describe the publishing API and SDK. These are first-party documented capabilities, not independently tested editor behavior, generated-content accuracy or an uptime assessment. No SEO ranking, approval percentage, team count, publishing-speed or customer outcome is asserted. The existing product illustration is conceptual brand artwork, not an authenticated application screenshot.
Inspect the sources
- Wrytze product workflow
Website context, generation, block editing, review and scheduling/publishing.
- Published-blog API
Pagination/filters, website-specific slug lookup and list/detail HTML distinction.
- API authentication and scope
Organization-scoped keys, server-side usage and documented error/rate-limit boundaries.
- TypeScript SDK
Native fetch client, typed data and structured errors; no component counts asserted.
- API release and cache record
February 2026 v1.0.0, Upstash Redis and distinct list/detail cache lifetimes.