# Authentication Source: https://apidocs.glideapps.com/api-reference/v2/general/authentication Authenticating to the Glide API ## Format The Glide API uses bearer token authentication in the request header in the form: `Authorization: Bearer ` `` should be replaced with your actual token which you can find in the Glide Data Editor. You can find your API auth token in the Glide Data Editor ## Token Behavior Please be aware of the following as it relates to your API auth token: * It should be treated as a secret (i.e. it should not be checked into source control or exposed in client environments) * It is unique to your Glide user * It is scoped to your Glide team, so it has access to all applications and data in your team # Errors Source: https://apidocs.glideapps.com/api-reference/v2/general/errors Common error scenarios and responses ## Error Responses All error responses will follow the following format with a top-level `error` object and a `4XX` status code. ```json theme={null} { "error": { "type": "", "message": "" } } ``` ### Invalid Auth Token Using an auth token that does not exist or is incorrect will result in a `404` response status. ```bash theme={null} curl --request GET \ --url https://api.glideapps.com/tables \ --header 'Authorization: Bearer INVALID' ``` ```json theme={null} { "error": { "type": "request_error", "message": "API key not found, or duplicate IN****ID" } } ``` ### Invalid Stash ID or Serial Using a stash ID or serial that does not [meet the requirements](../stashing/introduction#stash-ids-and-serials) will result in a `400` response status. ```bash theme={null} curl --request PUT \ --url https://api.glideapps.com/stashes/-INVALID-/1 \ --header 'Authorization: Bearer VALID-API-KEY' ``` ```json theme={null} { "error": { "type": "request_validation_error", "message": "Invalid request params: Stash ID must be 256 characters max, alphanumeric with dashes and underscores, no leading dash or underscore" } } ``` ### Invalid Row Data When adding or updating rows in a table, if the row data does not match the table schema, the API will return a `422` response status. #### Unkown Column ```json theme={null} { "error": { "type": "column_id_not_found", "message": "Unknown column ID 'foo'" } } ``` #### Invalid Value for Column ```json theme={null} { "error": { "type": "column_has_invalid_value", "message": "Invalid value for column 'foo'" } } ``` ### Row Not Found When attempting to update a row that does not exist, the API will return a `404` response status. ```json theme={null} { "error": { "type": "row_not_found", "message": "Row with ID 'XHz6kF2XSTGi1ADDbryjqw' not found" } } ``` # Glide API v2.0 Source: https://apidocs.glideapps.com/api-reference/v2/general/introduction The Glide API v2.0 is a RESTful API that allows you to programmatically interact with data on the Glide platform. These are the developer docs for version 2.0 of the API, initially released in July of 2024. This API is currently in Public Beta. **You may encounter minor bugs while using the API**. ## Functionality This version of the Glide API **only works with the Glide Big Tables data source**. An attempt to use this API with any other data source will return an error. ## Location The Glide API v2.0 is located at: `https://api.glideapps.com/`. ## Pricing * Adding, updating, or deleting rows will use 0.01 updates per row changed * Getting rows will use 0.001 updates per row retrieved If you use a stash, updates will be charged only when you commit your stash. Deleting a stash will not use updates. All other calls will not use updates, such as creating tables, listing tables, or getting row versions. **Additional updates above your team's quota are \$0.02 each.** You can read more pricing details on our [Pricing page](https://www.glideapps.com/pricing). ## Previous Versions This Glide API v2.0 differs from Glide API v1.0 in the following ways: * Only operates on Glide Big Tables data source * Uses fewer updates for reading, adding, editing, and deleting data * Capable of ingesting large data sets through the use of [stashing](/api-reference/v2/stashing/introduction) * Does not require scoping by Glide app (i.e., `App ID` is not required) # Limits Source: https://apidocs.glideapps.com/api-reference/v2/general/limits Rate and operational limits for the Glide API ## Payload Limits You should not send more than 15MB of data in a single request. If you need to work with more data, use [stashing](/api-reference/v2/stashing/introduction) to upload the data in 15MB chunks. ## Row Limits Even when using stashing, there are limits to the number of rows you can work with in a single request. These limits are approximate and depend on the size of the rows in your dataset. | Endpoint | Row Limit | | ------------------------------------------------------------- | --------- | | [Create Table](/api-reference/v2/tables/post-tables) | 8m | | [Overwrite Table](/api-reference/v2/tables/put-tables) | 8m | | [Add Rows to Table](/api-reference/v2/tables/post-table-rows) | 250k | # Get Job Status Source: https://apidocs.glideapps.com/api-reference/v2/jobs/get-job get /jobs/{jobID} Check whether a job is finished, and get its result Returns the status of an asynchronous job. # Glide API Changelog Source: https://apidocs.glideapps.com/api-reference/v2/resources/changelog ### June 18, 2025 * Added `GET /tables/{tableID}/rows/{rowID}` endpoint to retrieve a specific row by ID. ### May 19, 2025 * When creating a table with the `POST /tables` endpoint, you can now specify one or more apps to link the new table to. ### April 1, 2025 * Clarified that the version supplied in the `If-Match` header is compared against the row version, not the table version, in the Update Row endpoint. * Added HTTP 412 Precondition Failed as a possible error for endpoints that accept an `If-Match` header. ### December 13, 2024 * Clarified that endpoints return row IDs in the same order as the input rows. * Clarified the requirements for row data to match the table's schema and what happens if it doesn't. ### November 26, 2024 * Added a warning that using the `PUT /tables` endpoint to overwrite a table will clear user-specific columns. ### November 21, 2024 * Introduced `HEAD /tables/{tableID}/rows` endpoint to retrieve the current version of table data via `ETag` header. * Added support for the `If-Match` header to the Overwrite Table and Update Row endpoints. * Introduced a new Data Versioning guide. ### November 11, 2024 * Added `GET /tables/{tableID}/rows` endpoint to retrieve rows from a specified table with pagination. ### November 6, 2024 * Added a DELETE endpoint to remove a row. ### October 25, 2024 * Introduced a PATCH endpoint to update an existing row. * `$stashID` is now a reserved column ID. ### October 21, 2024 * Expanded the "type" enumeration for column definitions to include `imageURI`, `audioURI`, `markdown`, `phoneNumber`, `emailAddress`, `emoji`, `date`, `time`, and `duration`, in addition to the existing types and arrays of those values. ### October 4, 2024 * The `schema` field is now optional for the Create Table and Overwrite Table endpoints. * The Create Table and Overwrite Table endpoints now additionally accept a bare JSON array of rows. ### September 18, 2024 * Endpoints that receive tabular data can now accept CSV and TSV request bodies. ### September 13, 2024 * Introduced a new "Limits" document that outlines rate and operational limits for the API. * Updated guidelines for when to use stashing in line with the new doc. * Fixed the Bulk Import tutorial to use PUT instead of POST for the Stash Data endpoint. ### September 4, 2024 * Removed "json" as a valid data type in column schemas for now. ### August 28, 2024 * Users should now use the PUT method instead of POST for `/stashes/{stashID}/{serial}` to set the content of a chunk in a stash. * Clarified that if a chunk is uploaded with an existing serial, its data will be overwritten. * Documented the new format requirements for `stashID` and `serial`. ### August 23, 2024 * The `POST /tables` endpoint now returns HTTP status 201 on success instead of 200. * The `POST /tables/{tableID}/rows` endpoint now returns HTTP status 201 on success instead of 200. ### August 2, 2024 * Add [delete stash](/api-reference/v2/stashing/delete-stash) endpoint documentation ### July 29, 2024 * Remove the `rows` wrapper element from stashing docs * Add `type` to error responses ### July 24, 2024 * Update docs to reflect new production `api.glideapps.com` domain and removal of `/api` in request paths ### July 12, 2024 * Remove the `rows` wrapper element from the request body for the `/tables/{tableId}` endpoint ### July 9, 2024 * Initial release of the Glide API v2 documentation * Support for creating, overwriting tables * Support for adding rows to tables * Support for stashing large datasets # Glide API Postman Collection Source: https://apidocs.glideapps.com/api-reference/v2/resources/postman We have created a [Postman collection for the Glide API v2](https://www.postman.com/glideapps-internal/workspace/glide/collection/32369785-2375efc0-3be9-43bd-a134-bd430deb4c69?action=share\&creator=32369785\&active-environment=32369785-f7167028-954c-4563-8b72-365cf2d69b3c). This is useful if you want to execute the API from your own environment or perform a more rigorous exploration that possible from our documentation. [![Run collection in Postman](https://run.pstmn.io/button.svg)](https://app.getpostman.com/run-collection/32369785-2375efc0-3be9-43bd-a134-bd430deb4c69?action=collection%2Ffork\&source=rip_markdown\&collection-url=entityId%3D32369785-2375efc0-3be9-43bd-a134-bd430deb4c69%26entityType%3Dcollection%26workspaceId%3D992aee9a-f714-4dee-88e8-3ae9e11b159a#?env%5BGlide%20Production%5D=W3sia2V5IjoidG9rZW4iLCJ2YWx1ZSI6IiIsImVuYWJsZWQiOnRydWUsInR5cGUiOiJzZWNyZXQiLCJzZXNzaW9uVmFsdWUiOiI3NzVhZGQ2OS00NTY1LTRiZWUtYjk1OC1hODMyZWM0ODA4NzQiLCJzZXNzaW9uSW5kZXgiOjB9LHsia2V5IjoiYmFzZVVybCIsInZhbHVlIjoiaHR0cHM6Ly9mdW5jdGlvbnMucHJvZC5pbnRlcm5hbC5nbGlkZWFwcHMuY29tL2FwaSIsImVuYWJsZWQiOnRydWUsInR5cGUiOiJkZWZhdWx0Iiwic2Vzc2lvblZhbHVlIjoiaHR0cHM6Ly9mdW5jdGlvbnMucHJvZC5pbnRlcm5hbC5nbGlkZWFwcHMuY29tL2FwaSIsInNlc3Npb25JbmRleCI6MX1d) ## Running in Postman Once you have forked the collection into your own Postman workspace using the button above, you should do the following before executing any requests: Select the "Glide Production" environment from the dropdown in the top right of the Postman window: Select the Glide Production environment Add your personal [Glide API key](/api-reference/v2/general/authentication) to the Glide Production environment as the current value of the `token` variable: Add Glide API key Navigate to any of the requests in the collection and click the "Send" button to execute the request. Execute request The request will be executed scoped to your Glide team using the Glide API key you set in the previous step. # Delete Stash Source: https://apidocs.glideapps.com/api-reference/v2/stashing/delete-stash delete /stashes/{stashID} Deletes a stash and all its data If you no longer need a stash, you can delete it. This will remove the stash and all the data it contains. Even if you do not call this endpoint, all stashes are automatically deleted within 48 hours after they are created. To understand what stashing is and how to use it to work with large datasets, please see our [introduction to stashing](/api-reference/v2/stashing/introduction). # Introduction Source: https://apidocs.glideapps.com/api-reference/v2/stashing/introduction Stashing large datasets for use with the Glide API When using large datasets with the Glide API, it may be necessary to break them into smaller chunks for performance and reliability. We call this process "stashing." ## What is Stashing? Stashing is the process by which a large dataset is broken into smaller chunks for uploading to Glide. Each chunk is uploaded to Glide independently (either sequentially or in parallel) to form the complete dataset. Once all data has been uploaded to the stash, the stash can then be referenced in other API calls to refer to the full dataset. This eliminates the need to include the entire dataset in the request itself, which may not be feasible due to its size. ## When to Use Stashing You should use stashing when both of the following conditions are met: * You have a large dataset that you want to upload to Glide. Anything larger than [15MB](/api-reference/v2/general/limits) should be broken up into smaller chunks and stashed. * You want to perform an atomic operation using a large dataset. For example, you may want to perform an import of data into an existing table but don't want users to see the intermediate state of the import or incremental updates while they're using their application. ## Stash IDs and Serials The main components of a stash are its ID and the individual chunked data subsets, which are identified by serials. Both the ID and serial are values you define. The **stash ID** is a unique identifier for the stash that you define. You might use information that's relevant to your domain, such as `20240215-job32` or `2024-07-05T15-17-50Z_customer93ak`, a UUID, or any other unique identifier. Each chunk of data that is uploaded to the stash is identified by a unique **serial**. The sort order of the serials indicates the order of the chunks in the overall datset. If all serials can be parsed as integers, numerical sort order is used, otherwise sorting is done lexicographically according to each character's Unicode code point value. If the order of data chunks in the stash is important, using integers as serials (e.g., `1`, `2`, etc...) is recommended. The maximum length for both stash IDs and serials is 256 characters. They may only contain letters, numbers, hyphens, and underscores, and must start with a letter or number. ## Referencing a Stash Once all chunks have been uploaded to a stash, you can use the stash ID in place of passing the full dataset inline to other Glide API calls. Think of it as a reference to all the data in the stash. For instance, instead of including all the row data in a request to create a table, you can instead reference the stash ID: ```json theme={null} { "$stashID": "20240215-job32" } ``` The following endpoints support the use of a stash. Please see the specific endpoint's documentation for more details on how to use a stash reference: * [Create Table](/api-reference/v2/tables/post-tables) * [Overwrite Table](/api-reference/v2/tables/put-tables) * [Add Rows to Table](/api-reference/v2/tables/post-table-rows) ## Use Cases Stashing is a general purpose capability, but it is particularly useful in a few known use-cases. Please see our tutorials for more details: * [Bulk Import](/api-reference/v2/tutorials/bulk-import) # Stash Data Source: https://apidocs.glideapps.com/api-reference/v2/stashing/put-stashes-serial put /stashes/{stashID}/{serial} Sets the content of a chunk of data inside a stash When using large datasets with the Glide API, it may be necessary to break them into smaller chunks for performance and reliability. We call this process "stashing." Tabular data may be stashed in JSON, CSV, or TSV format. To learn more about stashing and how to use it to work with large datasets, please see our [introduction to stashing](/api-reference/v2/stashing/introduction). # Delete Row Source: https://apidocs.glideapps.com/api-reference/v2/tables/delete-table-row delete /tables/{tableID}/rows/{rowID} Deletes a row from a Big Table Deletes a row in a Big Table. No error is returned if the row does not exist. # Get Row by ID Source: https://apidocs.glideapps.com/api-reference/v2/tables/get-table-row get /tables/{tableID}/rows/{rowID} Gets a single row from a Big Table by row ID # Get Rows Source: https://apidocs.glideapps.com/api-reference/v2/tables/get-table-rows get /tables/{tableID}/rows Gets rows from a Big Table You can use the `limit` query parameter to specify the maximum number of rows to return for each request. Whether or not you supply a `limit`, you may need to make multiple requests to retrieve all the rows in the table. If there are more rows to fetch, the `continuation` field will be set in the response. To retrieve the next page of rows, make another request with the `continuation` as a query parameter. # List Tables Source: https://apidocs.glideapps.com/api-reference/v2/tables/get-tables get /tables Gets all Big Tables in the current team Get a list of all Big Tables associated with the team of the authenticated user. This endpoint only retrieves **Big Table** tables. No other table types will be included in the response, even though they are part of your Glide team. # Get Rows Version Source: https://apidocs.glideapps.com/api-reference/v2/tables/head-table-rows head /tables/{tableID}/rows Returns an `ETag` header containing the current version of the table data. This endpoint may be polled to detect changes in the table's data. To learn more about versioning and how to detect changes, please see our guide on [data versioning](/api-reference/v2/tables/versioning). *** #### Response Headers The current version of the table data. # Update Row Source: https://apidocs.glideapps.com/api-reference/v2/tables/patch-table-row patch /tables/{tableID}/rows/{rowID} Updates a row in a Big Table Updates an existing row in a Big Table. If a column is not included in the passed row data, it will not be updated. If a column is passed that does not exist in the table schema, or with a value that does not match the column's type, the default behavior is for no update to be made and the API call to [return an error](/api-reference/v2/general/errors#invalid-row-data). However, you can control this behavior with the `onSchemaError` query parameter. # Add Rows to Table Source: https://apidocs.glideapps.com/api-reference/v2/tables/post-table-rows post /tables/{tableID}/rows Adds rows to a Big Table Add one or more rows to an existing Big Table. Row IDs for the added rows are returned in the response in the same order as the input row data is passed in the request. Row data may be passed in JSON, CSV, or TSV format. If a column is not included in the passed row data, it will be empty in the added row. If a column is passed that does not exist in the table schema, or with a value that does not match the column's type, the default behavior is for no rows to be added and the API call to [return an error](/api-reference/v2/general/errors#invalid-row-data). However, you can control this behavior with the `onSchemaError` query parameter. ## Examples If you want to add a small number of rows to a table, you can do so by providing the data inline (being sure that row object structure matches the table schema): ```json theme={null} [ { "fullName": "Alex Bard", "ageInYears": 30, "hiredOn": "2021-07-03" }, { "fullName": "Alicia Hines", "ageInYears": 34, "hiredOn": "2023-01-015" } ] ``` However, this is only appropriate for relatively small dataset (a few hundred rows or less, depending on schema complexity). If you need to work with a larger dataset you should utilize stashing. [Stashing](/api-reference/v2/stashing/introduction) is our process for handling the upload of large datasets. Break down your dataset into smaller, more manageable, pieces and [upload them to a single stash ID](/api-reference/v2/stashing/put-stashes-serial). Then, to add all the row data in a stash to the table in a single atomic operation, use the `$stashID` reference in the `rows` field instead of providing the data inline: ```json theme={null} { "$stashID": "20240215-job32" } ``` # Create Table Source: https://apidocs.glideapps.com/api-reference/v2/tables/post-tables post /tables Creates a new Big Table Create a new Big Table, define its structure, and (optionally) populate it with data. Row IDs for any added rows are returned in the response in the same order as the input row data is passed in the request. Row data may be passed in JSON, CSV, or TSV format. When using a CSV or TSV request body, the name of the table must be passed as a query parameter and the schema of the table is always inferred from the content. Alternatively, the CSV/TSV content may be [stashed](/api-reference/v2/stashing/introduction), and then the schema and name may be passed in the regular JSON payload. If a schema is passed in the payload, any passed row data must match that schema. If a column is not included in the passed row data, it will be empty in the added row. If a column is passed that does not exist in the schema, or with a value that does not match the column's type, the default behavior is for the table to not be created and the API call to [return an error](/api-reference/v2/general/errors#invalid-row-data). However, you can control this behavior with the `onSchemaError` query parameter. ## Examples If you want to create a table and populate it with an initial dataset, you can do so by providing the data inline in the `rows` field (being sure that row object structure matches the table schema): ```json theme={null} { "name": "Employees", "schema": { ... }, "rows": [ { "fullName": "Alex Bard", "ageInYears": 30, "hiredOn": "2021-07-03" } ] } ``` However, this is only appropriate for relatively small initial datasets (around a few hundred rows or less, depending on schema complexity). If you need to work with a larger dataset you should utilize stashing. [Stashing](/api-reference/v2/stashing/introduction) is our process for handling the upload of large datasets. Break down your dataset into smaller, more manageable, pieces and [upload them to a single stash ID](/api-reference/v2/stashing/put-stashes-serial). Then, to create a table from a stash, you can use the `$stashID` reference in the `rows` field instead of providing the data inline: ```json theme={null} { "name": "Employees", "schema": { ... }, "rows": { "$stashID": "20240215-job32" } } ``` # Overwrite Table Source: https://apidocs.glideapps.com/api-reference/v2/tables/put-tables put /tables/{tableID} Replaces the schema and/or data of a Big Table Overwrite an existing Big Table by clearing all rows and (optionally) adding new data. Row IDs for any added rows are returned in the response in the same order as the input row data is passed in the request. Row data may be passed in JSON, CSV, or TSV format. If a column is not included in the passed row data, it will be empty in the added row. If a column is passed that does not exist in the updated table schema, or with a value that does not match the column's type, the default behavior is for no action to be taken and the API call to [return an error](/api-reference/v2/general/errors#invalid-row-data). However, you can control this behavior with the `onSchemaError` query parameter. There is currently no way to supply values for user-specific columns in the API. Those columns will be cleared when using this endpoint. ### Updating the Schema You can optionally update the table schema at the same time by providing a new schema in the JSON request body. If you do not provide a schema, the existing schema will be used. When using a CSV or TSV request body, you cannot pass a schema. If you need to update the schema, use the `onSchemaError=updateSchema` query parameter, or [stash](/api-reference/v2/stashing/introduction) the CSV/TSV data and pass a JSON request body referencing the stash ID. ## Examples To clear all rows from a table, send a PUT request with an empty array in the `rows` field: ```json theme={null} { "rows": [] } ``` If you want to reset a table's data with a small number of rows, you can do so by providing the data inline in the `rows` field (being sure that row object structure matches the table schema): ```json theme={null} [ { "fullName": "Alex Bard", "ageInYears": 30, "hiredOn": "2021-07-03" } ] ``` However, this is only appropriate for relatively small initial datasets (around a few hundred rows or less, depending on schema complexity). If you need to work with a larger dataset you should utilize stashing. [Stashing](/api-reference/v2/stashing/introduction) is our process for handling the upload of large datasets. Break down your dataset into smaller, more manageable, pieces and [upload them to a single stash ID](/api-reference/v2/stashing/put-stashes-serial). Then, to reset a table's data from the stash, use the `$stashID` reference in the `rows` field instead of providing the data inline: ```json theme={null} { "rows": { "$stashID": "20240215-job32" } } ``` This endpoint can be combined with the [Get Rows](/api-reference/v2/tables/get-table-rows) endpoint and [stashing](/api-reference/v2/stashing/introduction) to fetch the current table data, modify it, and then overwrite the table with the updated data: 1. Call the [Get Rows](/api-reference/v2/tables/get-table-rows) endpoint to fetch the current table data. Pass a reasonably high `limit` query parameter because you want to fetch all rows in as few requests as possible. 2. Modify the data as desired, and then stash the modified rows using the [Stash Data](/api-reference/v2/stashing/put-stashes-serial) endpoint. 3. If a `continuation` was returned in step 1, repeat steps 1-3, passing the `continuation` query parameter to [Get Rows](/api-reference/v2/tables/get-table-rows) until all rows have been fetched, modified, and stashed. 4. Finally, call this endpoint with same stash ID used in step 2. This will overwrite the table with the updated data: ```json theme={null} { "rows": { "$stashID": "20240215-job32" } } ``` **Risk of Data Loss** We strongly recommend you use the `If-Match` header to ensure the table is not modified between steps 1 and 4. See the [Data Versioning](/api-reference/v2/tables/versioning) guide for more information. # Data Versioning Source: https://apidocs.glideapps.com/api-reference/v2/tables/versioning Detect updates and prevent data loss with versioning Every Glide Big Table has a version number that increases whenever its data changes. Additionally, each row in a Big Table keeps track of the table version when it was last modified. This information can be used to detect changes to data and prevent mid-air collisions that can result in data loss. ## Getting the Current Version Most API endpoints that work with Big Tables return the current version of the table in the `ETag` response header. If you only want to get the current version of a table without performing any other operation, use the [Get Rows Version](/api-reference/v2/tables/head-table-rows) endpoint. You can poll this endpoint to detect changes to the table. ## Preventing Data Loss When updating data in a Big Table, you can specify the version of the table you expect to be working with using the `If-Match` header. How this value is interpreted depends on the endpoint: * The [Overwrite Table](/api-reference/v2/tables/put-tables) endpoint rejects the request if the current table version is newer than the version specified in the `If-Match` header. * The [Update Row](/api-reference/v2/tables/patch-table-row) endpoint rejects the request if the row has been modified since the version specified in the `If-Match` header. The update is still allowed if another row in the table was modified since the specified version. In both cases, an HTTP `412 Precondition Failed` response is returned if the condition is not met. # Bulk Import Source: https://apidocs.glideapps.com/api-reference/v2/tutorials/bulk-import Importing large datasets into a Big Table When importing large datasets into a Big Table it is necessary to upload the data in stages. This eliminates the volatility of long-running requests and allows for higher performance by parallelizing the upload process. This process is called "stashing". Please read our [introduction to stashing](/api-reference/v2/stashing/introduction) to understand how stashing works before looking at bulk imports specifically. ## Overview The general sequence of operations for a large import is: Create a stable stash ID that will associate all subsequent data uploads. Upload data in stages of 500 to 1,000 rows, using the stash ID from step one. Once all data has been uploaded, use the stash ID to import the full dataset as a single atomic table operation. ## Create Stash ID To simplify the coordination, parallelization, and idempotency of the upload process, the stash ID is a value that you create from the relevant information of your domain. For instance, a daily import process might have a stash ID of `20240501-import`. Or, an import specific to a single customer might have a stash ID of `customer-381-import`. You are responsible for ensuring that the stash ID is unique and stable across associated uploads. ## Upload Data Once you have a stable stash ID, you can use the [stash data endpoint](/api-reference/v2/stashing/put-stashes-serial) to upload the data in chunks. Chunks can be sent in parallel to speed up the upload of large datasets. Use the same stash ID across uploads to ensure the final data set is complete, and use the serial to control the order of the chunks within the stash. As an example, the following [stash](/api-reference/v2/stashing/put-stashes-serial) requests will create a final dataset consisting of the two rows identified by the stash ID `20240501-import`. The trailing parameters of `1` and `2` in the request path are the serial IDs. The data in serial `1` will come first in the stash, and the data in serial `2` will come second, even if the requests are processed in a different order. ```json theme={null} [ { "Name": "Alex", "Age": 30, "Birthday": "2024-07-03T10:24:08.285Z" }, ] ``` ```json theme={null} [ { "Name": "TomTom", "Age": 26, "Birthday": "2024-07-03T10:27:43.265Z" } ] ``` The above is just an example. In practice, you should include more than one row per stash chunk, and if your complete dataset is only 2 rows, you do not need to use stashing at all. See [Limits](/api-reference/v2/general/limits) for guidance. ## Finalize Import Once all the data to be imported has been uploaded, you can use the stash ID in one of Glide API's table endpoints to import the full dataset in a single atomic operation. ### Create New Table To create a table with the data of the stash ID `20240501-import` you can use the [create table](/api-reference/v2/tables/post-tables) endpoint with the `stashID` reference of `20240501-import` instead of the actual row values. ```json theme={null} { "name": "New Table", "schema": { "columns": [ ... ] }, "rows": { "$stashID": "20240501-import" } } ``` ### Add Rows to Table To add data to an existing table you can use the [add rows to table](/api-reference/v2/tables/post-table-rows) endpoint with the `stashID` reference of `20240501-import` instead of the actual row values. ```json theme={null} { "$stashID": "20240501-import" } ``` ### Overwrite Table To reset an existing table's data you can use the [overwrite table](/api-reference/v2/tables/put-tables) endpoint with the `stashID` reference of `20240501-import` instead of the actual row values. ```json theme={null} { "$stashID": "20240501-import" } ``` # Create Upload Source: https://apidocs.glideapps.com/api-reference/v2/uploads/post-apiapps-uploads post /apps/{appID}/uploads Create an upload session and get a pre-signed upload URL. Upload the file bytes to the `uploadLocation`, then call the complete endpoint to finalize the file and receive a public URL. ## Example ```bash theme={null} curl --request POST \ --url https://api.glideapps.com/apps/$APP_ID/uploads \ --header "Authorization: Bearer $GLIDE_API_KEY" \ --header "Content-Type: application/json" \ --data '{ "contentType": "image/png", "fileName": "logo.png" }' ``` Response: ```json theme={null} { "data": { "uploadID": "upload-123", "uploadLocation": "https://storage.googleapis.com/glide-uploads/example?X-Goog-Algorithm=GOOG4-RSA-SHA256" } } ``` Then upload the file bytes to `uploadLocation`: ```bash theme={null} curl --request PUT \ --url "$UPLOAD_LOCATION" \ --header "Content-Type: image/png" \ --upload-file ./logo.png ``` Finally, complete the upload: ```bash theme={null} curl --request POST \ --url https://api.glideapps.com/apps/$APP_ID/uploads/$UPLOAD_ID/complete \ --header "Authorization: Bearer $GLIDE_API_KEY" ``` Note that Glide will delete this file within 30 days if the URL is not stored in a table in Glide. # Complete Upload Source: https://apidocs.glideapps.com/api-reference/v2/uploads/post-apiapps-uploads-uploadid-complete post /apps/{appID}/uploads/{uploadID}/complete Finalize an upload and receive the public URL for the file. Use the `uploadID` from the create upload response. ## Error Responses | Status | Description | | ------ | ---------------------------------------------------------------------------------------------- | | 402 | Upload quota exceeded. The file has been deleted. | | 409 | Upload incomplete. The file bytes were not fully uploaded to the `uploadLocation`. | | 413 | File too large. The uploaded file exceeds the maximum allowed size. The file has been deleted. | Note that Glide will delete this file within 30 days if the URL is not stored in a table in Glide.