Blaze Balance Engine SaaS beta update:
We’re now deep into the controlled Shopify connection architecture phase, and the product has moved from “concept shell” into a real Laravel beta with safety-gated infrastructure.
The current beta is focused on proving the connection, tenant, OAuth, and token-vault architecture before allowing any live customer data flow.
What is working now:
The Laravel beta app is live in its private beta environment.
The users table has been repaired and confirmed working.
Core tenant tables are present:
tenants
workspaces
shopify_stores
tenant_user
The encrypted Shopify token vault table is present:
shopify_oauth_tokens
The token vault smoke test passed earlier with columns, indexes, foreign keys, and empty vault posture verified.
The encrypted token service stub has been tested using fake sample data only.
The token storage approval gate is working as a non-persistent review flow.
The OAuth exchange dry-run receipt room is installed.
The OAuth exchange approval and state-binding stub is installed.
The OAuth state nonce generator preview is installed.
The OAuth state vault design room is installed.
The latest migration approval gate is now installed for the future Shopify OAuth state vault.
Where we are now:
Blaze can now preview the future Shopify OAuth state lifecycle without storing anything yet.
That includes:
issuing a future state receipt
binding state to tenant/workspace/store/operator context
showing fingerprint-only receipts
previewing one-time-use state consumption
previewing replay rejection
previewing expired state rejection
previewing session mismatch rejection
previewing rollback posture
showing the future migration structure before it is created
This is intentionally not live OAuth yet.
No real Shopify tokens are stored.
No authorization codes are stored.
No raw OAuth state is displayed.
No raw token is displayed.
No encrypted token is displayed.
No Shopify API writes are enabled.
No webhooks are enabled.
No tenant enforcement is enabled.
No migration has been run for the future OAuth state vault yet.
That is the point of this stage: we are building the lock system before opening the door.
The latest beta room previews the future shopify_oauth_states table, including:
state fingerprint
payload hash
signature hash
session fingerprint
tenant binding
workspace binding
Shopify store binding
operator user binding
expiry window
consumed-at marker
replay tracking
callback receipt reference
redacted metadata only
The goal is to make Shopify OAuth state one-time-use, auditable, replay-resistant, tenant-bound, and safe before enabling any real exchange path.
What is still left before first test users:
Create the actual OAuth state vault migration file.
The next step is to move from migration preview to migration-file draft. This still should not automatically run anything. It should prepare the migration file, show the pretend command plan, and keep approval separate.
Run a controlled migration after review.
After the migration file is reviewed, we can run a controlled migration for the future shopify_oauth_states table.
No migrate:fresh.
No migrate:refresh.
No seed reset.
Just the specific approved migration path.
Seed or create the first tenant/workspace/store records.
Right now the tenant tables exist, but the tenant, workspace, and Shopify store rows are still empty. Before real test users, Blaze needs a clean first tenant record, workspace record, store record, and tenant-user link.
Connect OAuth state persistence to the future callback flow.
Once the state vault table exists, the system can move toward a real persisted OAuth state flow:
issue state
store only safe hashes/fingerprints
bind to tenant/workspace/store/operator/session
reject replay
reject expiry
consume once
write a safe callback receipt
Keep OAuth exchange behind a separate approval gate.
Even after state persistence works, OAuth exchange should remain disabled until specifically reviewed and unlocked.
The exchange path should only activate after:
state vault is working
callback validation is working
tenant binding is working
token vault is ready
rollback plan is documented
operator approval is explicit
Enable encrypted token storage only after state exchange is proven.
Token storage is its own separate gate.
The system should not persist live Shopify access tokens until:
OAuth exchange is working safely
state replay protection is working
token vault insert path is tested
token redaction is verified
revocation and rotation notes are ready
Add first read-only Shopify data bridge.
The first real data connection should stay read-only.
The goal is not “AI writes to Shopify.”
The first goal is:
read store status
read basic shop metadata
read product/order/inventory signals where allowed
normalize them into Blaze signals
show explainable recommendations
keep human review in the loop
Prepare the first tester flow.
Before inviting first test users, we still need:
tester login flow polished
workspace selection flow
first tenant dashboard
safe empty-state screens
reviewer/tester explanation copy
clear “read-only beta” disclosure
operator-only areas separated from tester areas
backup/rollback checklist
error logging and smoke-test checklist
The important part:
Blaze is not being rushed into live OAuth or token storage.
The current architecture is being built like an airlock:
Observe. Preview. Approve. Migrate. Bind. Validate. Persist safely. Read only. Then invite testers.
This is the right path for a serious SaaS product, especially one that will eventually connect to commerce systems like Shopify.
The beta is not ready for public users yet, but it is getting close to first controlled test-user readiness.
Right now, the remaining work is mostly about moving from preview rooms to controlled persistence, then from controlled persistence to read-only real data, then from read-only real data to private tester onboarding.
https://www.kickstarter.com/projects/blazeai/blaze-balance-engine-saas
Top comments (0)