Skip to main content

Azure Table Storage Destination

Nexla's bi-directional connectors allow data to flow both to and from any location, making it simple to create a FlexFlow data flow that sends data to an Azure Table Storage location.
azure_table_storage_api.png

Azure Table Storage

Create an Azure Table Storage Destination​

  1. Click the + icon on the Nexset that will be sent to the Azure Table Storage destination, and select the Send to Destination option from the menu.

  2. Select the Azure Table Storage connector from the list of available destination connectors. Then, select the credential that will be used to connect to the Azure Table Storage account, and click Next; or, create a new Azure Table Storage credential for use in this flow.

  3. In Nexla, Azure Table Storage destinations can be created using pre-built endpoint templates, which expedite destination setup for common Azure Table Storage endpoints. Each template is designed specifically for the corresponding Azure Table Storage endpoint, making destination configuration easy and efficient.
    • To configure this destination using a template, follow the instructions in Configure Using a Template.

    Azure Table Storage destinations can also be configured manually, allowing you to send data to Azure Table Storage endpoints not included in the pre-built templates or apply further customizations to exactly suit your needs.
    • To configure this destination manually, follow the instructions in Configure Manually.

Configure Using a Template​

Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Azure Table Storage endpoints. Each template is designed specifically for the corresponding Azure Table Storage endpoint, making destination setup easy and efficient.

  • To configure this destination using a template, select the endpoint to which data will be sent from the Endpoint pulldown menu. Then, click on the template in the list below to expand it, and follow the instructions to configure additional endpoint settings.

    Create Table

    This endpoint creates a new table in the storage account. Use it to provision tables on demand from an upstream flow — for example, when a tenant onboarding event requires a dedicated table per tenant.

    • Each record in the upstream Nexset must contain the JSON payload {"TableName": "<name>"}, where &lt;name&gt; is the desired table name. The full record is sent as the JSON body of the POST /Tables call. Use the Nexla transform layer to shape upstream attributes into this payload.
    • Table names must follow the Azure Table Storage naming rules: 3–63 characters, alphanumeric, may not start with a digit, and case-insensitive.

    Creating a table that already exists returns 409 Conflict. For full payload and naming reference, see the Create Table REST API documentation.

    Delete Table

    This endpoint deletes the named table and all of its entities. Use it to clean up tables that are no longer needed — for example, decommissioning per-tenant or per-batch tables.

    • Enter the table to delete in the Table Name field. This is required. The table name is substituted into the request URL as /Tables('<name>').

    Table deletion is irreversible, and the same table name cannot be re-created for at least 40 seconds after deletion. Validate upstream data carefully before activating this destination. For full reference, see the Delete Table REST API documentation.

    Insert Entity

    This endpoint inserts a new entity into the named table. Use it when you want a strict-insert flow that rejects duplicates — for example, ingesting append-only event records into a table where each event must occur exactly once.

    • Enter the target table in the Table Name field. This is required.
    • Each upstream Nexset record must include PartitionKey and RowKey properties plus any user-defined properties to store on the entity. The full record is sent as the JSON body of the POST call.

    Insert Entity returns 409 Conflict if an entity with the same (PartitionKey, RowKey) already exists. Use Insert Or Replace Entity or Insert Or Merge Entity if upserts are acceptable. For full reference, see the Insert Entity REST API documentation.

    Update Entity (Replace)

    This endpoint replaces an existing entity entirely with the supplied body. Any properties not present in the upstream record are removed from the stored entity. Use it when you want the upstream record to be the full source of truth for the entity.

    • Enter the target table in the Table Name field. This is required.
    • Enter the entity's PartitionKey in the Partition Key field. This is required.
    • Enter the entity's RowKey in the Row Key field. This is required.
    • The body of each PUT call is the upstream record as JSON; it must include PartitionKey and RowKey properties whose values match the URL.

    The template sends If-Match: * on every request, which performs an unconditional replace. To enable optimistic concurrency, override the header with a specific ETag value via the Request Headers field. For full reference, see the Update Entity REST API documentation.

    Merge Entity

    This endpoint merges the supplied properties into an existing entity. Properties not present in the upstream record are preserved on the stored entity. Use it for partial updates — for example, syncing only the fields that changed in a source-of-truth system.

    • Enter the target table in the Table Name field. This is required.
    • Enter the entity's PartitionKey in the Partition Key field. This is required.
    • Enter the entity's RowKey in the Row Key field. This is required.
    • The body of each PATCH call is the upstream record as JSON. Include only the properties that should be updated.

    Azure accepts both MERGE and PATCH verbs for this operation; the Nexla template emits PATCH. The template sends If-Match: * to perform an unconditional merge. For full reference, see the Merge Entity REST API documentation.

    Insert Or Replace Entity (Upsert)

    This endpoint inserts a new entity, or replaces an existing one entirely with the supplied body. The operation is idempotent and does not require an ETag, making it the default choice for bulk loads where the upstream record is the source of truth.

    • Enter the target table in the Table Name field. This is required.
    • Enter the entity's PartitionKey in the Partition Key field. This is required.
    • Enter the entity's RowKey in the Row Key field. This is required.
    • The body of each PUT call is the upstream record as JSON; it must include PartitionKey and RowKey properties whose values match the URL.

    Insert Or Replace Entity overwrites all properties on the existing entity. If preservation of unset properties is required, use Insert Or Merge Entity instead. For full reference, see the Insert Or Replace Entity REST API documentation.

    Insert Or Merge Entity (Upsert-Merge)

    This endpoint inserts a new entity, or merges the supplied properties into an existing one. Properties not present in the upstream record are preserved on the stored entity. The operation is idempotent and does not require an ETag, making it suitable for partial-update bulk loads.

    • Enter the target table in the Table Name field. This is required.
    • Enter the entity's PartitionKey in the Partition Key field. This is required.
    • Enter the entity's RowKey in the Row Key field. This is required.
    • The body of each PATCH call is the upstream record as JSON. Include only the properties that should be set or updated.

    Delete Entity

    This endpoint deletes the entity identified by partition key and row key. Use it for entity-level cleanup driven by upstream events — for example, removing entities flagged for deletion by a source-of-truth system.

    • Enter the target table in the Table Name field. This is required.
    • Enter the entity's PartitionKey in the Partition Key field. This is required.
    • Enter the entity's RowKey in the Row Key field. This is required.

    The template sends If-Match: *, which performs an unconditional delete. To enable optimistic concurrency, override the header with a specific ETag value via the Request Headers field. Entity deletion is irreversible. For full reference, see the Delete Entity REST API documentation.

    Set Table ACL

    This endpoint sets the stored access policies (up to five SignedIdentifier entries) on a table. Stored access policies are referenced by shared access signatures (SAS) to grant scoped, time-limited access. Use this endpoint to provision or rotate SAS policies as part of an automated governance flow.

    • Enter the target table in the Table Name field. This is required.
    • The body of each PUT call must be a serialized XML SignedIdentifiers document containing the stored access policies to apply. Pass the document via the upstream record's message payload.

    Azure Table Storage limits stored access policies to five entries per table. Setting the ACL replaces the entire policy set on the table. For the full document schema and examples, see the Set Table ACL REST API documentation.

    Set Table Service Properties

    This endpoint updates the logging, hour and minute metrics, and CORS settings configured for the Table service on the storage account. Use it to apply infrastructure-as-code configuration to the storage account from a governance flow.

    • The body of each PUT call must be a serialized XML StorageServiceProperties document. Pass the document via the upstream record's message payload.

    Set Table Service Properties replaces the entire properties document, not individual sections. To preserve existing settings, first read the current document with Get Table Service Properties, modify only the sections that need to change, and submit the merged document. For the full document schema, see the Set Table Service Properties REST API documentation.

    Preflight Table Request

    This endpoint issues a CORS preflight (OPTIONS) request against a table resource to confirm which origins, methods, and headers are permitted by the storage account's CORS rules. Use it during CORS configuration validation — for example, verifying that a browser-based application's domain is allowed before a release.

    • Enter the target table in the Table Name field. This is required.
    • The body of each OPTIONS call is the upstream record (as JSON), which carries the CORS preflight headers. Use the Nexla transform layer to shape upstream attributes into the required headers (typically Origin, Access-Control-Request-Method, and Access-Control-Request-Headers).

    Preflight Table Request is anonymous and does not send an Authorization header. The response surfaces the configured CORS rules. For full reference, see the Preflight Table Request REST API documentation.

Configure Manually​

Azure Table Storage destinations can be manually configured to send data to any valid Table service REST API endpoint on the storage account.

Using manual configuration, you can also configure Nexla to automatically send the response received from the Azure Table Storage API after each call to a new Nexla webhook data source — useful for capturing ETags or per-entity error codes returned by the Table service.

API Method​

  1. To manually configure this destination, select the Advanced tab at the top of the configuration screen.

  2. Select the API method that will be used for calls to the Azure Table Storage API from the Method pulldown menu. The Table service uses:

    • POST: To insert a new entity or to create a table.

    • PUT: To replace an entity (Update Entity, Insert Or Replace Entity), or to set table-level resources such as ACLs and service properties.

    • PATCH: To merge properties into an entity (Merge Entity, Insert Or Merge Entity). Azure also accepts the legacy MERGE verb for the same operation.

    • DELETE: To delete an entity or a table.

    • OPTIONS: To issue a CORS preflight request against a table resource.

Data Format​

  1. Select the format in which the Nexset data will be sent to the Azure Table Storage API from the Content Format pulldown menu. Most Table service endpoints expect JSON (application/json) — entity CRUD, table creation, and entity-group batch transactions are all JSON. Table-level configuration endpoints (Set Table ACL, Set Table Service Properties) expect XML (application/xml); select the XML format when targeting those endpoints.

API Endpoint URL​

  1. Enter the URL of the Azure Table Storage API endpoint to which you want to send the Nexset data in the URL field. All Table service URLs follow the form https://{'{account}'}.table.core.windows.net/{'{resource}'}. Examples:

    • https://{'{account}'}.table.core.windows.net/Tables — create a table (POST).

    • https://{'{account}'}.table.core.windows.net/{'{table}'}(PartitionKey='{'{pk}'}',RowKey='{'{rk}'}') — entity-level CRUD.

    • https://{'{account}'}.table.core.windows.net/{'{table}'}?comp=acl — set the table ACL.

Request Headers​

Optional

  • If Nexla should include any additional request headers in API calls to this destination, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (for example, header1:value1,header2:value2). Common Table service headers used on destinations include:

    • If-Match — Set to * for unconditional update/delete, or to a specific ETag for optimistic concurrency.

    • Prefer — Use return-no-content to suppress the response body on insert operations and reduce egress.

    • x-ms-client-request-id — Attach a custom client correlation ID that appears in storage logs.

    You do not need to include any headers already present in the credentials. The Authorization: Bearer header, the x-ms-version header (set from the credential's API Version (x-ms-version) field), and the standard Table service Accept, DataServiceVersion, and MaxDataServiceVersion headers are added automatically.

Exclude Attributes from the Call​

Optional

  • If any record attributes in the Nexset should be omitted when sending data to this Azure Table Storage destination, select the attributes from the Exclude Attributes pulldown menu. This is useful for stripping internal Nexla bookkeeping fields or attributes that the Table service would reject (for example, OData control properties produced by upstream sources).

  • Any number of attributes can be selected for exclusion, and all excluded attributes will be shown in the field. To remove an attribute from the list, click the X icon next to the attribute name.

Record Batching​

Optional

  1. If records should be sent to this destination in batched API calls, check the box next to Would you like to batch your records together? to enable record batching.

  2. Enter the maximum number of records that should be batched together in a single API call in the Batch Size field. By default, this value is set to 100.

    The Table service's native entity-group transactions accept a maximum of 100 entities per batch, and all entities in a batch must share the same PartitionKey. If you are using Nexla's record batching to construct entity-group transactions, keep the batch size at or below 100 and ensure upstream partitioning produces same-partition groups.

  3. Select the algorithm that will be used to group records into batches from the Grouping Algorithm pulldown menu. The sample request shown in the panel on the right will be updated to reflect the current batching settings.

Response Webhook​

Optional

Nexla can automatically send the response received from the Azure Table Storage API after each call to a new Nexla webhook data source. This option allows you to keep track of the status of each API call and any additional information returned after each call, such as the new entity ETag, the x-ms-request-id, or per-row error codes in entity-group transactions.

  • To enable this option, check the box next to Would you like to process the API response as a Nexla Webhook source?.

Sample Request Payload​

Sample request payloads containing a portion of the Nexset data that will be sent to the Azure Table Storage API endpoint based on the current settings are shown in the Sample Payload panel on the right. These samples can be referenced to ensure that the destination and request settings are correctly configured.

  • Click on a sample request payload to expand it and view the complete payload content.
  • Sample payloads are automatically updated with each setting change, making it easy to verify that changes achieve the desired effect.

Endpoint Testing (Manual Configuration)​

After all endpoint settings have been configured, Nexla can send a test payload to the Azure Table Storage API to ensure that the destination is configured correctly.

  1. To send a test payload, select the Test button at the top of the Sample Payload panel, and click on a listed sample payload to expand it.

  2. If any modifications to the sample payload are needed, make the necessary changes directly within the sample window.

  3. Click the Send Test Data button at the top of a sample payload to send the test payload to the Azure Table Storage API using the current settings.

Save & Activate the Destination​

  • Once all endpoint settings have been configured, click the Done button in the upper right corner of the screen to save and create the destination. To begin sending data to the configured Azure Table Storage endpoint, open the destination resource menu, and select Activate.

    The Nexset data will not be sent to the Azure Table Storage endpoint until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.