Azure Table Storage

Azure Table Storage is a Microsoft Azure NoSQL key-attribute store that holds structured, non-relational data as collections of entities organized by partition key and row key. The Table service REST API (data plane) exposes CRUD operations on tables and entities, stored access policies (table ACLs), service properties (logging, metrics, CORS), and entity-group batch transactions against the storage account's table endpoint, enabling integrations to read, write, and administer Azure Table Storage data programmatically.

Power end-to-end data operations for your Azure Table Storage API with Nexla. Our bi-directional Azure Table Storage connector is purpose-built for Azure Table Storage, making it simple to ingest data, sync it across systems, and deliver it anywhere — all with no coding required. Nexla turns API-sourced data into ready-to-use, reusable data products and makes it easy to send data to Azure Table Storage or any other destination. With comprehensive monitoring, lineage tracking, and access controls, Nexla keeps your Azure Table Storage workflows fast, secure, and fully governed.

Features

Type: API

SourceDestination

• Seamless API Integration: Connect to any endpoint as source or destination without coding, with automatic data product creation
• Visual Composition & Chaining: Build complex integrations using visual templates, chain API calls, and compose workflows with data validation and filtering
• API Proxy: Expose curated slices of your data securely with a secure and customizable API proxy that validates and transforms data on the fly
• Request optimization with intelligent batching, retry, and caching to minimize API calls and costs

Prerequisites

The Azure Table Storage connector authenticates to the Table service (data plane) using Microsoft Entra ID OAuth 2.0 with the authorization-code (3-legged) flow. Access tokens are issued by the Microsoft identity platform and presented to https://{account}.table.core.windows.net as Authorization: Bearer headers, alongside an x-ms-version request header.

Before creating a credential in Nexla, complete the following one-time setup in Microsoft Entra ID and Azure.

Register a Microsoft Entra ID Application

The Microsoft Entra app registration represents Nexla as an OAuth 2.0 confidential client and supplies the Client ID, Client Secret, and authorization endpoints used during the consent flow.

1. Sign in to the Microsoft Entra admin center with an account that has permission to manage application registrations in your tenant.

2. In the left navigation, expand Identity > Applications, and select App registrations.

3. Click + New registration at the top of the App registrations page.

4. On the Register an application page, enter the following:

   • Name: A descriptive name for the application, for example Nexla – Azure Table Storage.

   • Supported account types: Select the option that matches your access needs. Choose Accounts in this organizational directory only (Single tenant) for an app limited to your tenant, or Accounts in any organizational directory (Multitenant) if Nexla will authenticate users from other tenants.

   • Redirect URI: Set Platform to Web, and enter the Nexla OAuth callback URL shown in the Nexla credential overlay. The redirect URI registered with Microsoft Entra ID must match this value exactly.

5. Click Register to create the application.

6. After registration, copy the Application (client) ID value from the application's Overview page. This is the Client ID that will be entered into the Nexla credential.

   Also note the Directory (tenant) ID on the Overview page. For single-tenant applications, you will substitute this tenant ID in place of common in the authorization and token URLs entered into Nexla.

Create a Client Secret

The client secret authenticates Nexla to the Microsoft identity platform when exchanging the authorization code for an access token.

1. From the application's left navigation, select Manage > Certificates & secrets.

2. On the Client secrets tab, click + New client secret.

3. Enter a description for the secret (for example, Nexla integration secret), select an expiration period that matches your organization's rotation policy, and click Add.

4. Immediately copy the Value of the new secret and store it in a secure secret manager. The secret value is shown only once; after you leave the page, only the secret ID is visible.

Important

The Client Secret Value grants Microsoft Entra ID token-issuance rights for this application. Store it in a secure secret manager, never commit it to source control, and rotate it immediately if it is exposed.

Grant the Azure Storage API Permission

The application must be granted the user_impersonation delegated permission on the Azure Storage resource so that issued tokens are accepted by https://{account}.table.core.windows.net.

1. From the application's left navigation, select Manage > API permissions.

2. Click + Add a permission, select the Microsoft APIs tab (or APIs my organization uses if Azure Storage is not listed), and choose Azure Storage.

3. Select Delegated permissions, check the user_impersonation scope, and click Add permissions.

4. If your tenant requires admin consent for delegated permissions, click Grant admin consent for {tenant} to consent on behalf of all users. Otherwise, individual users will be prompted for consent the first time they authorize the application.

Assign an Azure RBAC Role to the User on the Storage Account

Microsoft Entra ID authorization for Azure Table Storage requires that the authorizing user (or group) hold a data-plane RBAC role on the target storage account. Without an RBAC assignment, the API returns 403 AuthorizationPermissionMismatch even when the access token is otherwise valid.

1. In the Azure portal, navigate to Storage accounts, and open the target storage account.

2. From the left navigation, select Access control (IAM).

3. Click + Add > Add role assignment.

4. On the Role tab, search for one of the following roles and select it based on the access needed:

   • Storage Table Data Reader: Read-only access to tables and entities. Use this role when Nexla will only ingest data from Azure Table Storage.

   • Storage Table Data Contributor: Read, write, and delete access to tables and entities. Use this role when Nexla will write, update, upsert, or delete entities.

5. On the Members tab, select User, group, or service principal, click + Select members, and add the user account that will authorize the Nexla credential.

6. Click Review + assign to apply the role.

   RBAC role assignments can take several minutes to propagate before the assigned user can call the Table service with a Microsoft Entra ID bearer token.

Identify the Storage Account Name and API Version

1. From the storage account's Overview page in the Azure portal, note the Storage account name (lowercase letters and numbers, 3–24 characters). This value is the hostname prefix of {account}.table.core.windows.net.

2. Confirm that the Azure Storage service version supports Microsoft Entra ID bearer-token authentication for the Table service. The Table service requires x-ms-version of 2020-12-06 or later to accept OAuth 2.0 bearer tokens.

For complete information about Microsoft Entra ID authorization for Azure Storage, see the Authorize with Microsoft Entra ID (Azure Storage REST API) documentation. For details on the OAuth 2.0 authorization-code flow, see the Microsoft identity platform OAuth 2.0 authorization-code flow documentation. For Azure Storage service-version details, see Versioning for Azure Storage.

Authenticate

Create a credential in Nexla

1. After selecting the data source/destination type, click the Add Credential tile to open the Add New Credential overlay.

2. Enter a name for the credential in the Credential Name field and a short, meaningful description in the Credential Description field.

3. Enter the Microsoft Entra ID v2.0 authorization endpoint in the Authorization URL field. The default is https://login.microsoftonline.com/common/oauth2/v2.0/authorize. For a single-tenant application, replace common with the Directory (tenant) ID captured during app registration (for example, https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/oauth2/v2.0/authorize).

4. Enter the Application (client) ID from the Microsoft Entra app registration in the Client ID field. This value is shown on the application's Overview page in the Microsoft Entra admin center.

5. Confirm the Access Scope field contains the Azure Storage delegated scope. The default value is https://storage.azure.com/user_impersonation offline_access:

   • https://storage.azure.com/user_impersonation requests delegated access to Azure Storage on behalf of the signed-in user.

   • offline_access requests a refresh token so Nexla can refresh expired access tokens without prompting the user again.

6. Enter the Microsoft Entra ID v2.0 token endpoint in the Token URL field. The default is https://login.microsoftonline.com/common/oauth2/v2.0/token. For a single-tenant application, replace common with the Directory (tenant) ID, matching the value used in the Authorization URL field.

7. Enter the Client Secret Value copied from the Certificates & secrets page of the Microsoft Entra app registration in the Client Secret field. Nexla stores this value securely and uses it only during token exchange.

8. Enter the Azure Storage Storage Account Name in the Storage Account Name field. This must match the hostname prefix of {account}.table.core.windows.net (lowercase letters and numbers, 3–24 characters).

9. Enter the Azure Storage service version in the API Version (x-ms-version) field. The default value 2020-12-06 is the minimum version that supports Microsoft Entra ID bearer-token authentication for the Table service. Set a later version only if a specific Table service feature requires it.

   The configured API Version (x-ms-version) is sent on every Table service request as the x-ms-version header. Versions earlier than 2020-12-06 do not accept OAuth 2.0 bearer tokens for the Table service and will cause authentication errors.

10. Click Authorize to launch the Microsoft Entra ID consent screen in a new browser tab. Sign in with the user account that holds the Azure RBAC role (Storage Table Data Reader or Storage Table Data Contributor) on the target storage account, and approve the requested permissions.

11. After consent is granted, Microsoft Entra ID redirects back to Nexla with an authorization code. Nexla automatically exchanges this code for an access token and refresh token, and stores the resulting tokens on the credential. Nexla refreshes the access token automatically using the refresh token when it expires.

12. Click the Save button at the bottom of the overlay to save the configured credential. The newly added credential will now appear in a tile on the Authenticate screen during data source/destination creation and can be selected for use with a new data source or destination.

Use as a data source

To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Select the Azure Table Storage connector tile, then select the credential that will be used to connect to the Azure Table Storage instance, and click Next; or, create a new Azure Table Storage credential for use in this flow.

Endpoint templates

Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common Azure Table Storage endpoints. Select the endpoint from which this source will fetch data from the Endpoint pulldown menu. Available endpoint templates are listed in the expandable boxes below. Click on an endpoint to see more information about it and how to configure your data source for this endpoint.

Query Tables

This endpoint enumerates the tables that exist in the storage account. Use it to discover the list of tables, sync the table catalog into a warehouse, or drive downstream entity-level reads against each table.

• No additional configuration is required for this endpoint beyond selecting the template. The request is issued against {'https://{account}.table.core.windows.net/Tables'} using the storage account name stored on the credential.
• The response data path is set to $.value[*], which extracts each entry from the value array returned by the Table service so that every table is treated as an individual record.

Query Tables returns at most 1,000 tables per request. If the account contains more tables, the Table service includes an x-ms-continuation-NextTableName response header that Nexla does not auto-follow. For full reference, see the Query Tables REST API documentation.

Query Entities

This endpoint reads entities from a single table, optionally narrowed by OData filter, projection, and page-size parameters. Use it to ingest entity data into a warehouse or to drive downstream analytics on table content.

• Enter the table to query in the Table Name field. This is required. The table name is appended to the request URL as {'/{table_name}()'}.
• Optionally, enter an OData filter expression in the $filter field to narrow the result set by property values — for example, {"PartitionKey eq 'p1' and RowKey gt 'r5'"}. Leave the field blank to return all entities in the table.
• Optionally, enter a comma-separated list of property names in the $select field to project only the specified fields (for example, PartitionKey,RowKey,Email). Leave the field blank to return every property on each entity.
• Optionally, enter a maximum page size in the $top field. The Azure Table service caps this value at 1000; values above the cap are rounded down.

Query Entities returns the first page only (up to 1,000 entities). Continuation is indicated by the x-ms-continuation-NextPartitionKey and x-ms-continuation-NextRowKey response headers, which Nexla does not auto-follow. For tables larger than one page, partition the work by issuing multiple Query Entities sources whose $filter values target distinct PartitionKey ranges. For full reference, see the Query Entities REST API documentation.

Get Entity

This endpoint retrieves a single entity by its partition key and row key. Use it to enrich an existing dataset of entity keys with the latest property values, or to drive lookups from upstream Nexla flows.

• Enter the table containing the entity 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 combination of Partition Key and Row Key uniquely identifies the entity.

Get Entity returns a single entity object (not an array). The response data path is set to the root ($), so the entity is treated as one record. For full reference, see the Querying Tables and Entities documentation.

Get Table ACL

This endpoint returns the stored access policies defined on a table. Stored access policies are referenced by shared access signatures (SAS) to grant scoped, time-limited access to the table. Use this endpoint for audit or governance flows that need to surface the current SAS policy configuration.

• Enter the table whose access policies should be read in the Table Name field. This is required.

The Table service returns ACL information as XML (a SignedIdentifiers document). For full reference, including the response document schema, see the Get Table ACL REST API documentation.

Get Table Service Properties

This endpoint returns the logging, hour and minute metrics, and CORS settings configured for the Table service on the storage account. Use it for compliance and configuration audits, or to capture current service settings before applying changes.

• No additional configuration is required for this endpoint beyond selecting the template. The request is issued against {'https://{account}.table.core.windows.net/?restype=service&comp=properties'}.

The Table service returns service properties as an XML StorageServiceProperties document. For full reference, see the Get Table Service Properties REST API documentation.

Get Table Service Stats

This endpoint returns replication statistics for the Table service, including the last sync time between the primary and secondary regions. Use it to monitor the geo-replication health of a read-access geo-redundant storage (RA-GRS) account.

• No additional configuration is required for this endpoint beyond selecting the template. The request is issued against the secondary endpoint {'https://{account}-secondary.table.core.windows.net/?restype=service&comp=stats'}.

Get Table Service Stats is only available on the secondary endpoint and only when the storage account is configured for read-access geo-redundant storage (RA-GRS or RA-GZRS). Calls against accounts without RA-GRS will fail. For full reference, see the Get Table Service Stats REST API documentation.

Once the selected endpoint template has been configured, click the Test button to the right of the endpoint selection menu to retrieve a sample of the data that will be fetched. Sample data will be displayed in the Endpoint Test Result panel on the right, allowing you to verify that the source is configured correctly before saving.

Manual configuration

Azure Table Storage data sources can also be manually configured to ingest data from any valid Table service REST API endpoint on the storage account, including endpoints not covered by the pre-built templates, custom OData query parameters, or continuation-token pagination through chained calls. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, endpoint URL, date/time and lookup macros, path to data, metadata, and request headers.

All Table service URLs follow the form https://{account}.table.core.windows.net/{resource} (or https://{account}-secondary.table.core.windows.net/... for read-only queries against the secondary region of an RA-GRS account); read endpoints use the GET and HEAD methods. Set the Path to Data to $.value[*] for JSON list responses such as Query Tables and Query Entities, and to $ for single-object endpoints such as Get Entity. XML responses (Get Table ACL, Get Table Service Properties) use an XPath such as /SignedIdentifiers/SignedIdentifier. You do not need to add authentication headers: the Authorization: Bearer header, the x-ms-version header (from the credential's API Version (x-ms-version) field), and the standard Accept, DataServiceVersion, and MaxDataServiceVersion headers are added automatically.

Once all of the relevant settings have been configured, click the Create button in the upper right corner of the screen to save and create the new Azure Table Storage data source. Nexla will now begin ingesting data from the configured endpoint and will organize any data that it finds into one or more Nexsets.

Use as a destination

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. 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.

Endpoint templates

Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Azure Table Storage endpoints. 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 <name> 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.

For full reference, see the Insert Or Merge Entity REST API documentation.

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.

Manual configuration

Azure Table Storage destinations can also be manually configured to send data to any valid Table service REST API endpoint on the storage account. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, data format, endpoint URL, request headers, attribute exclusions, record batching, and response webhooks. Nexla can also automatically send the response received from the Table service after each call to a new Nexla webhook data source, which is useful for capturing ETags or per-entity error codes.

Table service URLs follow the form https://{account}.table.core.windows.net/{resource}. Select the method for the operation: POST to insert an entity or create a table, PUT to replace an entity or set table ACLs and service properties, PATCH to merge properties into an entity (the legacy MERGE verb is also accepted), DELETE to delete an entity or table, and OPTIONS to issue a CORS preflight request. Send JSON (application/json) for entity CRUD, table creation, and entity-group batch transactions, and XML (application/xml) for Set Table ACL and Set Table Service Properties. When batching records into native entity-group transactions, keep the batch size at or below 100 and ensure all entities in a batch share the same PartitionKey. Set If-Match: * for an unconditional update or delete, or a specific ETag for optimistic concurrency; the Authorization: Bearer, x-ms-version, Accept, DataServiceVersion, and MaxDataServiceVersion headers are added automatically.

Save & activate

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.