API changes:
- 'verified' renamed to 'email_verified'
- 'api_key' field removed when null (not included in response)
Script changes:
- Check 'email_verified' field instead of 'verified'
- Handle missing 'api_key' field (use jq default: '.api_key // ""')
- Check email_verified AND api_key presence to determine flow
- Display email verification status clearly
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
CRITICAL BUG: When running --verify-email-code separately (not during registration),
the script was not extracting the API key from the verification response.
Problem:
- Registration flow had API key extraction code (line 387-393)
- Standalone verify flow was missing it (line 445)
- API key returned by API but not saved to config
Solution:
- Added API key extraction to standalone verification flow
- Now both flows extract and save the API key properly
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Shows user_id and verification code before making API call
to help troubleshoot 'User ID is required' errors.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The verify endpoint is now public and doesn't require API key.
Instead it takes user_id and verification_code in the request body.
Changes:
- Removed X-API-Key header from verify request
- Added user_id to request body
- Endpoint returns API key after successful verification
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Problem: New users with email verification enabled receive api_key: null,
but script only checked for existing_user flag, not null API key.
Solution: Check if api_key is null first, then determine if it's:
- Existing unverified user (load key from config)
- New user with verification (api_key comes after verification)
- New user without verification (api_key provided immediately)
This fixes the 'Failed to extract API key' error for new registrations.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The API key is now generated during email verification, not registration.
Changes:
- Extract api_key from verification response
- Save the API key to config after successful verification
- Display confirmation message when API key is received
This works with the new security flow where API keys are only issued to verified users.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
When a user tries to register with an email that already exists but is not verified:
- API now returns existing_user: true and api_key: null
- Script detects existing_user flag
- Loads existing API key from config file instead of expecting it in response
- Shows appropriate message about new verification code being sent
- Continues to verification step
This fixes the error 'Failed to extract user data' when users re-register.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Replace bash-specific &> with >/dev/null 2>&1
- Replace bash-specific == with POSIX-compliant = in [ ] tests
- Script now works with both sh and bash
- Fixes "unexpected operator" errors when run with sh
Issue: User ran script with 'sh' instead of 'bash', causing errors
Root cause: Bash-specific syntax (== and &>) not compatible with POSIX sh
Solution: Use POSIX-compliant alternatives that work in both shells
Changes:
1. Repository URL format: HTTPS → SSH
- Changed from: https://git.startanaicompany.com/user/repo.git
- Changed to: git@git.startanaicompany.com:user/repo.git
- Reason: Coolify requires SSH format for private repo deployments
2. API field name: git_token → gitea_api_token
- Changed from: "git_token": "${GITEA_API_TOKEN}"
- Changed to: "gitea_api_token": "${GITEA_API_TOKEN}"
- Reason: Match Coolify Wrapper API specification
These changes ensure the deployment script works with the Coolify
Wrapper API at apps.startanaicompany.com
The wrapper will now:
- Accept the SSH Git URL format
- Properly receive the Gitea API token
- Set up deploy keys and webhooks automatically
SAAC API now receives user's GITEA_API_TOKEN to enable Coolify to clone private repositories.
Changes:
- Added early validation of GITEA_API_TOKEN (before app creation)
- Pass git_token parameter to SAAC API in application creation request
- Removed duplicate GITEA_API_TOKEN check in webhook section
- Updated error message to explain both use cases (cloning + webhooks)
The SAAC API will use this token to configure Coolify with authenticated git access:
https://${GITEA_API_TOKEN}@git.startanaicompany.com/${user}/${repo}.git
This enables automatic deployments for private repositories.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Automatic deployments are essential for the template, so GITEA_API_TOKEN is now required.
Changes:
- .env.example: Marked both API keys as REQUIRED
- deploy-to-apps.example.sh: Script now exits with error if GITEA_API_TOKEN not set
- Added clear instructions on how to get Gitea API token
Without webhooks, users would need to manually trigger deployments after every push,
which defeats the purpose of automated infrastructure.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Removed SAAC API repository link (internal implementation detail)
- Changed DNS target from app.coolify.io to apps.startanaicompany.com
- Updated .env.example to only reference SAAC_API_KEY (not internal tokens)
- Simplified support section to only show template issues
Users should only interact with the SAAC API as a service, not see internal implementation.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Users should see this as the "StartAnAiCompany platform" not as a Coolify proxy.
Changes:
- README.md: "StartAnAiCompany infrastructure" and "StartAnAiCompany platform"
- DEPLOYMENT_GUIDE.md: Removed all Coolify references
- deploy-to-apps.example.sh: "deployment platform" instead of "Coolify"
Now all user-facing documentation uses StartAnAiCompany/SAAC branding exclusively.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Changed all references from "Coolify Wrapper" / "WRAPPER_API_KEY" to
"SAAC" / "SAAC_API_KEY" for better branding and user experience.
SAAC = StartAnAiCompany - makes it clear users are deploying to
StartAnAiCompany infrastructure rather than a "wrapper" service.
Changes:
- WRAPPER_API_KEY → SAAC_API_KEY throughout
- "Wrapper API" → "SAAC API" in all documentation
- Updated user-facing messages to reference StartAnAiCompany
This makes the service feel more direct and brand-focused rather
than like a proxy/wrapper layer.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This enables deployment via apps.startanaicompany.com instead of direct Coolify access.
New files:
- deploy-to-apps.example.sh: Deployment script using Wrapper API
- DEPLOYMENT_GUIDE.md: Comprehensive deployment documentation
Updated files:
- README.md: Updated deployment steps to use Wrapper API
- .gitignore: Added deploy-to-apps.sh to exclusions
Benefits:
- Users no longer need master Coolify token
- Each user gets their own API key
- Automatic resource isolation
- Rate limiting and audit logging
- Simpler deployment process
The old deploy-to-coolify.example.sh remains for reference but new
deployments should use the wrapper API.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
