How to Build API Endpoints for Your SaaS Product

How API Endpoints Work on the Platform

Every custom app on the platform gets its own set of API endpoints through the app commands system. When you define a command in your app configuration, the platform creates a secure API endpoint that your frontend, mobile app, or external integrations can call.

The request flow works like this:

• Your frontend sends a POST request to the API with an app name, command name, and JSON data
• The platform validates the API key, checks the account is active, and verifies credit balance
• Your command function receives the account ID and the full JSON data payload
• Your function processes the request (reads/writes database, calls AI models, whatever your product needs)
• Your function returns an array, which the platform sends back as JSON to the caller

Every command function follows the same signature: $result = yourFunction($accountID, $jsonData). The platform gives you the authenticated account ID so you always know which customer is making the request, and the JSON data contains whatever your frontend sent.

Designing Your API

A well-designed API for a SaaS product follows predictable patterns. For each data type your product manages, you typically need these endpoints:

• Create: Accept the new record's data, validate it, assign an ID, and store it in the database
• Read (single): Accept a record ID, look it up in the database, and return it
• Read (list): Return all records of this type for the account, optionally filtered or paginated
• Update: Accept a record ID and updated fields, validate them, and save the changes
• Delete: Accept a record ID and remove the record from the database

For a helpdesk SaaS, your ticket endpoints might look like: createTicket, getTicket, listTickets, updateTicket, deleteTicket. Each one is a separate command in your app configuration.

Handling Input and Validation

Your command functions receive raw JSON data from the caller. Always validate before using it:

• Check that required fields exist and are not empty
• Validate data types (make sure a number field is actually a number, an email field looks like an email)
• Enforce maximum lengths to prevent abuse
• Return clear error messages when validation fails so your frontend can show users what went wrong

Good validation at the API layer means your frontend and your data stay clean. Never trust that the frontend has already validated the data, because API endpoints can be called directly by anyone with an API key.

Structuring Your Response

Every endpoint should return a consistent response format. A common pattern:

• Success: {"status": "success", "data": {...}}
• Error: {"status": "error", "message": "What went wrong"}

Consistent response formats make your frontend code simpler because every API call can be handled with the same response parsing logic. Include enough detail in error messages for the frontend to show useful feedback, but never expose internal details like database field names or stack traces.

Combining Multiple Operations

Sometimes a single user action requires multiple database operations. For example, creating an order might need to create the order record, update inventory counts, and send a confirmation email. You can handle this in one endpoint by performing all operations sequentially in your command function, or you can use background jobs for the parts that do not need to complete before the user gets a response.

For more complex multi-step operations, the platform's workflow automation system lets you chain multiple commands together with conditional logic, so one API call can trigger an entire business process.

API Security

The platform handles the main security concerns automatically:

• Authentication: Every API call requires a valid API key tied to a specific account
• Authorization: Your function receives the authenticated account ID, so all data access is automatically scoped to the correct customer
• Rate limiting: The credit balance system naturally limits excessive API calls
• HTTPS: All API communication is encrypted via SSL

For your part, focus on input validation (described above) and making sure your functions never return data belonging to a different account. Since the platform passes the authenticated account ID to every function call, this is straightforward as long as you always use that ID for database queries rather than accepting an account ID from the request body.