Overview
The most popular destination for integration data is the database. With Fiber, you can sync third-party API data into your application database, to be easily consumed by your backend services.
Destination tables
Fiber writes each type from the source API into a separate table. Tables are mounted with the columns and types you would expect by reading the source API documentation.
You must individually register the destination tables that you want Fiber to write data into. Today, you can do this via the Fiber dashboard.
Managing tables
Use the Fiber dashboard to manage the tables associated with a database destination.
Each destination table within Fiber associated to a single source API resource, such as a Stripe Transaction or Shopify Order. It's therefore not possible to write different resources into the same table.
Register a table
You can register tables whether or not they already exists inside your database.
-
Existing tables. When you register an existing table, Fiber will scan it to make sure it contains the appropriate columns, types and indices.
-
Non-existent tables. When you register a table that does not yet exist, you have two options. First, you can ask Fiber to mount it for you. Second, you can mount it yourself. The latter is useful if you use an ORM that handles migrations for you.
To have Fiber mount the table for you, finish registering your table via the Dashboard. You will be redirected to the detail page for the new destination table. Then click "Mount Database Table". You will be asked to confirm your action through a dialog.
Modify a table
Please reach out if you need to modify a table.
Delete a table
Please reach out if you need to delete a table.
Column and type mapping
By default, Fiber mounts your destination tables following the precise schema of the source API. You can, however, choose a naming convention that best suits your codebase. For example:
| Example column | Snake-case format | Camelcase format |
|---|---|---|
| CreditCardPayment | credit_card_payment | creditCardPament |
| foo_bar | foo_bar | fooBar |
| ASIN | asin | asin |
| MerchantOrderID | merchant_order_id | merchantOrderId |
Reserved columns
The following columns are required on each destination table, and each carry a special meaning.
| Column | Type | Meaning |
|---|---|---|
id | string | The unique identifier of this resource within the source. |
created_at | timestamp (nullable) | The creation timestamp for this resource in the source. |
updated_at | timestamp (nullable) | The update timestamp for this resource in the source. |
account_id | string | The external id of the third-party account that owns this row. |
pf_id | UUID | The primary key column. |
pf_created_at | timestamp | The time when Fiber first created this row. |
pf_updated_at | timestamp | The time when Fiber last updated this row. |
id is not unique
Notice that the id is not the primary column, nor is it unique. It's common
for APIs to reuse ID values across different accounts. For example, BigCommerce
products use a numerical ID that restarts from 1 for each store. It's also
possible for the same resource to be referenced by more than one account. For
example, the same Github repository may be synced on behalf of two different
users of your app, provided they both have access to it.
Column indices
Fiber requires the following indices to be present:
account_idaccount_id+id(unique)updated_at+account_id(for performance)
You may add other indices to improve performance. Keep in mind that extra indices may slow down database writes.