Skip to main content

PressKit Known Limitations (v1)

Last updated: February 23, 2026 (America/Los_Angeles)

Applies to version/build: PressKit docs v1 baseline (released February 16, 2026; see changelog for updates)

This page documents current PressKit v1 boundaries to reduce rollout surprises and support churn.

These limits are intentional for predictable operator behavior.

Boundaries (quick read)

PressKit does:

  • Manage one EPK profile per HubSpot Company record.
  • Support draft and published states (with portal-level auto-publish as an irreversible posture).
  • Publish public pages using the portal-scoped route: /epk/:portalId/:publicId.
  • Enforce media and publish validation guardrails (required fields, HTTPS video URLs, media limits, MIME checks).

PressKit does not:

  • Provide multiple public profiles per Company record.
  • Provide per-company theming/layout customization in v1.
  • Provide password-protected public links in v1.
  • Include a rich engagement analytics UI in v1.

Known limitations

LimitationCurrent behaviorWhy this boundary existsIf you need this today
Object coveragePressKit is Company-record focused.Product scope is one EPK per HubSpot Company record.Use one canonical Company record per published EPK profile.
Profile modelOne EPK profile is managed per (portalId, companyId).Keeps authoring and publish state deterministic.Use internal process controls for any multi-profile variations.
Public visibility postureDefault mode (auto-publish OFF): only published records are publicly accessible; draft and missing records resolve as not found. Auto-publish mode (irreversible portal setting): public pages are accessible by default, including empty profiles; per-record publish toggling may be disabled.Supports conservative defaults while allowing always-on visibility when required.Decide your portal posture before rollout. Do not rely on draft privacy if auto-publish is enabled.
Public route contractPublic route is /epk/:portalId/:publicId; legacy /epk/:publicId returns a 404 deprecation response.Enforces explicit portal scoping and stable route behavior.Update old links to the portal-scoped URL format.
Publish requirementsWhen per-record publishing is enabled (default mode), Artist Name and Description are required before publish.Ensures minimum public page completeness in publish-gated portals.Define an internal pre-publish checklist for required fields.
Media validationMedia guardrails enforce limits and MIME checks; video links must use HTTPS.Reduces malformed media failures and unsafe URL handling.Pre-validate file types and link formats before upload.
Theming/layout customizationPer-company theming/layout customization is not supported in v1.Prioritizes stable baseline output over design variants.Keep brand variations in source content rather than per-company page themes.
Access controls on public pagesPassword-protected public links are not supported in v1.Keeps public route contract simple and deterministic for v1.Share links through your own access-controlled channels.
Analytics UIRich engagement analytics UI is not included in v1.Current focus is authoring, publishing, and route reliability.Use your existing analytics stack around public link distribution.

Support intake checklist

If you hit a boundary and need help confirming whether it’s “expected” vs “unexpected,” send support:

  • Portal ID
  • Company record URL
  • Which limitation you hit (copy/paste the table row name)
  • Public URL tested (if relevant)
  • Expected behavior vs actual behavior
  • Timestamp with timezone
  • Screenshots (and any visible requestId / error code)