Legal
Cookie & Storage Disclosure
Shipping API Dojo currently relies on first-party storage needed to provide requested learning and account features. This page explains the browser storage, cookies, and hosted records that exist today.
The current implementation does not add analytics, remarketing pixels, session replay tools, or other non-essential tracking identifiers.
That means the current storage model is limited to necessary auth/session and requested-service functionality. If optional tracking is introduced later, this position must be revisited.
This disclosure covers browser storage, session cookies, and hosted records tied to auth, progress, billing, and transactional email.
For the broader explanation of how those records are used, retained, and handled through support, see the Privacy Policy.
Browser storage and cookies
Where
Browser localStorage key `shipping-api-dojo-progress`.
When
When you use lessons, drills, or scenarios without signing in, and also as the local cache that can later be merged into an account.
Purpose
Remember anonymous lesson, drill, streak, XP, and scenario progress in the browser you are using.
Required
Yes. This is part of the progress feature you requested.
Retention
Until you reset/import progress, clear browser storage, or your browser removes it.
Where
Browser localStorage key `api-trainer-progress`.
When
Only if an older `api-trainer-progress` key still exists in the browser.
Purpose
Migrate older anonymous progress into the current browser storage key without losing prior progress.
Required
Yes, but only for users with older saved progress.
Retention
Read only during migration and removed once data is copied into the current key.
Where
First-party cookies issued through Better Auth on `shipping.apidojo.app` and, if enabled later, an explicitly configured subdomain cookie scope.
When
When you sign in, keep a session active, reset a password, or use other account-related auth flows.
Purpose
Authenticate you, keep your session active, and secure account-related requests.
Required
Yes. These are strictly necessary when account features are used.
Retention
Until sign-out, cookie expiry, or browser removal, subject to the configured session lifetime.
Hosted records behind signed-in features
Where
Hosted database records for `user`, `session`, `account`, and `verification`.
When
When you sign up, sign in, reset a password, or use magic-link flows.
Purpose
Create and secure user accounts, keep sessions active, and support password-reset or magic-link verification flows.
Required
Yes for signed-in features.
Retention
While the account remains active, plus a limited period where needed for security, abuse prevention, or legal compliance.
Where
Hosted database records for `user_progress` and `progress_merge_events`.
When
When a signed-in user syncs progress or when anonymous local progress is merged into an account.
Purpose
Persist progress across sessions and devices and record how anonymous local progress was merged into an account.
Required
Yes for server-backed progress.
Retention
While the account remains active, subject to deletion-request handling and operational exceptions.
Where
Hosted database records for `subscriptions`, `user_entitlements`, and `billing_events`.
When
When Creem reports subscription or billing webhook events, or when account entitlements are updated.
Purpose
Reflect plan status, enable or disable paid capabilities, and keep an audit trail for billing operations.
Required
Yes for paid features.
Retention
As needed for contract performance, accounting, tax, fraud prevention, disputes, and legal obligations.
Where
Hosted database records for `email_events`.
When
When Resend reports tracked webhook events for transactional email we send.
Purpose
Track delivery, bounce, complaint, and suppression events so account and billing email can be operated safely.
Required
Yes for transactional email operations.
Retention
As needed to troubleshoot delivery, maintain suppression safety, and respond to abuse or support issues.
Future consent-trigger matrix
The current no-banner position only holds while storage remains limited to strictly necessary auth/session and requested-service functionality. Any of the triggers below would require a fresh compliance review before production rollout.
Examples
- Page analytics, product analytics, or attribution tooling that stores identifiers beyond the requested service flow.
- Examples include GA4, PostHog analytics mode, Mixpanel, Amplitude, or similar analytics SDKs.
Why this changes the current position
These tools are not required to deliver the lesson, arena, account, billing, or transactional-email features the user explicitly requested.
Required next step
Add consent controls before enabling them in production, classify the related cookies or storage as optional, and block loading until consent is granted where required.
Examples
- Ad conversion pixels, audience syncing, retargeting tags, or affiliate tracking identifiers.
- Examples include Meta Pixel, LinkedIn Insight Tag, Google Ads remarketing, or similar ad-tech tags.
Why this changes the current position
These tools are marketing-oriented rather than strictly necessary to provide the requested service.
Required next step
Ship a consent banner or equivalent consent gate before deployment and keep the tags disabled until the user opts in.
Examples
- Cross-session preference profiling, personalization experiments, or recommendation state that is not necessary to deliver the current requested feature.
- Examples include marketing personalization profiles or non-essential remembered behavior across visits.
Why this changes the current position
Once storage moves from core service operation into optimization or profiling, it stops fitting the current strictly-necessary stance.
Required next step
Assess the storage as optional, disclose the profiling purpose clearly, and add consent gating before enabling it for production users.
Examples
- Replay tools, heatmaps, scroll tracking, rage-click detection, or similar behavioral observation systems.
- Examples include Hotjar, FullStory, LogRocket replay mode, or Microsoft Clarity session capture.
Why this changes the current position
These tools observe user behavior for optimization or diagnostics rather than providing the core requested learning/account service itself.
Required next step
Introduce consent controls before deployment, keep capture disabled until consent is recorded, and document the behavioral data category explicitly.
Examples
- Third-party tags, embedded widgets, or external scripts that set or read identifiers for their own tracking purposes.
- Examples include social embeds with tracking cookies, marketing chat widgets, or externally hosted personalization tags.
Why this changes the current position
Third-party identifiers create tracking exposure beyond the first-party, strictly necessary storage currently disclosed for auth and requested-service functionality.
Required next step
Block the third-party identifier until consent exists, update the disclosure pages, and re-check whether a consent banner becomes mandatory before launch.
The product keeps these disclosures public and crawlable so the storage model is visible before you sign in. Settings remains the main in-app place to manage local browser progress and reach account-related requests.