Chartbeat organises permissions by site and account role. Use this section to track how the collaborator gains access, how roles evolve, and how to sunset credentials when projects complete.
How Chartbeat Structures Access
Chartbeat uses a straightforward role-based permissions model combined with site-level access controls. Understanding both components is essential for secure collaborator management.
Account-Level Roles
Chartbeat provides two primary account roles with distinct capabilities.
Administrator:
- Full control over account configuration and settings
- Manage user accounts (add, edit, remove users)
- Configure sites, domains, and tracking settings
- Access billing and subscription management
- Create and manage API credentials
- Configure integrations (Slack, webhooks, data exports)
- Set up and modify alerting rules
- Full access to all sites and dashboards
User:
- View-only access to assigned sites and dashboards
- Cannot modify account settings or configurations
- Cannot add or remove other users
- Cannot access billing or API credentials
- Can create personal alerts and bookmarks
- Can export dashboard data (CSV, images)
- Ideal role for analysts and collaborators focused on insights
Key distinction: Chartbeat doesn't offer granular permissions between these two roles. Users are either Administrators with full control or Users with read-only dashboard access. This binary structure requires careful consideration when granting collaborator access.
Site and Group Access
Beyond the account role, access is controlled by which sites a user can view.
Site-specific access:
- Each user can be granted access to specific sites or site groups
- Sites represent individual properties (websites, mobile apps, or sections)
- Access can be scoped to production sites vs. staging/development domains
- Users only see data from sites they're explicitly granted access to
Site Groups:
- Organize multiple sites into logical collections
- Grant access to entire groups rather than individual sites
- Useful for brand families, regional properties, or departmental sites
- Groups simplify collaborator access when managing multiple properties
Access patterns:
- All Sites: User sees all current and future sites (risky for collaborators)
- Specific Sites: User sees only named sites (recommended for collaborators)
- Site Groups: User sees all sites within defined groups (good for multi-property engagements)
Dashboard and Publishing Access
Chartbeat offers distinct dashboard products with different access patterns.
Publishing (Editorial) Dashboard:
- Real-time audience analytics for content teams
- Shows concurrent visitors, top pages, traffic sources
- Headline testing and engagement metrics
- Social media performance tracking
Head's Up Display:
- Wall-mounted or kiosk displays for newsrooms
- Public-facing real-time metrics
- Reduced functionality, focused on visibility
Video Dashboard:
- Specialized analytics for video content
- Engagement, completion rates, and audience retention
- Requires separate entitlement and site configuration
For collaborators: Confirm which dashboard products are in scope. Access is typically granted at the site level, but some features (video analytics) require additional configuration.
API and Data Access
Chartbeat provides API access for programmatic data retrieval and integrations.
API Key Types:
- Account-level API keys: Tied to a user account, inherit that user's site access
- Read-only: Most common for collaborator integrations pulling data for reporting
- Write access: Rare, used for updating configurations programmatically (avoid for collaborators)
API capabilities:
- Pull real-time traffic data
- Export historical metrics
- Retrieve top pages and traffic sources
- Access engagement and recirculation data
Data exports:
- CSV downloads from dashboards (available to all Users)
- API-based exports (requires API key)
- Data warehouse integrations (enterprise feature, requires Administrator role to configure)
Account Role Permissions Matrix
| Capability | Administrator | User |
|---|---|---|
| Account Management | ||
| Manage user accounts | ✓ | - |
| Configure SSO/SAML | ✓ | - |
| Access billing and subscription | ✓ | - |
| View account audit logs | ✓ | - |
| Site Configuration | ||
| Add/edit/delete sites | ✓ | - |
| Configure tracking code | ✓ | - |
| Manage site groups | ✓ | - |
| Configure domain settings | ✓ | - |
| Integrations and API | ||
| Create/revoke API keys | ✓ | - |
| Configure integrations (Slack, webhooks) | ✓ | - |
| Set up data warehouse exports | ✓ | - |
| Analytics and Dashboards | ||
| View real-time dashboards | ✓ | ✓ |
| Access historical data | ✓ | ✓ |
| Export data (CSV, images) | ✓ | ✓ |
| Create personal bookmarks | ✓ | ✓ |
| Alerting | ||
| Create global alert rules | ✓ | - |
| Create personal alerts | ✓ | ✓ |
| Manage team notifications | ✓ | - |
Account Types and Capabilities
Account Administrators
Administrators have full control over the Chartbeat account and all sites.
Use Administrator role for:
- IT leaders responsible for Chartbeat platform governance
- Primary client contacts managing the account
- Implementation consultants configuring tracking (temporarily, then downgrade)
- Senior analytics leads managing multi-site deployments
Grant to collaborators when:
- Collaborator is implementing Chartbeat tracking and needs to configure sites
- Statement of work explicitly includes platform administration
- Collaborator manages API integrations requiring credential creation
- Collaborator handles Slack or webhook integrations for the client team
Avoid granting to collaborators when:
- Work is limited to analysis and reporting
- Implementation is complete and only monitoring is required
- Billing visibility should be restricted
- Collaborator doesn't need to add/remove other users
Security considerations:
- Administrators can modify tracking configurations that affect data collection
- Can create API keys with access to all sites (even those outside collaborator scope)
- Can access billing and contract information
- Limit to 2-3 people maximum; use User role for most collaborator team members
Standard Users (Read-Only)
Users have view-only access to dashboards for assigned sites.
Use User role for:
- Collaborator analysts creating insights and reports
- Junior team members learning the platform
- Stakeholders who need visibility without configuration rights
- Collaborators after implementation phase completes
Capabilities within assigned sites:
- View real-time traffic and engagement metrics
- Access historical reporting (date range depends on subscription tier)
- Create and manage personal alerts
- Export dashboard data as CSV or images
- Bookmark favorite views and dashboards
Limitations:
- Cannot modify site configurations or tracking settings
- Cannot add/remove other users or change permissions
- Cannot create or revoke API keys
- Cannot access sites they haven't been explicitly granted access to
- Cannot configure integrations or data exports
Best practice for collaborators: Start with User role. Elevate to Administrator only when specific configuration tasks require it, then downgrade back to User when complete.
Service Accounts and API Keys
For programmatic access, Chartbeat uses API keys tied to user accounts.
Service account pattern:
- Create a dedicated Chartbeat user for API integrations (e.g., chartbeat-api@client.com)
- Grant the service account User role with access to required sites only
- Generate API key under that account
- Store API key in secure vault (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault)
- Document which integrations use the key for offboarding
API key characteristics:
- API keys inherit the site access of the user account they're created under
- Keys don't expire automatically (manual rotation required)
- Revoking a key immediately breaks integrations using it
- Each user can have multiple API keys for different integrations
For collaborator integrations:
- Provide API keys scoped to only the sites in the engagement scope
- Rotate keys annually or when collaborator engagement ends
- Monitor API usage through your own application logs (Chartbeat doesn't provide detailed API audit logs)
- Document which keys belong to collaborator integrations for cleanup
Access Control and Data Governance
Site-Based Data Segmentation
Chartbeat isolates data at the site level, making site access the primary data governance control.
Single-site strategy:
- One Chartbeat site per web property
- Grant collaborators access only to sites within engagement scope
- Clear boundaries, easy to audit
- May result in many sites to manage individually
Multi-site grouping:
- Use site groups to bundle related properties
- Grant collaborators access to entire groups
- Easier management for multi-brand engagements
- Risk: Collaborator may see more sites than strictly necessary if group is too broad
Production vs. staging:
- Configure separate Chartbeat sites for staging/development domains
- Grant collaborators Administrator access to staging sites for testing
- Restrict to User role on production sites to prevent accidental changes
- Clearly label sites (e.g., "Client Production", "Client Staging") to avoid confusion
Recommendation for collaborators: Grant access to the minimum set of sites required for the engagement. Review quarterly and remove access to sites no longer in scope.
Domain and Subdomain Scoping
Chartbeat tracks based on configured domains and can filter by subdomain.
Domain configuration:
- Each site has a primary domain (e.g., client.com)
- Can include subdomains (blog.client.com, shop.client.com)
- Dashboard filtering allows viewing specific subdomains
- Access control operates at the site level, not subdomain level
For collaborators managing subsets:
- If the collaborator should only see blog.client.com data, create a separate Chartbeat site for that subdomain
- Don't rely on dashboard filtering for access control (Users with site access can view all domains/subdomains in that site)
- Document in your access tracker which domains/subdomains the collaborator is authorized to view
Restricting Sensitive Data
Chartbeat doesn't offer granular metric/dimension hiding (unlike some analytics platforms).
Data exposed to all Users with site access:
- Full URL paths (may contain query parameters with PII or sensitive data)
- Referral sources and social links
- Geographic data (country, region, city)
- Device and browser information
- Traffic volumes and engagement metrics
Mitigation strategies:
- Use site segmentation to isolate sensitive properties
- Configure Chartbeat tracking to exclude query parameters containing PII
- Review URL structures with legal/privacy teams before granting collaborator access
- Document data exposure in Data Processing Agreements
No PII in Chartbeat: As a best practice, don't send personally identifiable information (email, name, phone) to Chartbeat in URL parameters or custom data layers. Chartbeat is designed for aggregate content analytics, not individual user tracking.
Team and Organization Structure
Single Account Model
Most organizations use one Chartbeat account for all properties.
Characteristics:
- Centralized billing and user management
- Shared user pool across all sites
- Easier to grant collaborators access to multiple sites
- All sites visible to Administrators
For collaborator management:
- Create collaborator users within your primary account
- Use site access controls to limit visibility
- Simpler onboarding (one set of credentials)
- Risk: Collaborators appear in same user list as employees (document clearly)
Multi-Account Model (Rare)
Some enterprises maintain separate Chartbeat accounts for different brands or regions.
When to use:
- Acquired companies with pre-existing Chartbeat accounts
- Different legal entities requiring complete data separation
- Billing must be split across cost centers
For collaborators:
- May need separate accounts in each Chartbeat instance
- No single sign-on across accounts
- More complex to manage and audit
- Document which account(s) the collaborator has access to
SSO and SAML Integration
Chartbeat supports SAML-based single sign-on for enterprise accounts.
Supported identity providers:
- Okta
- Microsoft Azure AD / Entra ID
- Google Workspace
- OneLogin
- Any SAML 2.0 compliant provider
SSO benefits:
- Centralized authentication through your IdP
- MFA enforced at IdP level
- Automatic deprovisioning when removed from IdP
- Aligns with corporate joiner/mover/leaver processes
Implementation:
- Configure Chartbeat as a SAML application in your IdP
- Provide Chartbeat support with your IdP metadata
- Chartbeat configures SSO for your account
- Test with non-production users
- Enable SSO enforcement (optional) to disable password logins
For collaborators:
- Collaborators authenticate via your corporate SSO
- Add collaborators to IdP group granting Chartbeat access
- Map IdP attributes (email, name) to Chartbeat user profiles
- Remove from IdP group to revoke Chartbeat access automatically
Limitation: SCIM (automated provisioning) is not widely supported by Chartbeat. User accounts may still need manual creation even with SSO enabled.
API Access and Authentication
API Key Management
Chartbeat API keys provide programmatic access to real-time and historical data.
Creating API keys:
- Log in as an Administrator
- Navigate to Account Settings → API Keys
- Click "Create New Key"
- Assign the key a descriptive name (e.g., "Collaborator ETL Integration")
- Associate the key with a user account (determines site access)
- Copy the key immediately (only shown once)
API key scope:
- API keys inherit site access from the associated user account
- If user has access to 5 sites, API can query those 5 sites
- Changing user's site access automatically updates API key scope
- Revoking key is immediate; integrations break instantly
For collaborator integrations:
- Create API keys under collaborator service accounts, not your employee accounts
- Name keys clearly to indicate they belong to collaborator integrations
- Grant minimum site access required
- Document key creation date and purpose in your access tracker
API Authentication Methods
Header-based authentication (recommended):
GET /live/toppages/v3/
Host: api.chartbeat.com
Authorization: Bearer YOUR_API_KEY
Query parameter authentication (legacy):
GET /live/toppages/v3/?apikey=YOUR_API_KEY
Host: api.chartbeat.com
Best practice: Use header-based authentication to avoid logging API keys in server access logs or browser history.
API Rate Limits
Chartbeat enforces rate limits to protect platform stability.
Standard limits:
- 50 requests per minute per API key
- Burst allowance of 100 requests if under sustained limit
- Historical API: 10 requests per minute (more expensive queries)
For collaborator integrations:
- Implement exponential backoff on 429 (rate limit) errors
- Cache responses when appropriate (e.g., historical data unlikely to change)
- Spread requests over time rather than bursting
- Contact Chartbeat support if higher limits are required (available for enterprise accounts)
Monitoring:
- Log API responses for rate limit headers
- Alert on repeated 429 errors (indicates integration needs optimization)
- Review API usage monthly to ensure collaborator integrations remain efficient
Data Warehouse and Export APIs
Chartbeat offers data warehouse integrations for historical data exports.
Supported warehouses:
- Google BigQuery
- Amazon Redshift
- Snowflake
- Custom webhook endpoints
Configuration requirements:
- Administrator role required to set up warehouse integrations
- Scheduled exports (hourly, daily) or real-time streams
- Data includes page views, engagement metrics, traffic sources
For collaborators:
- If collaborator needs bulk historical data, configure warehouse export under client-controlled credentials
- Don't grant collaborators direct warehouse configuration access unless explicitly in scope
- Monitor export volumes for cost management
- Document warehouse access in Data Processing Agreement
Audit Logging and Monitoring
Account Audit Logs
Chartbeat provides basic audit logging for account-level changes.
Events logged:
- User account creation, modification, deletion
- Site additions and configuration changes
- API key creation and revocation
- SSO configuration updates
- Integration configuration changes
Accessing audit logs:
- Log in as an Administrator
- Navigate to Account Settings → Audit Log
- Filter by date range, user, or event type
- Export to CSV for archival
Retention:
- Chartbeat retains audit logs for 90 days in the UI (varies by plan tier)
- Export logs monthly for long-term compliance storage
- Include in SOC 2, ISO 27001, or GDPR documentation
What's NOT logged:
- User dashboard views or data access (Chartbeat focuses on content analytics, not user behavior tracking)
- API calls (only key creation/revocation, not individual API requests)
- CSV export events
Monitoring Collaborator Activity
Unlike some analytics platforms, Chartbeat doesn't provide detailed user activity tracking.
What you can monitor:
- Audit log for configuration changes made by collaborator accounts
- API usage patterns (requires logging in your application layer, not Chartbeat)
- Last login date (visible in user management, but not detailed session logs)
Workarounds for better visibility:
- Require collaborators to document configuration changes in tickets
- Use separate Administrator accounts for different collaborators to track changes
- Implement logging in your own applications that call Chartbeat APIs
- Review audit logs monthly for unexpected changes
Data Export Tracking
Users can export dashboard data (CSV, images), but these exports aren't logged by Chartbeat.
Governance approach:
- Rely on contractual Data Processing Agreements to govern exports
- Educate collaborators on acceptable use of exported data
- If strict export tracking is required, consider this a platform limitation
- For sensitive data, limit collaborator role to User and control which sites they access
Access Requests at a Glance
- Add User Access covers inviting our shared account and mapping it to the correct sites.
- Update Access & Roles explains how to toggle analyst vs. admin rights or adjust site groups.
- Remove User Access details how to revoke access and capture audit evidence.
Add, Update, Remove at a Glance
- Add: Invite the collaborator, set the account role, then attach the precise list of sites or groups relevant to the project timeline.
- Update: Switch between Administrator/User when responsibilities shift, or expand the site list as new sections launch. Reconfirm MFA or SSO status after role changes.
- Remove: Detach the user from all sites, downgrade to User if a record must remain, then remove entirely once exports and alerts have been reassigned.
Platform Notes and Practical Steps
- Site lists are the real scope control: Chartbeat access lives at the site and group level. When adding or updating a user, spell out exactly which newsroom sections, marketing sites, or staging properties belong, and add the expiration date in the ticket.
- Real-time alerts depend on roles: Admins can create/edit alerts that hit Slack or email. If the collaborator only monitors dashboards, keep the role at User to avoid accidental alert floods.
- API keys ≠ UI roles: API credentials stay valid even if you change a UI role. Track which keys belong to the collaborator and rotate them when you downgrade or remove access.
- Evidence to keep: Export the User Audit list and capture a screenshot of the Users page showing the collaborator's role and site group mapping after every change.
Roles to Maintain
- Account Administrators who can configure sites, API keys, and billing. Keep this limited to client owners plus one the collaborator's contact if the collaborator supports configuration.
- Site-Level Users with dashboard access only. Assign this when the collaborator is focused on reporting support rather than configuration.
- API or Data Pipeline Accounts if Chartbeat data is exported downstream; store credentials securely and rotate them annually.
Best Practices for Team Access Management
Start with User Role
Most collaborators should begin with User (read-only) role.
Decision framework:
- Review statement of work to identify tasks
- If tasks include "configure tracking," "set up sites," or "create integrations" → Administrator (temporarily)
- If tasks include "analyze performance," "create reports," "monitor metrics" → User
- Default to User; elevate only when necessary
Temporary elevation pattern:
- Grant Administrator for implementation phase
- Downgrade to User when configuration is complete
- Document elevation period in access tracker
- Re-elevate temporarily if configuration changes needed
Scope Site Access Tightly
Grant access only to sites within engagement scope.
Best practices:
- List specific sites rather than "All Sites"
- Create site groups for multi-site engagements (e.g., "Collaborator Brand Family Sites")
- Review site lists quarterly; remove sites no longer in scope
- Use separate staging sites for testing; grant broader access there
Avoid:
- Granting "All Sites" access (includes future sites automatically)
- Giving access to production and staging unless both are required
- Broad site groups that include properties outside engagement scope
Separate Production and Staging Access
Use different permission levels for different environments.
Pattern:
- Staging sites: Administrator role (collaborators can experiment freely)
- Production sites: User role (read-only prevents accidental changes)
- Clearly label sites to prevent confusion (e.g., "Client Prod", "Client Staging")
Time-Bound Access
Set expiration dates and review regularly.
Implementation:
- Note access expiration date in user management notes field
- Set calendar reminders 30 days before expiration
- Review all collaborator accounts quarterly
- Remove dormant accounts (no logins in 60+ days)
Automated options:
- If using SSO, set IdP group membership with expiration dates
- Build a script to check last login dates via Chartbeat API or manual export
- Integrate with your IAM platform's access review workflows
Common Access Issues and Solutions
Issue: Collaborator Can't See Expected Sites
Symptoms:
- User logs in but sees "No sites available"
- Specific sites missing from dashboard dropdown
Resolution steps:
- Verify the collaborator accepted the invitation email
- Check that sites are explicitly granted in User Management → [User] → Site Access
- Confirm site names haven't changed (renamed sites must be re-granted)
- Verify the sites are active (archived sites won't appear)
- Clear browser cache and cookies, then re-login
Prevention: After adding users, ask them to log in while you watch to confirm site visibility. Provide a checklist of sites they should see.
Issue: SSO Login Fails
Symptoms:
- "Authentication failed" error
- User redirected to password login instead of SSO
- Infinite redirect loop
Resolution steps:
- Verify user's email domain is configured for SSO in Chartbeat
- Confirm user is assigned to Chartbeat SAML application in your IdP
- Check IdP logs for SAML assertion errors
- Test with a different user to isolate account-specific vs. configuration issues
- Contact Chartbeat support to verify SSO configuration on their end
Prevention: Document SSO setup and test with new users before rolling out to collaborators.
Issue: API Key Returns 403 Forbidden
Symptoms:
- API authentication succeeds but requests return 403
- "Access denied" or "Insufficient permissions" errors
Resolution steps:
- Verify the user account associated with the API key has access to the requested site
- Check that the API key hasn't been revoked
- Confirm you're using correct API key in request headers
- Test API key with a known-working site ID to isolate issue
- Review rate limit status (429 errors, not 403, indicate rate limiting)
Prevention: Create API keys under service accounts with clearly documented site access. Test keys immediately after creation.
Issue: Administrator Can't Access Billing
Symptoms:
- Billing section missing or greyed out
- "Contact account owner" message
Resolution steps:
- Verify the user is truly an Administrator (not User role)
- Confirm SSO attributes map correctly (some SSO misconfigurations can affect roles)
- Check if billing access is restricted to specific email addresses by Chartbeat support
- Contact Chartbeat support to verify account ownership records
Prevention: Document which users should have billing access. Coordinate with Chartbeat support for any restrictions.
Issue: Alerts Not Working for Collaborator
Symptoms:
- Collaborator creates alert but doesn't receive notifications
- Alert appears in UI but never triggers
Resolution steps:
- Verify the collaborator has correct email address in profile
- Check email spam/junk folders
- Confirm alert thresholds are set appropriately (may not be triggering due to settings)
- For Slack integrations: Verify collaborator is in the Slack channel and integration is active
- Test alert by creating one that should trigger immediately (e.g., "visitors > 0")
Prevention: Have collaborators create test alerts during onboarding to verify delivery.
Security Recommendations
Enforce Multi-Factor Authentication
For password-based logins:
- Chartbeat doesn't natively enforce MFA platform-wide
- Require collaborators to use password manager with strong, unique passwords
- Recommend enabling MFA on collaborator's email account (protects password reset)
For SSO-based logins:
- MFA is enforced at your IdP level
- Verify your IdP MFA policy applies to collaborators
- Preferred approach for enterprise environments
Use SSO Instead of Password Logins
SSO provides stronger security and easier lifecycle management.
Benefits:
- Centralized authentication
- MFA enforced at IdP
- Automatic revocation when removed from IdP
- Audit trail in both Chartbeat and IdP
Implementation:
- Enable SSO through Chartbeat support
- Test with pilot users before enforcing
- Migrate existing collaborator accounts to SSO
- Optionally disable password logins entirely
Rotate API Keys Annually
API keys are long-lived and don't expire automatically.
Rotation schedule:
- Production integrations: Rotate annually
- High-privilege keys: Rotate every 6 months
- When collaborator team members change: Rotate immediately
Rotation process:
- Create new API key
- Update collaborator integrations to use new key
- Test integrations
- Revoke old key
- Document rotation in secrets management system
For collaborator engagements:
- Rotate all collaborator API keys when engagement ends
- Don't share keys via email; use secure transfer methods
- Monitor for usage of old keys after rotation (indicates missed integration)
Implement IP Allowlisting
Chartbeat supports IP allowlisting for added security (enterprise feature).
Configuration:
- Request IP allowlisting from Chartbeat support
- Provide collaborator office and VPN IP ranges
- Test before enforcing to avoid lockouts
- Plan for remote work and mobile access scenarios
Limitations:
- Not self-service; requires Chartbeat support
- May conflict with distributed/remote collaborator teams
- SSO + MFA may provide sufficient security without IP restrictions
Monitor for Anomalous Activity
Set up processes to detect unusual collaborator behavior.
Monitor:
- Audit logs for unexpected configuration changes
- Last login dates (dormant accounts may indicate offboarding needed)
- New API keys created (should align with documented integrations)
- Site access changes (expansion beyond original scope)
Response workflow:
- Detect anomaly through manual audit log review
- Contact collaborator to verify legitimacy
- If unauthorized: Immediately revoke access and rotate API keys
- Document incident
- Update security controls and access procedures
Governance Checklist
Before granting access:
- Data Processing Agreement signed and filed
- Account role selected (default to User unless Administrator needed)
- Site access list documented (specific sites, not "All Sites")
- SSO group membership configured (if applicable)
- API keys generated and stored in vault (if needed for integrations)
- Access expiration date recorded
- Collaborator contact information obtained
Quarterly review:
- Confirm site access aligns with active contract/SOW
- Review audit logs for unexpected configuration changes
- Check last login dates; remove dormant accounts (60+ days no login)
- Verify API keys still in use; revoke unused keys
- Export and archive audit logs
- Update site access as properties launch or are decommissioned
When engagement ends:
- Remove user account or revoke all site access
- Revoke all API keys associated with collaborator
- Remove from SSO/IdP group (if applicable)
- Export final audit log showing removal
- Verify no active integrations remain using collaborator keys
- Confirm collaborator deleted local exports per DPA
- Archive access documentation
Annual compliance:
- Review all Chartbeat access against current contracts
- Audit account roles for over-provisioning
- Test SSO integration (if configured)
- Review API key inventory and rotation schedule
- Update documentation for Chartbeat feature changes
Related Documentation
- Add User Access - Step-by-step guide for inviting collaborators and assigning sites
- Update Access & Roles - How to modify account roles and site access during engagements
- Remove User Access - Offboarding workflow including API key revocation and audit exports
- Chartbeat Help Center - Official product documentation
- Chartbeat API Documentation - Technical reference for integrations
Additional Resources
- Chartbeat Dashboard: chartbeat.com/publishing/dashboard (login)
- Chartbeat API Docs: chartbeat.com/docs/api
- Chartbeat Status Page: status.chartbeat.com (platform health)
- Chartbeat Support: Contact through in-app support widget or account team
Document which sites the collaborator can access and review quarterly for new launches or decommissioned properties. Capture Chartbeat's User Audit export after every change and archive it with IAM records. Align Chartbeat login policies (MFA, SSO) with your enterprise baseline and confirm the collaborator meets those requirements. Track service account passwords or API tokens in your chosen secrets manager with ownership clearly assigned.