Developer Options

For advanced users and developers looking to extend ChargePanda.

REST API

ChargePanda provides a REST API to integrate with your other systems. Common endpoints include:

• GET /api/v1/products
• GET /api/v1/orders/{id}

Authentication is handled via personal access tokens, which can be managed from the user profile settings.

License key verification has its own dedicated reference — see Verify API Reference.

System Updates

Keep ChargePanda up to date with the latest features and security fixes. Navigate to Admin Dashboard > Settings > Updates to check for and install the latest versions directly from your dashboard.

Logs

View error and activity logs under Admin Dashboard > Settings > Logs to troubleshoot any issues with your installation.

Testing the Upgrade Path

ChargePanda ships with an upgrade test suite that proves the migration stack is safe to run against a real, years-old customer database — not just a fresh install. This is the most important pre-release check for a self-hosted product.

Running the suite

composer test:upgrade

This command:

1. Migrates a baseline schema (the schema a long-time customer would have before upgrading).
2. Seeds it with old-format data — entrust role tables, legacy plans.features JSON, old custom_css setting, and a completed order with a license.
3. Runs php artisan migrate on top of that data — exactly the production upgrade path.
4. Asserts that every data-transform migration ran cleanly and left the data intact.

Run this before every release. A failure here means a customer's update will break their database; a failure in the regular smoke suite (composer test) means a fresh install broke. Both must be green.

Extending the seeder

When you add a new data-transform migration (one that reads and rewrites existing rows, not just adds a column), extend database/seeders/Testing/LegacyDatabaseSeeder.php:

1. Add synthetic old-format rows that represent what a real customer would have before the migration.
2. Guard every insert with Schema::hasTable() / Schema::hasColumn() so the seeder stays correct if the baseline cutoff changes.
3. Add a corresponding assertion in tests/Upgrade/UpgradeTest.php that proves the transform ran correctly.

Migrations that only add columns, create tables, or seed settings do not need a seeder extension — the existing test_full_migration_runs_clean_on_legacy_data case covers those automatically.