Technical specification of data access scope, encryption implementation, network egress, authorization model, and infrastructure for Workflow Archaeologist. Intended for security review, vendor risk assessment, and technical due diligence.
The application requests nine OAuth scopes from HubSpot's OAuth 2.0 authorization server. All nine are read scopes. No write, create, delete, or send scope is requested at any point in the authorization flow.
| Scope | Grants | Consumed by |
|---|---|---|
| automation | Read workflow definitions, action sequences, enrollment criteria | Workflow graph ingestion |
| crm.schemas.contacts.read | Read contact object property schema | Property-reference resolution |
| crm.schemas.companies.read | Read company object property schema | Property-reference resolution |
| crm.schemas.deals.read | Read deal object property schema | Property-reference resolution |
| forms | Read form definitions | Orphaned-reference detection |
| content | Read marketing email/page asset metadata | Send-action and content-reference validation |
| crm.objects.owners.read | Read HubSpot user/owner records | Action attribution |
| crm.lists.read | Read list definitions and membership counts | List-reference validation |
| crm.objects.contacts.read | Read contact records | Aggregate reach-ratio computation only; no individual contact record is persisted to the database |
Scopes explicitly not requested: automation.write, crm.objects.contacts.write, content.write, forms.write, any e-commerce, tickets, conversations, or settings scope, and no scope covering billing or account administration.
Standard authorization-code grant. Implementation specifics:
crypto.randomUUID()) is generated per authorization request and stored in an HttpOnly, SameSite=Lax cookie with a 600-second expiry, scoped to path /. The callback validates the returned state against this cookie before proceeding.DELETE /oauth/v1/refresh-tokens/{token} against HubSpot's revocation endpoint, invalidating the token on HubSpot's side, in addition to deleting the local encrypted copy.Complete enumeration of non-idempotent (non-GET) HTTP calls this application issues to HubSpot's API surface:
All outbound HubSpot API calls are rate-limit aware: responses are checked for HTTP 429, Retry-After is honored when present, requests are retried up to a fixed budget, and the call fails closed (throws) rather than silently proceeding after the retry budget is exhausted.
| Property | Value |
|---|---|
| Cipher | AES-256-CBC |
| Key length | 256-bit (32 bytes) |
| IV | 128-bit (16 bytes), cryptographically random, generated per encryption operation |
| Ciphertext format | {iv_hex}:{ciphertext_base64} |
| Key storage | Application environment configuration — not co-located with the database |
| Key rotation dependency | Decryption is attempted lazily at call time; a missing or malformed key throws rather than degrading silently |
Both the OAuth access token and refresh token are encrypted independently before the write to the portals table. No plaintext token value is written to persistent storage at any point. A distinct random IV per encryption call means identical plaintext tokens encrypt to distinct ciphertext on each write.
Transport encryption: TLS 1.2+ for all connections — browser-to-application, application-to-HubSpot, application-to-database.
Multi-tenancy is enforced at the database layer via PostgreSQL row-level security (RLS), not exclusively in application code. Every table storing portal, dig, graph, or finding data carries an RLS policy scoping rows to the requesting user's workspace membership. A query issued under one workspace's session cannot return rows belonging to another workspace, independent of application-layer logic correctness.
| Role | Read | Trigger digs / triage findings | Connect/disconnect portals | Manage team |
|---|---|---|---|---|
| Owner | ✓ | ✓ | ✓ | ✓ |
| Member | ✓ | ✓ | — | — |
| Viewer | ✓ | — | — | — |
Third-party subprocessors with access to infrastructure or data, disclosed for vendor-risk and subprocessor-registry purposes:
| Component | Provider |
|---|---|
| Application hosting / compute | Vercel |
| Database | Supabase (managed PostgreSQL) |
| Authentication | Supabase Auth |
| Background job orchestration | Inngest |
Standard security headers, including a Content-Security-Policy restricting cross-origin framing, are enforced at the application layer on every response.
Campaign Creators, the organization operating Workflow Archaeologist, holds SOC 2 Type II certification covering its organizational security controls.
Scope note: SOC 2 Type II audits define a specific system boundary. This certification has not been independently confirmed by this document to include Workflow Archaeologist as a named system within that boundary. For procurement requiring a specific audit-boundary confirmation, request documentation directly — see Section 10.
For security review, source-level walkthrough under NDA, SOC 2 documentation, or completion of a vendor security questionnaire, contact: security@campaigncreators.com.