Why Xano's create object is essential for database updates

Introduction

As a developer who transitioned from traditional coding to primarily using No Code platforms, I'm always exploring ways to make backend operations more efficient and reliable. Through my No Code & Low Code blog series, I share the techniques and patterns I discover along the way. While working on several Xano projects recently, I've found myself reaching for one particular function repeatedly: the create object function.

Last month, I was building a financial tracking application where I needed to update user account balances based on transaction calculations. Initially, I was managing multiple variables and struggling with inconsistent update patterns. The code was messy, error-prone, and difficult to maintain. After some experimentation and diving deeper into Xano's capabilities, I discovered how powerful the create object function could be for building dynamic PATCH request payloads.

The breakthrough came when I realized I could perform all my mathematical calculations first, then use create object to build a clean, structured payload for my database updates. This approach transformed not just that project, but how I handle complex data updates in every Xano backend I build.

Having refined this technique across multiple projects, I decided to write this blog post to share the approach, hoping it might help someone facing similar challenges with dynamic database updates in Xano.

What We're Building Today

We're going to build a system that updates user account balances based on transaction history. This will show:

• Using create object to build dynamic PATCH request payloads

• Performing mathematical calculations before updates

• Handling conditional updates based on business logic

• Updating specific rows using ID identification

• Building reusable update patterns

This real-world scenario shows exactly why create object is one of Xano's most powerful features for database operations.

The Problem: Complex Database Updates

Let's look at a realistic users table structure:

users table:
├── id (primary key)
├── first_name (text)
├── last_name (text)
├── email (text)
├── phone (text)
├── profile_picture_url (text)
├── date_of_birth (date)
├── address (text)
├── city (text)
├── state (text)
├── zip_code (text)
├── account_balance (decimal)
├── total_spent (decimal)
├── loyalty_points (integer)
├── membership_tier (text)
├── last_login (datetime)
├── last_transaction_date (datetime)
├── email_verified (boolean)
├── phone_verified (boolean)
├── marketing_consent (boolean)
├── account_status (text)
├── created_at (datetime)
└── updated_at (datetime)

When a user makes a purchase, you only need to update 4 specific fields:

1. Subtract the purchase amount from account_balance

2. Add the purchase amount to total_spent

3. Calculate and add loyalty points (1 point per $100 spent)

4. Update the last_transaction_date

Now that I’m a huge fan of PATCH request, I’d like to reiterate the differences between PUT and PATCH with some context

Why PATCH (not PUT) is essential here:

• PUT would require ALL 21 fields in your request - including name, email, address, preferences, etc.

• PATCH only needs the 4 fields you're actually changing

• Missing fields in PUT = those fields get set to null (data loss!)

• Missing fields in PATCH = those fields stay unchanged (safe!)

Without create object, you'd need separate variables for each field. With it, you can build one clean, safe object for your PATCH request.

Building the Dynamic Update System

Step 1: Setting Up the Function

Create a API called process_user_transaction that will handle our purchase updates. I chose Custom end point while creating the API.

Step 2: Define Input Parameters

Set up parameters for:

• user_id (integer) - To identify which row to update

• purchase_amount (decimal) - The transaction amount

• transaction_type (text) - Type of transaction for different calculations. Possible values can be Online, In store, etc.,

• 

Step 3: Get Current User Data

First, fetch the current user data to perform calculations:

Store the response in a variable called current_user.

Step 4: Perform Mathematical Calculations

Now we'll calculate the new values:

Create variables for:

• new_balance = current_user.account_balance - purchase_amount

• 

• new_total_spent = current_user.total_spent + purchase_amount

• 

• new_loyalty_points = current_user.loyalty_points + floor(purchase_amount)

• 

Step 5: Create the Update Object

Here's where the magic happens. Use create object to build your PATCH payload:

Keys array:

Create a variable “keys” to hold the keys of an object.

Values array:

Create a variable “values” to hold the corresponding values of an object.

We then create the result variable using both keys and values using create_object method.

Step 6: Execute the PATCH Request

Now use your created object as the input for the PATCH request:

• Method: PATCH

• Endpoint: /users/{user_id}

• Body: Use your created object variable

• URL Parameter: user_id from your input

Steps 7 and 8 demonstrate best practices and show what else can be done. It has nothing to do with create_object method.

Step 7: Add Conditional Logic

Make it smarter by adding business rules:

Use IF conditions to create different objects based on scenarios:

• VIP customers get bonus loyalty points

• Negative balances trigger different updates

• Different transaction types require different calculations

Step 8: Error Handling and Validation

Add validation before creating your update object:

Check for:

• Sufficient account balance

• Valid transaction amounts

• User existence

Pro Tips from My Experience

1. Always Validate First: Check your calculations and data before creating the update object

2. Use Descriptive Variable Names: update_object is better than obj1

3. Handle Edge Cases: What happens if calculations result in negative values?

4. Log Your Updates: Include metadata in your objects for audit trails

5. Test with Edge Cases: Zero amounts, very large numbers, decimal precision

6. Consider Database Constraints: Make sure your calculated values respect field limits

Conclusion

Using create object for database updates has transformed how I handle complex data modifications in Xano. Instead of managing multiple variables and risking inconsistent updates, I can build precise, clean objects that contain exactly what needs to be updated.

This pattern works for any scenario where you need to update database records with calculated or conditional values. From simple balance updates to complex multi-field modifications, create object keeps your code organized and your updates reliable.

The mathematical calculation example we built today is just the beginning. Once you master this pattern, you'll find yourself using it everywhere—subscription management, inventory tracking, user analytics, and countless other scenarios where data needs to be calculated before it's stored.

As a Xano certified developer, I've implemented this pattern across several projects, including complex SaaS platforms in diverse domains like real estate, estate tech, and unique SaaS products. It's one of those techniques that seems simple but unlocks enormous power and flexibility in your backend operations.

Need help to build your next application? Whether you're developing financial platforms, inventory management systems, or complex business applications, I can help you architect and build complete solutions from backend to frontend and everything in between.

Ready to master advanced Xano patterns? Let's connect and build something powerful together!