The first step in loading your BaseCRM data to any data warehouse solution is accessing your data and starting to extract it.

As previously mentioned, using Base’s rich Core API, you can get access to data from 25 resources, including:

• Account: The Account API provides read-only access to your account details.
• Calls: The Calls API provides a simple interface to manage calls.
• Contacts: The Contacts API provides a simple interface to manage your contacts. A contact represents an individual or an organization.
• Deals: The Deals API provides a simple interface to manage deals.
• Leads: The Leads API provides a simple interface to manage leads. A lead represents an individual or an organization that expresses interest in your goods or services.
• Orders: Through the Orders API, you can manage your orders.
• Pipelines: The Pipelines API provides a read-only interface to your sales pipeline definition.
• Products: The Products API offers an interface for managing the Product Catalog. The catalog lists products that are available in your account.
• Users: Using the User’s API, you can interact with your account’s users. You can retrieve a single user as well as a list of all users associated with your account.

In addition to the above, the things that you have to keep in mind when dealing with the BaseCRM API are:

• Rate limits. According to the documentation, you can make up to 36,000 requests per hour (10 requests/ip/second).
• Authentication. You can authenticate on BaseCRM using OAuth.
• Pagination. API endpoints that return a collection of items are always paginated. The number of results to display can vary with a maximum value of 100.

After you have accessed your data on BaseCRM, you will have to transform it based on two main factors,

• The limitations of the database where the data is loaded
• The type of analysis that you plan to perform

Each system has specific limitations on the data types and data structures that it supports. If you want to push data into Google BigQuery, you can send nested data like JSON directly.

Also, you have to choose the right data types. Again, depending on the system you will send the data to and the data types that the API exposes to you, you will have to make the right choices. These choices are important because they can limit the expressivity of your queries and limit your analysts on what they can do directly out of the database.

The reports obtained from BaseCRM are similar to CSV files in structure. You also need to identify how to map a table into your database.

Data in Snowflake is organized around tables with a well-defined set of columns with each one having a specific data type.

Snowflake supports a rich set of data types. It is worth mentioning that a number of semi-structured data types are also supported. Snowflake allows loading data directly in JSON, Avro, ORC, Parquet, or XML format. Hierarchical data is treated as a first-class citizen, similar to what Google BigQuery offers.

There is also one notable common data type that Snowflake does not support. LOB or large object data type is not supported. Instead, you should use a BINARY or VARCHAR type. But these types are not that useful for data warehouse use cases.

A typical strategy for loading data from BaseCRM to Snowflake is to create a schema where you will map each API endpoint to a table.

Each key inside the BaseCRM API endpoint response should be mapped to a column of that table, and you should ensure the right conversion to a Snowflake data type.

You will need to ensure that as the data types from the BaseCRM API might change, and you adapt your database tables accordingly - automatic data typecasting isn’t available.

After you have a complete and well-defined data model or schema for Snowflake, you can move forward and start loading your data into the database.

Usually, data is loaded into Snowflake in a bulk way, using the COPY INTO command. Files containing the data, usually in JSON format, are stored in a local file system or Amazon S3 buckets. A COPY INTO command is invoked on the Snowflake instance, and data is copied into the data warehouse.

The files can be pushed into Snowflake using the PUT command into a staging environment before the COPY command is invoked.

Another alternative is to upload the data directly into a service like Amazon S3 from where Snowflake can access the data directly.

As you will be generating more data on BaseCRM, you will need to update your older data on Snowflake. This includes new records together with updates to older records that for any reason have been updated on BaseCRM.

You will need to periodically check BaseCRM for new data and repeat the previously described process while updating your currently available data if needed. Updating an already existing row on a Snowflake table is achieved by creating UPDATE statements.

Another issue that you need to take care of is identifying and removing any duplicate records on your database. Either because BaseCRM does not have a mechanism to identify new and updated records or because of errors on your data pipelines, duplicate records might be introduced to your database.

In general, ensuring the quality of the data that is inserted into your database is a big and difficult issue.

So far, we have understood what can be done with Snowflake and how to load data into it. The way to proceed relies heavily on the data you want to load, from which service they are coming from, and the requirements of your use case.

Things can get even more complicated if you want to integrate data coming from different sources. Instead of writing, hosting, and maintaining a flexible data infrastructure, a possible alternative is to use a product like RudderStack that can automatically handle these problems for you.

RudderStack integrates with multiple sources or services like databases, CRM, email campaigns, analytics, and more. Quickly and safely move all your data from BaseCRM to Snowflake and start generating insights from your data.